This can be tested by shifting the entry in /etc/crontab, for cron.daily, ahead one hour. which, FWIW, is what I recently did thinking it would fix the double run on shift from daylight to standard time. Shifting the cron.daily from 02:02 to 03:02 resulting in a run at 2:20, because /usr/sbin/run-crons deletes the file in /var/spool/cron/lastcron during its scheduled run at 2:10, and at 2:20, seeing no spool/cron/lastrun/cron.daily it runs. This deletion happens by the run-crons script, not by the cronjob that runs `rm -f /var/spool/cron/lastrun/cron.daily` The run-crons script will do the same thing on a shift from daylight time to standard time. Once a year, the cron.daily scripts will run twice, no matter what time the entry in /etc/crontab suggests will happen. Fixed here by editing the lines in the run-crons script that check the age and delete "stale" entries in /var/spool/cron/lastcron. I added 60 minutes to all four (hourly, daily, weekly, and monthy) so a one hour time change (either external or by /etc/crontab change) does not result in double run. Just by way of example of fix, for the "case" of cron.daily, "TIME="-cmin +1445" ;;" was changed to "TIME="-cmin +1505" ;;"
This bug is old enough to drive. *** This bug has been marked as a duplicate of bug 69777 ***
LOL. I see. Wow. Well, I'll deal with the script my way then, and it looks like whoever is in charge of it is entrenched, so there is no risk my fix will be overwritten. The "computer off" rationale that was provide in the other bug doesn't hold water. If the "remove stale entries" logic is modified to a one hour longer timeframe to deal with DST, the files still age while the computer is off and the cronjobs will run when the computer is brought back up (as well as at the scheduled time). I understand this still results in double run, but it resolves the double run issue for those of us running 24/7 systems.
