On Sun, Nov 04, 2012 at 04:36:02PM +0200, Alan McKinnon wrote:
> On Sun, 4 Nov 2012 08:58:54 -0500
> Michael George <geo...@mutualdata.com> wrote:
>
> > Last night was our change from EDT to EST. So we went through the
> > 1am-2am hour twice. My crontab has the following:
> >
> > # for vixie cron
> > # $Header:
> > # /var/cvsroot/gentoo-x86/sys-process/vixie-cron/files/crontab-3.0.1-r4,v
> > # 1.3 2011/09/20 15:13:51 idl0r Exp $
> >
> > # Global variables
> > SHELL=/bin/bash
> > PATH=/sbin:/bin:/usr/sbin:/usr/bin
> > MAILTO=root
> > HOME=/
> >
> > # check scripts in cron.hourly, cron.daily, cron.weekly and
> > cron.monthly 59 * * * * root rm
> > -f /var/spool/cron/lastrun/cron.hourly 9 3 * * * root rm
> > -f /var/spool/cron/lastrun/cron.daily 19 4 * * 6 root rm
> > -f /var/spool/cron/lastrun/cron.weekly 29 5 1 * * root rm
> > -f /var/spool/cron/lastrun/cron.monthly */10 * * * * root test
> > -x /usr/sbin/run-crons && /usr/sbin/run-crons
> >
> > So the cron.daily file should be removed at 3:09am -- it should only
> > run once as the 2am-forward time only occurred once.
> >
> > However, this morning I have two sets of email from my daily jobs
> > running. At this time:
> >
> > Date: Sun, 4 Nov 2012 02:20:05 -0500 (EST)
> >
> > and this time:
> >
> > Date: Sun, 4 Nov 2012 03:10:04 -0500 (EST)
> >
> > Why would it have run twice?
>
>
> This is clearly documented in the man pages for Vixie cron.
>
> cron is utterly unaware of the vagaries and stupidities that humans get
> up to recording the passage of time. If your crontab is this:
>
> 0 0 * * * <something>
>
> then when the clock says it is 0 minutes past the 0 hour, the cron will
> run.
>
> That time happened twice. Therefore the cron ran twice.
>
> You can't really blame cron for not picking up that an event that is
> guaranteed to happen once in a period actually happened twice in a
> period. There comes a time when a developer has to step back and say
>
> "To hell with that, it's out of contract spec and actually not my
> problem!"
>
> There are other crons that avoid this problem by taking a completely
> different approach. You configure them by declaring you want a job to
> run in a given period of time. When daylight saving kicks in, it sees a
> job has already run and doesn't do it again. But you have to lose the
> ability to specify the exact time a job must run at to do it this way.
Actually, checking the page for cron(8) of vixie-cron, we see this:
Daylight Saving Time and other time changes
Local time changes of less than three hours, such as those
caused by the start or end of Daylight Saving Time, are handled
specially. This only applies to jobs that run at a specific
time and jobs that are run with a granularity greater than one
hour. Jobs that run more frequently are scheduled normally.
If time has moved forward, those jobs that would have run in the
interval that has been skipped will be run immediately.
Conversely,
if time has moved backward, care is taken to avoid running jobs
twice.
Time changes of more than 3 hours are considered to be corrections
to the clock or timezone, and the new time is used
immediately.
So it seems that DST changes are accommodated. Is there some
side-effect of the cron.<period> method of scheduling tasks that I'm
overlooking?
--
-M
Rident stolidi verba Latina.
-Ovid
