ntp and hwclock

tjwoosta · 2011-05-08 20:30:58

Earlier today I installed ntp for the first time following the wiki page, because Ive noticed my clock slowly drifts out of sync. After a couple months its usually a few hours off.

Anyway I want to run as non-root user, but I noticed it says

Note: Before attempting this, make sure ntp has already created /var/lib/ntp/ntp.drift.

So Ive been running it as root for a few hours waiting for the file to be created, but it never happens. My clock has synced, but that file doesnt exist. The only file in /var/lib/ntp/ is an empty file called .placeholder

My /etc/ntp.conf says

driftfile       /var/lib/ntp/ntp.drift

I also noticed that when I reboot my clock always goes back to being out of sync untill about 10 minutes later when ntp syncs it.

Basically what am I doing wrong? Is it safe to just touch the ntp.drift file manually rather than wait for ntp to create it? How can I sync my hardware clock with the ntp time so its not so far off when I first boot?

Last edited by tjwoosta (2011-05-09 03:10:17)

ewaller · 2011-05-08 22:40:06

Out of curiosity, why do you not want to run it as a daemon? I'm not saying it is wrong, or don't do that. I just what to know the rational.

Last edited by ewaller (2011-05-08 22:40:35)

tjwoosta · 2011-05-08 23:36:55

I do want to run it as a daemon, just make it drop root and run as ntp:ntp .

Heres the section of the wiki that explains what Im trying to do
https://wiki.archlinux.org/index.php/NT … -root_user

But I havnt even made it that far yet. For now Im just running as root waiting for the drift file to be created, but its not happening.

tjwoosta · 2011-05-08 23:50:37

Ok, strange thing just happened. I ran ntpd with debug flag and the drift file was created immediatly.

Dont know what was happening, but I have the drift file now so I guess thats fine. Now my only problem is that I have to wait a while from the time I boot before my clock gets adjusted. I assume this means my hardware clock is not being synced with the ntp time? Is there a way to fix that?

tjwoosta · 2011-05-09 00:17:02

Been reading up on and learned about hwclock, would it be a bad idea to do a hwclock --systohc cron job?

brebs · 2011-05-09 01:45:53

tjwoosta wrote:

wait a while

That's how the ntpd program works - it syncs *slowly*, so as not to screw up your logfile or whatever other time-sensitive progs you may be running.

At startup, your initscript should first be running *ntpdate* - an example snippet:

/sbin/hwclock --hctosys
SERVER="`grep -m 1 ^server /etc/ntp.conf | awk '{ print $2 }'`"
ntpdate -t 15 $SERVER

Then when the initscript stops:

/sbin/hwclock --systohc

Your cron job idea is probably overkill, but I suppose you could do that e.g. once per day, to be paranoid, in case ntpdate fails.

Edit: ntpdate is the old-style method.

Last edited by brebs (2011-05-09 01:54:09)

tjwoosta · 2011-05-09 01:59:28

brebs wrote:

tjwoosta wrote:
wait a while
That's how the ntpd program works - it syncs *slowly*, so as not to screw up your logfile or whatever other time-sensitive progs you may be running.
At startup, your initscript should first be running *ntpdate* - an example snippet:
/sbin/hwclock --hctosys
SERVER="`grep -m 1 ^server /etc/ntp.conf | awk '{ print $2 }'`"
ntpdate -t 15 $SERVER
Then when the initscript stops:
/sbin/hwclock --systohc
Your cron job idea is probably overkill, but I suppose you could do that e.g. once per day, to be paranoid, in case ntpdate fails.
Edit: ntpdate is the old-style method.

wait, what file is that snippet from? I dont see that anywhere. I see /etc/rc.d/hwclock, which updates the hw clock on stop, but the ntp wiki page says to disable it.

Last edited by tjwoosta (2011-05-09 02:09:37)

brebs · 2011-05-09 02:28:26

It's from Lunar.

It would be nice if the Arch wiki actually gave a *reason*. Maybe Arch's initscripts package itself runs hwclock? That Arch page says:

Add ntpd to the DAEMONS array in /etc/rc.conf to have it start at boot; also make sure not to be starting hwclock (for initscripts>=2011.04.1)

It also says, further down:

Since initscripts-2011.04.1, check that the DAEMONS array in /etc/rc.conf includes hwclock, to ensure the hardware clock is periodically updated

Which sounds contradictory.

tjwoosta · 2011-05-09 03:02:45

brebs wrote:

It's from Lunar.
It would be nice if the Arch wiki actually gave a *reason*. Maybe Arch's initscripts package itself runs hwclock? That Arch page says:
Add ntpd to the DAEMONS array in /etc/rc.conf to have it start at boot; also make sure not to be starting hwclock (for initscripts>=2011.04.1)
It also says, further down:
Since initscripts-2011.04.1, check that the DAEMONS array in /etc/rc.conf includes hwclock, to ensure the hardware clock is periodically updated
Which sounds contradictory.

I think the second one is supposed to be for if your not running the ntp daemon, since its in the "Syncing the clock without running the daemon" section. But I cant figure out why it should be disabled. With it disabled I dont see anything anywhere that sets the hardware clock. /etc/rc.sysinit sets the system clock from the hardware clock but not the other way around.

Im so confused..

Last edited by tjwoosta (2011-05-09 03:04:48)

lolilolicon · 2011-05-09 03:29:49

brebs wrote:

Which sounds contradictory.

No, you're reading it out of context. Note that the second quote is from the "Syncing the clock without running the daemon" section.

I, too, am wondering if there's anything doing `hwclock --systohc` or anything that saves the (correct) system time to hardware clock at system shutdown.

It seems to me that running the hwclock daemon along with ntpd is fine, except I find the hourly cron job doing `hwclock --adjust` unnecessary, (or "can lead to subtle bugs (especially if using dual-boot or ntp)"). Or rather, it seems to me, only the "stop" part of the hwclock daemon is useful when using ntpd...

Maybe we can just add this to /etc/rc.local.shutdown:

stat_busy "Saving System Time to Hardware Clock"
hwclock --systohc

Last edited by lolilolicon (2011-05-09 03:36:39)

brebs · 2011-05-09 03:45:31

lolilolicon wrote:

Note that the second quote is from the "Syncing the clock without running the daemon" section.

That doesn't explain the contradiction I mentioned.

rc.local.shutdown

Who doesn't care about time? Being part of the ntp package is convenient and appropriate, rather than being something that the user adds manually if he happens to see this forum thread.

tjwoosta · 2011-05-09 03:58:31

lolilolicon wrote:

Maybe we can just add this to /etc/rc.local.shutdown:
stat_busy "Saving System Time to Hardware Clock"
hwclock --systohc

That makes more sense than a cron job, but if theres nothing else setting the hardware clock maybe it would be best to have /etc/rc.d/ntpd do it on stop?

lolilolicon · 2011-05-09 04:07:44

brebs wrote:

lolilolicon wrote:
Note that the second quote is from the "Syncing the clock without running the daemon" section.
That doesn't explain the contradiction I mentioned.

The two statements don't contradict with each other, only different strategies under different conditions. But the wiki needs to explain why running both the ntpd and hwclock daemons are bad, in addition to the first statement.

rc.local.shutdown
Who doesn't care about time? Being part of the ntp package is convenient and appropriate, rather than being something that the user adds manually if he happens to see this forum thread.

I agree saving the system time to RTC is necessary for almost everyone. I actually meant to edit rc.local.shutdown to rc.shutdown at a second thought...
How do you think this should be included in the ntp package? Please elaborate.

Edit:
Hmmm... it seems the thing is a bit more complicated: http://tldp.org/HOWTO/Clock-2.html (esp. "Potential Conflicts")

Last edited by lolilolicon (2011-05-09 04:30:41)

brebs · 2011-05-09 04:52:05

lolilolicon wrote:

included in the ntp package? Please elaborate.

See the Lunar script I linked to earlier, regarding its use of hwclock.

a bit more complicated

Yeah - needs more investigative time than I could be bothered with. I also found this 11-minute sync mode, which I would speculate ntpd enables, in which case the cron job question is "solved" at least.

lolilolicon · 2011-05-09 07:09:28

brebs wrote:

11-minute sync mode

Right, I've checked from `adjtimex --print`, that 11 minute mode is indeed on here (supposedly activated by ntpd). This should mean that with ntpd in effect, `hwclock --systohc` is indeed unnecessary at all (also doesn't hurt).

tjwoosta wrote:

I also noticed that when I reboot my clock always goes back to being out of sync untill about 10 minutes later when ntp syncs it.

How much is the clock off when the system boots up? And how long has the system been down?
Or did you mean really "reboot"? In that case, I guess the 11 minute mode is off.
Running ntpdate at bootup as brebs suggested should be fine. Adding ntpdate to your DAEMONS array should do it (but I'm not sure if it will disable 11 minute mode).

---
Below is my current point of view on this issue (correct me if anything is wrong):

If you want to maintain the RTC accurately, you use hwclock as the *only* program that ever sets/adjusts the RTC. To do this, you must prevent anything else from setting the RTC, e.g. the 11 minute mode, or another OS. This has the benefit of relatively accurate time at boot up, by running `hwclock --adjust && hwclock --hctosys`.

On the other hand, if you can't prevent others from setting the RTC, don't use hwclock to set/adjust RTC at all. The downside is that any drift of the RTC when the system is down will not be adjusted at boot up, but can only be corrected later by ntpd + the 11 minite mode, or whatever.

Last edited by lolilolicon (2011-05-09 07:46:55)

tomegun · 2011-05-09 12:36:50

Hi guys!

This is how hwclock/ntp is supposed to work. If it does not, please file bugs against initscripts, and I'll try to figure it out:

* ntpd will enable 11-minute-mode in the kernel (I don't think it is possible to disable this, let me know if I'm wrong!)
* 11-minute-mode will write the system clock to the hardware clock every 11 minutes, but it will not update the adjfile (so the hardware clock will drift when the computer is off, and this we cannot adjust for, sadly)
* hwclock --systohc/--hctosys will adjust for and calculate/update the drift to the adjfile
* if anything else than hwclock adjusts the hardware clock then the calculated drift will be completely wrong and we must use hwclock --hctosys --noadjfile to avoid getting weird errors

In other words, we must choose between ntpd or hwclock and never use both. the benefit of ntpd is that it will give a more accurate time when the computer is online, the benefit of hwclock is that it will give a more accurate time when the computer is offline. The reason why ntpd is probably the best choice is that a computer not connected to a network probably does not need to have a very accurate time.

Please open bug reports or email <arch-projects@archlinux.org> if you have problems!

Cheers,

Tom

lolilolicon · 2011-05-09 14:36:09

Good, thank you for the clarification!

Regarding to 11 miniute mode...

tomegun wrote:

* ntpd will enable 11-minute-mode in the kernel (I don't think it is possible to disable this, let me know if I'm wrong!)

hwclock(8) wrote:

This mode (we'll call it "11 minute mode") is off until something turns it on. The ntp daemon xntpd is one thing that turns it on. You can turn it off by running anything, including hwclock --hctosys, that sets the System Time the old fashioned way.

I've tried it, `hwclock --hctosys` did disable it, but I'm not sure if ntpd will re-enable it...
Edit: Confirmed (probably) nptd re-enabled 11 minute mode.

Last edited by lolilolicon (2011-05-09 14:51:35)

tjwoosta · 2011-05-09 15:27:47

11 minute mode sounds good, but its not being enabled here as far ask I can tell. Every reboot my clock goes back to being 53 minutes off, until about 5 minutes later when ntp updates it. Even after being on overnight.

lolilolicon · 2011-05-09 16:14:50

tjwoosta wrote:

11 minute mode sounds good, but its not being enabled here as far ask I can tell. Every reboot my clock goes back to being 53 minutes off, until about 5 minutes later when ntp updates it. Even after being on overnight.

To check whether 11 minute mode is on or off, I installed adjtimex from AUR and checked the "status" value from `adjtimex --print`; you can determine if 11 miniute mode is enabled by running:

echo $(($(adjtimex --print | grep status | grep -o '[0-9]\+')/64%2))

0 is on, 1 is off.

Last edited by lolilolicon (2011-05-09 16:17:25)

tjwoosta · 2011-05-09 16:25:12

hmm.. it returns 0, but my time problem persists.

lolilolicon · 2011-05-09 16:37:46

Strange. What is the output of `hwclock && date`?

tjwoosta · 2011-05-09 17:43:30

Mon 09 May 2011 02:12:28 PM EDT  -0.412997 seconds
Mon May  9 13:42:28 EDT 2011

lolilolicon · 2011-05-09 18:34:33

Off half an hour... Try doing `hwclock --systohc` (maybe with --noadjfile too) once, see if the problem persists.

tjwoosta · 2011-05-09 19:07:59

lolilolicon wrote:

Off half an hour...

yea, I never actually compared it when I said 53 minutes, I was just going by ntps drift file which said -53.445. I guess that doesnt mean how far off the clock is then.

Try doing `hwclock --systohc` (maybe with --noadjfile too) once, see if the problem persists.

hwclock --systohc did work, everything is synced up now. I was just holding off on doing it waiting for the system to do it automatically with the 11 minute mode or whatever. Now that the clock is synced I have no way of knowing if its doing it automatically, other than waiting to see if it drifts out of sync again in a month or so.

EDIT:
btw, I dont dual boot or anything, so I dont think anything else will be setting the hardware clock and interfering.

Last edited by tjwoosta (2011-05-09 19:14:40)

Lars Stokholm · 2011-05-10 14:05:42

tjwoosta wrote:

Anyway I want to run as non-root user, but I noticed it says
Note: Before attempting this, make sure ntp has already created /var/lib/ntp/ntp.drift.

I totally ignored that advice. Now, after some time, ntp created ntpd.drift without any issues, as far as I can see:

[lars@x201 ~]$ LC_ALL=C ll /var/lib/ntp/ntp.drift
-rw-r--r-- 1 ntp ntp 6 May 10 14:55 /var/lib/ntp/ntp.drift

Arch Linux

#1 2011-05-08 20:30:58

ntp and hwclock

#2 2011-05-08 22:40:06

Re: ntp and hwclock

#3 2011-05-08 23:36:55

Re: ntp and hwclock

#4 2011-05-08 23:50:37

Re: ntp and hwclock

#5 2011-05-09 00:17:02

Re: ntp and hwclock

#6 2011-05-09 01:45:53

Re: ntp and hwclock

#7 2011-05-09 01:59:28

Re: ntp and hwclock

#8 2011-05-09 02:28:26

Re: ntp and hwclock

#9 2011-05-09 03:02:45

Re: ntp and hwclock

#10 2011-05-09 03:29:49

Re: ntp and hwclock

#11 2011-05-09 03:45:31

Re: ntp and hwclock

#12 2011-05-09 03:58:31

Re: ntp and hwclock

#13 2011-05-09 04:07:44

Re: ntp and hwclock

#14 2011-05-09 04:52:05

Re: ntp and hwclock

#15 2011-05-09 07:09:28

Re: ntp and hwclock

#16 2011-05-09 12:36:50

Re: ntp and hwclock

#17 2011-05-09 14:36:09

Re: ntp and hwclock

#18 2011-05-09 15:27:47

Re: ntp and hwclock

#19 2011-05-09 16:14:50

Re: ntp and hwclock

#20 2011-05-09 16:25:12

Re: ntp and hwclock

#21 2011-05-09 16:37:46

Re: ntp and hwclock

#22 2011-05-09 17:43:30

Re: ntp and hwclock

#23 2011-05-09 18:34:33

Re: ntp and hwclock

#24 2011-05-09 19:07:59

Re: ntp and hwclock

#25 2011-05-10 14:05:42

Re: ntp and hwclock

Board footer