[ntp:questions] Re: NTP and Cron
Richard B. Gilbert
rgilbert88 at comcast.net
Tue Nov 30 14:28:50 UTC 2004
Steven Hajducko wrote:
>Is it possible for NTP to reset the time back enough that cron will fire off
>I realize it's poor programming in whatever jobs we have running that they
>don't check if they're already running, but that is out of my hands. The
>issue that was given to me was to write a monitoring script around it
>happening again. I'd instead like to make sure that NTP can't do that. Do
>you have to specify a threshold for time increments and if so, is it
>possible to set the time increments to be under 1 second ( or is this the
>default already? )
>In our log, we have the following:
>Nov 23 08:55:25 xeon xntpd: time reset (step) 14.427314 s
>And afterwards, the log goes on to show one of the jobs firing off, again.
>I'm not exactly sure this IS the issue, as I don't see how it could have set
>off another cronjob, being that 14 second step would have simply gone to
>8:55:11, or if that timestamp is after the step, then 8:55:39 and since cron
>only goes by a minimum of minutes, well...
>But I'd like to clear up the issue so I can present it to them. So is it
>possible for NTP to reset the time in a big enough increment that it could
>make cron fire off a job twice? And if so, are there ways to prevent that?
What you are are describing is not supposed to happen! I find it
difficult to believe that a properly working ntp setup would allow the
time to get out of synch by 14 seconds. If it did, somehow, get that
far off it would step but the step you cite is in the positive
direction; it is setting the clock ahead, not back, and cron should not
see the same time twice.
Please provide some more details. "cron jobs" suggests some Unix or
Linux variant but which one? Which version of the NTP software are you
running? On the chance that NTP is not properly configured, would you
consider posting your ntp.conf file? What options are you specifying
when you start ntpd?
Finally, assuming that ntp stepping the clock in either direction caused
the problem, I fail to see how a "monitoring script" could prevent a
recurrence! You might be able to detect a large clock step but you
would probably be too late to prevent a second instance of a job from
I believe the most effective prevention would be to locate the error
that caused the clock step and prevent a recurrence of that!
More information about the questions