The answer lies in the cron sources (which you can get by apt-get source cron
),
particularly in the main loop at lines 159--272 of file cron.c
.
crond
sleeps for a minute, then wakes up and queries the
system time, comparing it to its own idea of time (i.e., what time it
would be if nothing altered the clock). Based on the difference
between the actual and the expected time, crond
takes different
actions; two of them are relevant in your case:
Time has leaped forward more than 5 minutes but less than 3 hours
(DST starts): cron runs wildcard jobs scheduled at the actual time,
and any job scheduled at a fixed time between the computed time and
the actual time. Relevant source is at lines 221--247:
/*
* case 2: timeDiff is a medium-sized positive number,
* for example because we went to DST run wildcard
* jobs once, then run any fixed-time jobs that would
* otherwise be skipped if we use up our minute
* (possible, if there are a lot of jobs to run) go
* around the loop again so that wildcard jobs have
* a chance to run, and we do our housekeeping
*/
Debug(DSCH, ("[%d], DST begins %d minutes to go\n",
getpid(), timeRunning - virtualTime))
/* run wildcard jobs for current minute */
find_jobs(timeRunning, &database, TRUE, FALSE);
/* run fixed-time jobs for each minute missed */
do {
if (job_runqueue())
sleep(10);
virtualTime++;
find_jobs(virtualTime, &database, FALSE, TRUE);
set_time();
} while (virtualTime< timeRunning &&
clockTime == timeRunning);
break;
Time has gone backwards less than 3 hours (DST ends): just run
wildcard jobs, skip fixed-schedule jobs since they have already
run. Relevant source is at lines 247--258:
/*
* case 3: timeDiff is a small or medium-sized
* negative num, eg. because of DST ending just run
* the wildcard jobs. The fixed-time jobs probably
* have already run, and should not be repeated
* virtual time does not change until we are caught up
*/
Debug(DSCH, ("[%d], DST ends %d minutes to go\n",
getpid(), virtualTime - timeRunning))
find_jobs(timeRunning, &database, TRUE, FALSE);
break;
So, when entering DST, you should have no problem: your script will be
run (either just before, or immediately after the time leap).
When exiting DST, there is a risk that your (fixed-time) job will be
skipped, if you schedule it exactly at 1 o'clock. My suggestion
would be to schedule the run either 1 minute before 1 o'clock,
or at 2 o'clock (or after).