Time synchronization and scheduled tasks

Solution 1:

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.

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

Solution 3:

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

Solution 4:

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.

Solution 5:

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.