5

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?

3
  • How is ntpdate getting called? Your combination of ntpdate and date script is extremely odd. As Vortaq points out, using ntpd is the "normal" thing to do, using ntpdate in any script (boot or otherwise) is not normal or recommended. It's meant to be an administrative stop-gap, so you can force the clock to sync to a given timeserver manually.
    – Chris S
    Jul 31, 2012 at 21:41
  • You really should only have a single time sync tool running on your system. Having multiple tools always results in lots of badness in my experience. For the best results you should go with a full implementation of NTPd unless you need something more precise.
    – Zoredache
    Jul 31, 2012 at 22:36
  • Thanks for the tips. It appears to have been scheduled by my distro on installation. I've since purged NTP from the system -- unfortunately, if there be only one clock manager, it must be the initialization script which pulls time from another device on the local network.
    – Peter Woo
    Jul 31, 2012 at 23:22

3 Answers 3

4

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.

6

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

3
  • 1
    The date command shouldn't hurt in the least if it's called before ntpd gets started.
    – Chris S
    Jul 31, 2012 at 21:39
  • voretaq7: would love to get rid of it, unfortunately this is an embedded system and the constraints make it necessary (I'm not guaranteed external network access). Chris: I'd have expected some guard against date being invoked in the middle of the protocol, as read/increment/store is a classic threading problem. Maybe that's not possible, without NTP having kernel support...
    – Peter Woo
    Jul 31, 2012 at 21:47
  • @PeterWoo date operates independently of the NTP tools (you can adjust your clock with date while running ntpd -- you just shouldn't as this will really upset NTP) -- If you can't get rid of the date bits then adding a lock/test like Michael Hampton alludes to in his answer. (Of course if the thing that calls date is relying on some kind of local-network time server you can change your requirements to say "Must have a working NTP server available" instead of whatever that script uses too - Lots of options, you just need to figure out what works for your specific use case :-)
    – voretaq7
    Aug 1, 2012 at 3:27
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.

1
  • To be honest, I didn't even know ntpdate was in use on the system, and so never thought about using ntpd. It must have been set up by the distro at install.
    – Peter Woo
    Jul 31, 2012 at 21:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .