SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hi: the time in my computer is always lagging exactly 3 hours. I set the right time but in a very short time it is lagging again. What can be the cause?
Since you're exactly 3 hours behind UTC, my guess is that it has something to do with that. Are you dual booting? Also, how are you setting the time?
I'd suggest using timeconfig to make sure that your timezone is correct. Then, make sure the clock is set to the proper local time. Once you've done that, use hwclock to save it to the hardware clock.
If your hardware clock uses UTC:
/sbin/hwclock --utc --systohc
If your hardware clock uses local time:
/sbin/hwclock --localtime --systohc
If you happen to be dual booting, the other operating system might have a different idea about whether you are using local time or UTC. If that is the case, and if it is set to synchronize from a network clock source, that could also lead to a 3 hour offset. Similarly, a wrong timezone setting on Linux combined with network time sync could lead to the 3 hour offset whenever the sync occurs.
I use dual booting but seldom boot the other OS. So, this can't be the cause. Also, the clock must be synchronized to some external source, and this is what I do not understand. I do not use ntpd or other network time service.
Another thing is that when in London it is, say 11pm, in my city it is 8pm. But I have 5pm! Just the same lag but opposite sign. It surely is a coincidence.
The actual UTC time is not relevant. If your hardware clock is set to local time (8 pm), but the system is configured to think that the hardware clock represents UTC, you'll be lagging by 3 hours.
Did you try reconfiguring and then saving the time to the hardware clock?
Yes, I did. Now I'll have to wait at least a day to be sure the clock is well. But why am I connected to an external source? Running 'ps -e|grep ntp' gives nothing. Maybe the GUI runs some network time service?
Yes, I did. Now I'll have to wait at least a day to be sure the clock is well. But why am I connected to an external source? Running 'ps -e|grep ntp' gives nothing. Maybe the GUI runs some network time service?
You might not be syncing to any external source. The example I gave where the hardware clock holds localtime but the system thinks that the hardware clock holds UTC would cause a 3 hour lag for your timezone whenever the hardware clock is fetched.
To set the system clock under Linux, use the date command. As an example, to set the current time and date to July 31, 11:16pm, type ``date 07312316'' (note that the time is given in 24 hour notation). If you wanted to change the year as well, you could type ``date 073123161998''. To set the seconds as well, type ``date 07312316.30'' or ``date 073123161998.30''. To see what Linux thinks the current local time is, run date with no arguments.
Setting the hardware clock
To set the hardware clock, my favourite way is to set the system clock first, and then set the hardware clock to the current system clock by typing ``/sbin/hwclock --systohc'' (or ``/sbin/hwclock --systohc --utc'' if you are keeping the hardware clock in UTC). To see what the hardware clock is currently set to, run hwclock with no arguments. If the hardware clock is in UTC and you want to see the local equivalent, type ``/sbin/hwclock --utc''
Ntp is used to synchronize your computer to an external source which is in turn synchronized to an atomic clock at a research facility. It helps to overcome any creeping errors in time reporting due to hardware issues that are too technical for me to describe.
I ran timeconfig to set the time zone to my time zone, then date to set the time and 'hwclock --localtime --systohc'. Now I am periodically running 'hwclock ; date' to see which one of the clocks is lagging, if it is. It is possible that the time zone was wrong. It's the only possible explanation.
The timezone must have been wrong, because after running timeconfig the problem never occurred again. Now the system time is always correct, within the accuracy of the hardware clock.
If you are dual booting with Windows do NOT set your hardware clock to UTC.
Use localtime. Slackware will not add by default server entries to your
/etc/ntp.conf file, you must add them yourself:
Code:
server 2.ar.pool.ntp.org iburst
server 0.south-america.pool.ntp.org iburst
server 2.south-america.pool.ntp.org iburst
Take in care ntp daemon will not correct automatically your time if the delay
is big, so you must stop it:
Code:
# /etc/rc.d/rc.ntpd stop
set the time with ntpdate:
Code:
# ntpdate 2.ar.pool.ntp.org
and restart it:
Code:
# /etc/rc.d/rc.ntpd start
Now I am not using Slackware I don't remember if some rc file runs hwclock at
shut down. You can check it doing:
Code:
grep hwclock /etc/rc.d/*
If it doesn't you can add some of the hwclock commands explained by Patrick to
rc.local_shutdown
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
Rep:
Quote:
Originally Posted by stf92
I suppose Windows connects itself to external sources on a periodic basis. How can this interfere with ntpd?
Windows does do what they call "Internet time" periodically to keep the clock(s) up to date. So, you might want to double-check your time zone settings in Windows and make sure it's correct.
Daylight time is coming soon (it's 10 March in the US) and your Linux system, if it's running, will switch the time. If you then boot Windows, it'll switch the time again, then you get back into Linux and your clock is all screwed up. Best solution I've found is to turn off the automatic daylight time adjustment in Windows. Other best solution is install Windows in VirtualBox (or some other virtual machine software) and you won't have the problem (Windows can't fiddle with the hardware in VirtualBox, but turn off the automatic daylight time adjustment anyway).
I suppose Windows connects itself to external sources on a periodic basis. How can this interfere with ntpd?
You're right, I didn't explain it correctly.
It's not exactly about using ntpd but using UTC time (like Patrick explained). Windows doesn't support UTC bios time, it will save your localtime to bios clock. When you reboot to a Linux configured to use UTC, ntpd won't sync because it can't handle big drifts.
I told you not use ntpd in that case because a common alternative is running ntpdate at boot time.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.