How quickly is CRON triggered?

Question

First Example

Suppose I have a CRON job

 30 2 * * * ....

Then this would run every time when it is 2:30 at night (local time).

Now suppose I have the time zone Europe/Germany and it's 2017-10-29 (the day when DST is switched). Then this CRON job would run twice, right?

Second Example

Suppose I have the time zone Europe/Germany and the CRON job

 30 11 * * * ....

As Germany never had a DST change at 11:30, this will not interfere. But the user could change the local time. To be super clear: This question is NOT about DST.

For the following test cases, I would like to know if/how often the CRON job gets scheduled:

1. At 11:29:58.0, the user sets the time to 11:31:00
2. At 11:29:59.1, the user sets the time to 11:31:00
3. At 11:29:59.6, the user sets the time to 11:31:00
4. At 11:30:01.0, the user sets the time to 11:29:59.7 - is CRON executed directly afterwards?

They boil down to How quickly is CRON triggered?, where the 4th one also has the question if CRON stores that it was already executed for that minute.

Another variant of the same question:

5. At 11:29:59, the NTP service corrects the time to 11:31:00 - will the job be executed that day at all?

Answer 1

The easiest way to answer this with confidence is to take a look at the source for the cron daemon. There are a few versions online like this, or you can use apt-get source cron.

The tick cycle in cron is to repeatedly sleep for a minute, or less if there is a job coming up. Immediately after emerging from the sleep, it checks the time and treats the result as one of these wakeupKind values:

• Expected time - run any jobs we were expecting
• Small jump forwards (up to 5 minutes) - run the jobs for the intervening minutes
• Medium jump forwards (up to 3 hours, so this would include DST starting in spring) - run any wildcard jobs first (because the catch up could take more than a minute), then catch up on the intervening fixed time jobs
• Large jump (3 hours or more either way) - start over with the current time
• Jump backwards (up to 3 hours, so including the end of DST) - because any fixed time jobs have 'probably' already run, only run any wildcard jobs until the time is caught up again

If in doubt, the source comments these wakeupKind values clearly.

---

Edit

To follow up on whether sleep() could be affected by a clock change, it looks like the answer is indirectly there in a couple of the Linux man pages.

• Firstly the notes for the sleep() function confirm that is implemented by nanosleep()
• The notes for nanosleep() say Linux measures the time using the CLOCK_MONOTONIC clock (even though POSIX.1 says it shouldn't)
• Scroll down a bit in the docs for clock_settime() to see the explanation of CLOCK_MONOTONIC, which explains it is not affected by jumps in the system time, but it would be affected by incremental NTP style clock sync adjustments.

So in summary, a system admin style clock change will have no effect on the sleep(). But for example if an NTP adjustment came in and said to 'gently' advance the clock, cron would experience a series of slightly short sleep() function calls.

Answer 2

There are many implementations of cron systems (See here). One of the most commonly used cron's is Vixie cron. And its man page states:

Daylight Saving Time and other time changes

Local time changes of less than three hours, such as those caused by the Daylight Saving Time changes, are handled in a special way. This only applies to jobs that run at a specific time and jobs that run with a granularity greater than one hour. Jobs that run more frequently are scheduled normally.

If time was adjusted one hour forward, those jobs that would have run in the interval that has been skipped will be run immediately. Conversely, if time was adjusted backwards, running the same job twice is avoided.

Time changes of more than 3 hours are considered to be corrections to the clock or the timezone, and the new time is used immediately.

_{source: man 8 cron}

I believe this answers most of your points.

In addition to point five:

5. At 11:29:59, the NTP service corrects the time to 11:31:00 - will the job be executed that day at all?

First of, if NTP corrects the time with more then a minute, you have a very bad clock! This should not happen too often. Generally, you might have such a step when you enable NTP but then it should be much less.

In any case, if the DeltaT is not to high, generally below 125 ms, your system will slew the time. Slewing the time means to change the virtual frequency of the software clock to make the clock go faster or slower until the requested correction is achieved. Slewing the clock for a larger amount of time may require some time, too. For example standard Linux adjusts the time with a rate of 0.5ms per second.

This implies, (under the assumption of Vixie cron, and probably many others):

• If NTP jumps more then 3 hours, the job is skipped
• If NTP jumps less then 3 hours but more then 125 ms, Vixie cron handles the job nicely by assuming the concepts of the time-jumps.
• If NTP corrects the time for less then 125 ms, cron does not notice the time-jump due to the slewing.

---

Interesting information:

• RFC5905: Network Time Protocol Version 4: Protocol and Algorithms Specification
• The NTP FAQ and Howto
• https://wiki.gentoo.org/wiki/Cron/en