4

If NTP runs at 10:59:55, and fixes the time to 11:00:13, does chron run the 11:00:00, and *:00:00 tasks, or are they skipped?

Alternately, if NTP runs at 11:00:00 and fixes the time to 10:59:48, do these tasks run twice?

If they are skipped, what methods are used to fix this?

What about other schedulers (windows, etc)?

-Adam

1
  • 2
    You might note that there is a difference between running ntpd, which will attempt to introduce changes at the microsecond level so the problem you describe won't happen, and ntpdate, which updates the time in one go. The problem you describe can happen with ntpdate, which is why the "poor man's ntp" or running ntpdate out of cron is not a great solution.
    – jj33
    May 8, 2009 at 19:52

5 Answers 5

9

if you run a NTP daemon you will not have this problem, it will speed up/slow down your clock so it gets synchronized over time rather then jumping.

2

To the best of my understanding, the scheduled jobs shouldn't be skipped or run twice.

Cron uses an event list for it's scheduling, so if the time skips ahead, cron will simply see that job didn't run on time and run it during it's next wake cycle. If the time jumps back, the job will have been removed from the event list and cron won't see it as needing to be run again.

As Tjofras mentioned, ntpd will gradually adjust your clock using drift rather than a hard jump however, so you normally shouldn't see time jumps unless you manually change the system clock yourself.

1
  • I wouldn't assume that your jobs will be run until you've done some testing. So get a test machine, schedule a job and manually jump the time, both forwards and backwards, and see if the job is skipped or run twice.
    – pgs
    Jun 1, 2009 at 2:56
2

This depends on what you mean by NTP. If you are running the NTP time synchronization daemon (ntpd) with a reasonable configuration, then the time will never jump. The daemon continuously slews the system time toward actual time. It doesn't "run" at intervals: it queries its time sources at intervals simply to determine how much to slew the time. You will never see skipped time, nor will your time move backward in any detectible way.

The time will jump, however, if you are synchronizing via certain other means. For example, if you use a cron job to run ntpdate or ntpd -q (which you shouldn't do unless you have a very good reason and understand the possibll dire consequences), then your system time could instantaneously and wildly change each time this runs. The time could also jump when you first start ntpd, depending on how you have it configured.

Regarding Cron:

If the exact time that a cron job was supposed to run does not occur (is skipped) due to a time jump, then it simply will not run. It will run at the next interval for which it is scheduled.

If the exact time that a cron job was supposed to run occurs twice (the time jumps backward), then it will run both times.

To solve the cron problem, run ntpd as a service/daemon, thus ensuring that your time will never jump. If you manually jump the time, you will have to check all of your cron jobs to determine what did not run (or will run twice) and manually intervene.

Of course, the best solution is to solve the time problem. The cron problem is simply a symptom of the much more serious time jump issue, which can cause all sorts of problems beyond cron (logging, auditing, SELinux, etc...)

1

I've seen Backup Exec jobs in Windows fire off if the time gets changed. They especially don't like it when the time shifts back an hour.

1

As others have mentioned, running ntpd will prevent this problem, but if you have problems due to time skipping, you could make use of anacron. It's designed for use when a computer isn't up 24/7 and to run jobs asap, but I don't see why it wouldn't work in the situation you described.

You must log in to answer this question.

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