Is an ntpdate correction atomic?

Peter Woo asked:

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

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

ntpdate “corrected” my clock from July 30th to December 16th! According to, 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?

My answer:

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.

View the full question and any other answers on Server Fault.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.