Peter Woo asked:
I’ve got the following in /var/log/syslog, from yesterday (July 30th)
Dec 16 22:54:05 omap ntpdate: step time server 18.104.22.168 offset 12052648.821465 sec
ntpdate 22.214.171.124 “corrected” my clock from July 30th to December 16th! According to http://www.pool.ntp.org/scores/126.96.36.199, that server was not off by more than 2ms.
Now, I do have a script which calls the
date command when the system boots in order to set the clock with ~1s accuracy. Coarse time is read from a local network, and
date is called to set the time. I have to do something along these lines since the system has no real time clock, and an Internet connection might not be available for NTP.
I’m not sure how Linux guesses the initial time when there is no clock available, but I’ve observed that it can be very wrong (which is reasonable). My only thought on what happened is:
- The system booted and initialized the clock to something way off, say March 15th
ntpdatebegan talking to the NTP server, determining how wrong March 15th is compared to the real date
- My script set the system’s clock to July 30th
ntpdatedetermined that the clock was 12052648s slow, and added the correction, assuming the clock was still on March 15th
- 12052648s was actually added to July 30th, bringing the clock to December 16th.
Frankly I’m not too familiar with how NTP works. Is the above reasonable? Could there be another explanation?
Without knowing more about your setup, your theory sounds plausible.
You will want to change your startup scripts to ensure that your
date command which sets the system date is complete before
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.