[ntp:questions] Re: Lost synchronization on 2003 to 2004 year rollover
David L. Mills
mills at udel.edu
Fri Jan 9 19:02:55 UTC 2004
Remember, the ntpd daemon and timestamp calculations have nothing to do
with Unix; the only connection with Unix time is in the systime.c
routines, which use the Unix adjtime() and gettimeofday() system calls.
>From your description, at or near the rollover the gettimeofday()
routine returned one day (86400 seconds) different than NTP time.
Ordinarily, this would cause the daemon to exit after the 900-second
stepout interval, but apparently it did not. Since you saw the time
torqued by one day and the daemon survived, something surely is wrong.
Nothing like that happened here, but then we don't run Linux.
William Brower wrote:
> We have 7 linux machines (stock Redhat7.2, kernel 2.4.7-10smp)
> synchronized to a single NTP server on a LAN (a Datachron model 2000
> netsync server). Each of the client machines now show the correct time,
> but the incorrect date - they are all 1 day in the future.
> NTP version 4.1.0 on the Linux machines.
> We peeked in the logs (/var/log/message*) to see the suspicion of year
> rollover was confirmed: that is indeed the problem. About 10 minutes
> after year rollover, the ntp daemon lost synchronization with the server
> and adjusted the time by 86399.999xxx seconds. The NTP server is today
> showing the correct date and time and we have no reason to believe it
> misbehaved during rollover. We're leaning toward an ntpd bug. Suggestions?
> Now a second question. Given that the NTP server is correct and that a
> client machine is 24 hours ahead of it, why does the NTP daemon not
> reject the server as "very wrong"? ntpd shows no signs of trouble even
> though the server and local machine are 24 hours different.
> Note that we have a strange situation here, as all of these client
> machines and the server live on a very isolated network - and the one
> NTP server is all we have. Could this be why the machines wont reject
> the "wrong" time...that they don't have anything to compare it to? But,
> if it wont reject it, then why do the clients continue to show the wrong
> date? Shouldn't they be slewing backwards to get to yesterday?
> Please CC: wbrower at ll.mit.edu
> William Brower
> MIT Lincoln Laboratory
> Reagan Test Site, Kwajalein, Marshall Islands
> p: 805.355.1310
> f: 805.355.1701
More information about the questions