NTP and Cron

[Elliott Moskowitz]

Is there anything magic that NTP (xntpd) does when it resets time backwards? Could it not cause a cron job to kick in twice ? For instance at 12:00:00 cron kicks of a job "A", and at 12:00:01 xntpd sets the time back 2.0 seconds.

When you change the system time with "date" the system warns you - I'm assuming for that very reason.

[Sanjay_6]

Hi Elliot,

I guess what you say is correct. Cron may repeat the sdame job, if the time resets backward.

Regds

[harry d brown jr]

As long as ntp is not "stepping" (doing an immediate time change), then NO, the same cron will not start twice. You would need to add the "-x" option to xntpd.

man pages of xntpd:

The good news is that NTP can be forced to never make a STEP, but instead SLEW the clock to drive the offset to zero. This is accomplished with the -x option on the command line. This effectively removes the middle operating regime. You won't get millisecond (or microsecond) precision with this method, but you probably can't get that over a WAN anyway.

It is important to note that SLEWING is a cover-up for a more fundamental problem (poor connection to the timesource), and it does not solve this problem. SLEWING is not recommended by HP because it causes reduced accuracy and stability, and it leads to anamolous behavior that can be quite confusing.

live free or die
harry

[John Payne_2]

NTP is a very basic protocal. It does not stop any services or anything. If the time gets changed back 30 minutes, you have the same problem. It just changes the time.

Are you running a driftfile? The driftfile will tell you the last correction and the timestamp. Then next time it happens, you can look at the driftfile and see that the time changed overlapping the cron job's time.

Format is an entry like this:

driftfile /etc/ntp.drift

Add a the ntp.drift file with an initial entry of '1' in the file...

John

[Craig Rants]

Elliot,
I am sure that it would kick off the job twice.
You may want to update your system time more often if you clock is fast and an update has to move the time back in big chunks.

C

[Bernie Vande Griend]

It is definitely possible for this to occur, unless the slewing option is used that Harry mentioned.

Because of that, we do not run xntpd, but instead use ntpdate to sync the time immediately. We do this at boot time and also have a cron job that does it twice a day. That way we can choose a time where setting the clock back or forward a few minutes does not have an impact.
I think it depends on how time sensitive your application and cron jobs are and the impact of them running more than once if the time was set back.

[Patrick Wallek]

I suppose it is possible for that to happen.

But, if you are running xntpd and the clock on your server is functioning fairly normally, xntpd should never have adjust the time that much.

I have been running xntpd on production servers for at least 2 years and I have never had anything like that happen.

[James R. Ferguson]

Hi Elliott:

Several comments.

First, 'xntpd' will adjust a server's time if the difference between it and its source time is greater than 1000 seconds. This prevents some measure of time insanity.

Second, time adjustments are made gradually in small increments. This too, lessens the kind of behavior about which you worry.

Thirdly, remember that the granularity of 'cron' jobs is one minute. This too, limits the periods of union for the behavior about which you worry.

Lastly, one a server's clock is synchronized, time is very stable. Afterall, that's the reason to run 'xntp' in the first place; to provide continuous, very small adjustments as necessary.

Regards!

...JRF...

[Elliott Moskowitz]

Harry D. Brown,

Even if the system "slews" a microsecond and doesn't "step", couldn't a cron job kick off twice ?

[Elliott Moskowitz]

James,

You mention in your second point that time adjustments are made gradually, are you referring to slewing like Harry. And where is this "-x" option in the manpages ?

The system that I was testing "stepped" the time back 2 seconds, something that I don't want to happen. I think "slewing" sounds like a better idea for me.

[harry d brown jr]

SLEWing refers to slowing down or speeding up the increments of time so that the clock doesn't jump back or forwards. The big issue would be when you set time backwards by many hours or even days, because the system could take that many number of hours/days to "catch up". It that case, you might as well shut the system down, and manually reset the clock. The problem again though would be that file dates would be hosed (into the future).

live free or die
harry

[Darrell Allen]

Hi Elliott,

NTP does a good job at what it's designed for: keep the time sync'ed with a time source. It should be most unusual for NTP to change the time enough to cause a cron job to run twice. Is it possible? Probably, in theory. I've used it in DCE and DFS environments which are rather particular about the time and had no problems.

Concerning the -x argument, we never used it. The man page for xntpd is rather interesting, particularly about slewing. According to the man page, xntpd usually operates in slewing mode anyway. This is because it usually keeps the time within 128 milliseconds of the time source. If off by 129 - 1000 msecs, xntpd will step. That might occur at boot. Above 1000 msecs, xntpd will shutdown because it assumes the time is so far off human intervention is needed.

Darrell

[A. Clay Stephenson · Accepted solution]

Hi Elliott:

You will not see the -x xntpd option unless you are running 11x. I tend to agree with your assessment that slewing is exactly what you want in spite of the man pages warning. The last thing I want to happen (other than very early in the boot process) is to step the time backwards. Cronjobs are the least of your worries. The real problems are timestamps especially in databases. You can easily get into the situation where a transactions with a higher sequence number have an earlier datastamp because something was monkeying with the time. It is far better to 'slow' the system clock until 'real' time catches up which is just what 'slewing' does. Stepping time backwards can also mess up deveopment machine so that objects and executables appear inconsistant with the source files so that makes behave very strangely.

[James R. Ferguson]

Hi Elliott:

Take a look at the recent man pages for 'xntpd':

http://docs.hp.com/hpux/onlinedocs/B2355-90692/B2355-90692.html

There is the discussion of the SLEW mechanism and what constitutes STEP. I think once time is synchronized and the 'xntpd' daemon isn't interrupted, all will be well. I don't run with the slewing (-x) option.

Regards!

...JRF...

[Darrell Allen]

Oops, made a mistake in my previous post. Where I refer to 1000 milliseconds it should have been 1000 seconds.

I knew I should have copied and pasted that info but it just doesn't paste pretty in this dang small window!

Darrell