I recently upgraded from ntp 4.2.2p3 to 4.2.4. Since then, I have since lots of log entries like this: ntpd[PID]: kernel time sync error 0001 These entries seem to be replacing the happy little periodic status messages I was getting prior to the upgrade: ntpd[PID]: synchronized to aa.bb.cc.dd, stratum 2 I think ntpd is trying to tell me something bad is happening. I did some googling and found a bug in ntp's bugzilla, but I don't know if it's relevant. Reproducible: Always Steps to Reproduce: 1. Upgrade from ntp 4.2.2_p3 to ntp 4.2.4-r1 2. Check /var/log/daemon.log for entries where ntpd is complaining. Actual Results: Mar 11 19:02:38 tux ntpd[8898]: ntpd 4.2.4@1.1437-o Sat Mar 10 21:20:51 UTC 2007 (1) Mar 11 19:02:38 tux ntpd[8899]: precision = 1.000 usec Mar 11 19:02:38 tux ntpd[8899]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled Mar 11 19:02:38 tux ntpd[8899]: Listening on interface #1 lo, 127.0.0.1#123 Enabled Mar 11 19:02:38 tux ntpd[8899]: Listening on interface #2 eth0, 192.168.1.103#123 Enabled Mar 11 19:02:38 tux ntpd[8899]: kernel time sync status 0040 Mar 11 19:02:38 tux ntpd[8899]: frequency initialized -104.276 PPM from /var/lib/ntp/ntp.drift Mar 11 19:05:55 tux ntpd[8899]: synchronized to LOCAL(0), stratum 3 Mar 11 19:05:55 tux ntpd[8899]: kernel time sync status change 0001 Mar 11 19:06:58 tux ntpd[8899]: synchronized to 216.99.98.39, stratum 2 Mar 11 19:12:19 tux ntpd[8899]: synchronized to 204.13.216.91, stratum 2 Mar 11 19:20:57 tux ntpd[8899]: time reset -0.727492 s Mar 11 19:24:50 tux ntpd[8899]: synchronized to LOCAL(0), stratum 3 Mar 11 19:26:12 tux ntpd[8899]: synchronized to 204.13.216.91, stratum 2 Mar 11 21:15:27 tux ntpd[8899]: kernel time sync error 0001 ... and lots more like the above entry, with an occasional "synchronized" entry Expected Results: Feb 14 19:35:53 tux ntpd[6524]: ntpd 4.2.2p3@1.1577-o Sat Jan 27 16:13:23 UTC 2007 (1) Feb 14 19:35:53 tux ntpd[6544]: precision = 2.000 usec Feb 14 19:35:53 tux ntpd[6544]: Listening on interface wildcard, 0.0.0.0#123 Disabled Feb 14 19:35:53 tux ntpd[6544]: Listening on interface lo, 127.0.0.1#123 Enabled Feb 14 19:35:53 tux ntpd[6544]: Listening on interface eth0, 192.168.1.103#123 Enabled Feb 14 19:35:53 tux ntpd[6544]: kernel time sync status 0040 Feb 14 19:35:53 tux ntpd[6544]: frequency initialized -104.546 PPM from /var/lib/ntp/ntp.drift Feb 14 19:39:08 tux ntpd[6544]: synchronized to LOCAL(0), stratum 3 Feb 14 19:39:08 tux ntpd[6544]: kernel time sync enabled 0001 Feb 14 19:40:16 tux ntpd[6544]: synchronized to 209.216.230.19, stratum 2 Feb 14 19:47:41 tux ntpd[6544]: synchronized to 192.139.46.42, stratum 2 Feb 14 19:58:32 tux ntpd[6544]: time reset +2.256960 s Feb 14 20:02:46 tux ntpd[6544]: synchronized to LOCAL(0), stratum 3 Feb 14 20:03:52 tux ntpd[6544]: synchronized to 209.216.230.19, stratum 2 So, can we downgrade the stable version of ntp until this problem is resolved? thanks.
https://ntp.isc.org/bugs/show_bug.cgi?id=780 is the upstream bug. Short summary: it's from code that was introduced in 4.2.4, and is caused by ntp_adjtime (a kernel/glibc function) returning an error. Either way, it is certainly not Gentoo specific. The error is showing up for me on amd64, 2.6.17. From my observation, NTP still seems to be doing its job properly though.
remind me when this gets resolved properly upstream and i'll pull down the fix/new version ;)
> The error is showing up for me on amd64, 2.6.17. From my observation, NTP > still seems to be doing its job properly though. Not according to the upstream bug reporter, and it seems to be affecting my little office server as well (I get both the error messages and random erratic time-sync behavior). I think the suggestion of masking 4.2.4 until it's fixed is a good idea...
When you guys marked this as RESOLVED UPSTREAM, is that because the problem was determined to be a kernel bug? If so, the understanding is that the latest 2.6 kernel version fixes this?
