Is an ntpdate correction atomic?

I've got the following in /var/log/syslog, from yesterday (July 30th)

Dec 16 22:54:05 omap ntpdate[432]: step time server 91.189.94.4 offset 12052648.821465 sec

ntpdate 91.189.94.4 "corrected" my clock from July 30th to December 16th! According to http://www.pool.ntp.org/scores/91.189.94.4, 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:

1. The system booted and initialized the clock to something way off, say March 15th
2. ntpdate began talking to the NTP server, determining how wrong March 15th is compared to the real date
3. My script set the system's clock to July 30th
4. ntpdate determined that the clock was 12052648s slow, and added the correction, assuming the clock was still on March 15th
5. 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?

Solution 1:

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 ntpdate starts.

Solution 2:

I'm not certain how your clock got into the condition it's in, but may I suggest that you eliminate the script which calls the date command if possible?

The usual method for setting the system clock on startup on most systems I've worked with is:

1. Start the network.
2. Start ntpd with the -g to sync the clock.

^{-g is a new-ish option that lets ntpd step the clock to any time -- If your version of ntpd doesn't support that fkag you would run ntpdate -b some.time.server before you started the NTP daemon}

If your system is so old that it's doing something entirely different than this it's probably also so old that it's unsupported, so I would have no qualms about changing the startup scripts to be more sane...

Solution 3:

Why are you not using ntpd?

ntpd is much more efficient at making sure your clock is correct than ntpdate is because it buffers the update into smaller changes to avoid any kind of shock to the system.

And it definitely does not change your clock to a different month accidentally!

I would give more precise instructions on how to install and enable ntpd on your system, but you did not specify your distro.