[ntp:questions] Re: NTP, Unix and the 34-year itch

David L. Mills mills at udel.edu
Sat Jan 24 21:41:13 UTC 2004


Roman,

Neither 36 years or 100 years sounds plausible from ntpd victim. The
daemon knows nothing about DST of course, and cannot compute an offset
more than 34 years in the version you probably have. The year 1904 is in
the past relative to the Unix base of 1970, or negative by 66 years, but
not beyond a sign flip. I would also be very surprised if the Unix
library handled negative timestamps and got the prettyprint right. If
you are watching loopstats or something like that, it would be useful to
see the data. I've never seen anything like that in my Solaris herd or
other herds here; however, I'll survey the other ranches on campus for
stampedes.

Dave

Roman Maeder wrote:
> 
> David L. Mills wrote:
> > Folks,
> >
> > I have retooled ntpd in the development version here as per my
> > suggestions below and tested it in both Solaris and FreeBSD. The daemon
> > sets the clock correctly  if within +-68 years of UTC. I tested it by
> > setting the Unix clock to 1970 and then to 2036 and verified it works in
> > both broadcast and unicast modes and with and without public key
> > cryptography.
> 
> I just learned that big time offsets can come in places least expected. Twice
> over the last three weeks an otherwise well-behaved Sun Netra X1 with Solaris
> 8 experienced a sudden change of its sytem time to exactly 100 years into the
> past, to January 1904 (while it was running). It though that at that time it
> was daylight saving time, so the time stamps in the syslogs were one hour off
> (syslog does not print the year, unfortunately). Only one service immediately
> suffered from this, ISC BIND 9, which started to generate assert failures.
> Ntpd would still serve out the (wrong) time to anyone who asked, so my other
> Netra, which synchronizes to the former one got this in the ntpd log:
> 
> 22 Jan 04:32:57 ntpd[7610]: time correction of -1008276352 seconds exceeds
> sanity limit (1000); set clock manually to the correct UTC time.
> 
> (which is about 36 years, maybe -100 mod 136 ?)
> 
> There were no log messages from ntpd itself (which synchronized to a local DCF
> clock and a few external servers).
> 
> It was not trivial to set the time back to a correct value. "date" cannot
> handle such large corrections, but ntpdate took care of the rest:
> 
> Jan 22 09:03:20 ntpdate[305]: [ID 702911 daemon.notice] step time server
> 129.132.2.21 offset -1139207214.011402 sec
> 
> (which is about 36 years)
> 
> I don't know what caused the problem. The value of exactly 100 years suggests
> some left-over of the Y2K problem. But the recent discussion in this group
> with the magical 34 years made me think about 1970+34 = 2004. Is it
> conceivable that ntpd itself had something do to with this? I rather doubt it.
> 
> Roman Maeder



More information about the questions mailing list