You are not logged in.
Here's a snippet of a log from awhile ago:
May 30 00:03:55 protagoras ntpd[3530]: adjusting local clock by 358.616164s
May 30 00:06:15 protagoras ntpd[3530]: adjusting local clock by 358.938006s
May 30 00:09:14 protagoras ntpd[3530]: adjusting local clock by 359.345307s
May 30 00:12:39 protagoras ntpd[3530]: adjusting local clock by 359.865609s
May 30 00:16:06 protagoras ntpd[3530]: adjusting local clock by 360.267431s
Ntpd seems to be failing to make the adjustment that it thinks it's making, resulting in the clock drifting away from the actual time. I'm not sure what other information would be relevant, so please let me know if I should be including anything else. This behavior seems consistent, no matter how I sync the hardware and system clocks, how I invoke ntpd, and so on. I'd appreciate any help.
Cheers,
Shawn
Offline
do you tried updating the time by ntpdate ones?
I think the timedifference is far to much to use ntpd.
Offline
OpenNTPD will set the time directly once when you start it if it's started with the "-s" option, which is done by default. If something screws up your clock after it's started (like if you hibernate and boot some other OS), it won't do it again, so you should restart it.
Offline
I saw this tip when I was installing OpenBSD and i just like it better because you don't have to wait for gradual readjustment of the clock the the openntp daemon does. In your root crontab add a line like:
00 12 * * * /usr/sbin/ntpd -s
This will sync the time with the ntp server at 12:12 every morning.
Last edited by Gen2ly (2009-06-09 21:17:38)
Setting Up a Scripting Environment | Proud donor to wikipedia - link
Offline
Thanks for the suggestions, but I don't think the issue here is the time being off by too much, hibernation, or dual booting. Several times I've manually synchronized the hardware and system clocks to the right time, then watched the clock slowly diverge over the next hour or so. It seems that ntpd is always failing to adjust the clock.
In your root crontab add a line like...
Gen2ly, I suppose I could take that approach, but 1) that seems kind of counter to the idea of ntpd, and 2) will still result in the clock being off by a few minutes (or more) almost all the time. It's not a big deal, but it's not the way it should be working.
Here's a more recent log, running over the past few hours, starting from when the time was almost right (I've only included every 5th attempted correction):
Jun 9 09:46:16 protagoras ntpd[5150]: adjusting local clock by 4.347607s
Jun 9 10:05:52 protagoras ntpd[5150]: adjusting local clock by 10.499490s
Jun 9 10:24:59 protagoras ntpd[5150]: adjusting local clock by 13.077256s
Jun 9 10:42:11 protagoras ntpd[5150]: adjusting local clock by 15.493147s
Jun 9 11:00:35 protagoras ntpd[5150]: adjusting local clock by 18.118155s
Jun 9 11:17:39 protagoras ntpd[5150]: adjusting local clock by 20.402703s
Jun 9 11:34:45 protagoras ntpd[5150]: adjusting local clock by 22.832447s
Jun 9 11:50:17 protagoras ntpd[5150]: adjusting local clock by 25.107387s
Jun 9 12:04:20 protagoras ntpd[5150]: adjusting local clock by 27.179131s
Jun 9 12:22:36 protagoras ntpd[5150]: adjusting local clock by 29.708028s
Jun 9 12:36:22 protagoras ntpd[5150]: adjusting local clock by 31.586910s
Jun 9 12:54:47 protagoras ntpd[5150]: adjusting local clock by 34.062692s
Jun 9 13:10:28 protagoras ntpd[5150]: adjusting local clock by 36.526562s
Cheers,
Shawn
Offline
Are you being adjusted to the wrong timezone? Like, there's maybe a confusion between UTC and local time set somewhere?
Do you have a huge skew value in /var/lib/hwclock/adjtime? (The first value in the file.) It should be somewhere between -5 and 5 at the most. If you once had the clock very far off, a large number will be written here, and your system clock will be misconfigured to believe that your hardware clock drifts a lot. If you do find a big number there, delete this file, set the clock, and reboot.
Offline
Thanks for the suggestions ataraxia. I don't know where to look for timezone mix-ups. In /etc/rc.conf HARDWARECLOCK is set to "UTC" and TIMEZONE is set to "US/Pacific" (I live in California). Neither /etc/conf.d/openntpd nor /etc/ntpd.conf reference anything like a timezone.
However, when I looked at /var/lib/hwclock/adjtime, the first value was around 113, which seems way out of line according to the guidelines you posted. I did the following:
$ rm /var/lib/hwclock/adjtime
$ /etc/rc.d/openntpd stop
$ hwclock --set --date="<current time>"
$ hwclock --hctosys
and restarted. Now adjtime looks like:
0.000000 1244588062 0.000000
1244588062
UTC
It's too soon to say for sure whether that fixed the issue, but it's looking positive. Since rebooting, the last logs I have from ntpd are:
Jun 9 16:00:21 protagoras ntpd[5128]: adjusting local clock by 0.499768s
Jun 9 16:03:20 protagoras ntpd[5128]: adjusting local clock by 0.398575s
Jun 9 16:07:10 protagoras ntpd[5128]: adjusting local clock by 0.329191s
It's still adjusting, but within a totally reasonable range. I don't think I've ever seen it go down more than once, either, so this is certainly a good sign.
Thanks for the help,
Shawn
Offline
113 is right out. These latest developments look very promising.
Offline
Yep, it looks like /var/lib/hwclock/adjtime was indeed the culprit. My clock seems to be ticking along right on schedule now. Thanks ataraxia.
Offline