Bug 6391 - xntpd claims spurious hour discrepancy and exits
xntpd claims spurious hour discrepancy and exits
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: xntp3 (Show other bugs)
6.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-10-26 14:18 EDT by rjb
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-02-27 13:02:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description rjb 1999-10-26 14:18:28 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
Comment 1 Jeff Johnson 2000-02-27 13:02:59 EST
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.

Note You need to log in before you can comment on or make changes to this bug.