Red Hat Bugzilla – Bug 6391
xntpd claims spurious hour discrepancy and exits
Last modified: 2008-05-01 11:37:52 EDT
I'm having problems with this occuring now and again (not frequently, but still too frequently). Non linux systems do not get random occasional one hour out problems. Linux systems do this occasionally (also sometimes for exactly half an hour as well): Oct 21 18:04:41 bo709-10-04 xntpd: xntpd startup succeeded Oct 21 18:04:41 bo709-10-04 xntpd[417]: xntpd 3-5.93e Wed Apr 14 20:23:29 EDT 1999 (1) Oct 21 18:04:41 bo709-10-04 xntpd[417]: tickadj = 5, tick = 10000, tvu_maxslew = 495, est. hz = 100 Oct 21 18:04:41 bo709-10-04 xntpd[417]: precision = 12 usec Oct 21 18:04:41 bo709-10-04 xntpd[417]: read drift of 26.590 from /etc/ntp.drift Oct 21 18:09:31 bo709-10-04 xntpd[417]: synchronized to 130.209.240.208, stratum=3 Oct 21 18:09:31 bo709-10-04 xntpd[417]: kernel pll status change 89 Oct 21 19:17:01 bo709-10-04 xntpd[417]: synchronized to 130.209.241.1, stratum=3 Oct 21 19:17:01 bo709-10-04 xntpd[417]: synchronized to 130.209.240.49, stratum=3 Oct 21 19:17:01 bo709-10-04 xntpd[417]: synchronisation lost Oct 21 19:21:33 bo709-10-04 xntpd[417]: synchronized to 130.209.241.1, stratum=3 Oct 21 19:21:33 bo709-10-04 xntpd[417]: time error -3600.355229 is way too large
The exiting occurs because of a sanity check to prevent time warps on the local NTP client due to servers passing bad data etc. One cause of your problem might be apmd disabling and reenabling cpu power, as xntp3 needs accurate timestamps in order to synchronize. Otherwise, without a reproducible test case, we are not going to be able to even verify your problem.