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:
> 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.
Well, this is what I initially thought would happen. However, my
crontab indicates that cron.daily would be removed at 3:09am. But at
2am EDT, the time changed back to 1am EST, never having reached 3:09am
EDT. Then after an hour it would be 2am EST, or "2am again". See here:
http://www.webexhibits.org/daylightsaving/b2.html
But 3:09am would never have been reached last night during EDT, only at
EST, so I don't expect something after 3am would ever suffer from the
change.
> > 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.
> > 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?
> 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.
> ...
> 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?
The run-crons script is triggered every ten minutes, and so avoids the
special handling. But the script is broken, and has been so forever:
On Sun, Nov 04, 2012 at 06:36:50PM -0500, Michael Orlitzky wrote:
> On 11/04/2012 03:16 PM, Michael George wrote:
> > 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.
> > ...
> > 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?
> The run-crons script is triggered every ten minutes, and so avoids the
> special handling. But the script is broken, and has been so forever:
I'm surprised that hasn't been fixed by now. Looking at the cron guide
(https://bugs.gentoo.org/show_bug.cgi?id=69777), is bcron subject to the
same problem because the run-crons script is in cronbase and not part of
the cron daemon?
> On Sun, Nov 04, 2012 at 06:36:50PM -0500, Michael Orlitzky wrote:
>> On 11/04/2012 03:16 PM, Michael George wrote:
>>> 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.
>>> ...
>>> 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?
>> The run-crons script is triggered every ten minutes, and so avoids the
>> special handling. But the script is broken, and has been so forever:
> I'm surprised that hasn't been fixed by now. Looking at the cron guide
> (https://bugs.gentoo.org/show_bug.cgi?id=69777), is bcron subject to the
> same problem because the run-crons script is in cronbase and not part of
> the cron daemon?
I think all of them are, out-of-the-box. I just commented on the bug. I
think the sensible thing to do is delete the time-management code in the
run-crons script. It's only there as a half-assed attempt to run your
missed jobs after a reboot, which fcron (and maybe others) does properly.
If you don't want to mess with run-crons, you could just replace the
stuff in /etc/crontab. All you really need is one command per line that
does (untested),
find "/etc/cron.${PERIOD}" -type f -executable -exec bash '{}' \;
Michael Orlitzky wrote:
> On 11/06/2012 06:24 AM, Michael George wrote:
>> On Sun, Nov 04, 2012 at 06:36:50PM -0500, Michael Orlitzky wrote:
>>> On 11/04/2012 03:16 PM, Michael George wrote:
>>>> 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.
>>>> ...
>>>> 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?
>>> The run-crons script is triggered every ten minutes, and so avoids the
>>> special handling. But the script is broken, and has been so forever:
> I think all of them are, out-of-the-box. I just commented on the bug. I
> think the sensible thing to do is delete the time-management code in the
> run-crons script. It's only there as a half-assed attempt to run your
> missed jobs after a reboot, which fcron (and maybe others) does properly.
> If you don't want to mess with run-crons, you could just replace the
> stuff in /etc/crontab. All you really need is one command per line that
> does (untested),
> find "/etc/cron.${PERIOD}" -type f -executable -exec bash '{}' \;
Well, I'm medicated so pardon me if I get silly. What is the BEST cron
to use? I'm using vixie-cron since that is what was in the handbook
during my install. Let's not get into how long ago that was. lol So,
what cron has . . . well. . . the least issues and is more developed?
Oh, would I need to reemerge anything to get the stuff updated? Things
like logrotate and such? I also couldn't find any USE flags for it
either. I know these use cron:
root@fireball / # ls -R /etc/cron*
/etc/cron.deny /etc/crontab
> Well, I'm medicated so pardon me if I get silly. What is the BEST cron
> to use? I'm using vixie-cron since that is what was in the handbook
> during my install. Let's not get into how long ago that was. lol So,
> what cron has . . . well. . . the least issues and is more developed?
> Oh, would I need to reemerge anything to get the stuff updated? Things
> like logrotate and such? I also couldn't find any USE flags for it
> either. I know these use cron:
I use vixie-cron, its most important feature being that it scans
/etc/crontab automatically so I don't have to remember to run `crontab
/etc/crontab` every time I make a change to it.
Fcron was aimed at being a vixie-cron replacement, but it doesn't
automatically scan /etc/crontab. It does allow you to run missed jobs,
though. Personally, if I want my cron jobs to run, I don't turn the
machine off.
Dcron is also probably also pretty good, since it was written by Matt
Dillon (of Dragonfly BSD fame).
If you switch away from vixie-cron, you might need to run `crontab
/etc/crontab` once unless the ebuild does it for you. Otherwise, all the
cron daemon does is invoke the run-crons script which does the real work.
Michael Orlitzky wrote:
> On 11/06/2012 09:29 AM, Dale wrote:
>> Well, I'm medicated so pardon me if I get silly. What is the BEST cron
>> to use? I'm using vixie-cron since that is what was in the handbook
>> during my install. Let's not get into how long ago that was. lol So,
>> what cron has . . . well. . . the least issues and is more developed?
>> Oh, would I need to reemerge anything to get the stuff updated? Things
>> like logrotate and such? I also couldn't find any USE flags for it
>> either. I know these use cron:
> I use vixie-cron, its most important feature being that it scans
> /etc/crontab automatically so I don't have to remember to run `crontab
> /etc/crontab` every time I make a change to it.
> Fcron was aimed at being a vixie-cron replacement, but it doesn't
> automatically scan /etc/crontab. It does allow you to run missed jobs,
> though. Personally, if I want my cron jobs to run, I don't turn the
> machine off.
> Dcron is also probably also pretty good, since it was written by Matt
> Dillon (of Dragonfly BSD fame).
> If you switch away from vixie-cron, you might need to run `crontab
> /etc/crontab` once unless the ebuild does it for you. Otherwise, all the
> cron daemon does is invoke the run-crons script which does the real work.
It looks like each has its good and bad points. Since I would likely
forget to update it when I change something to, I guess I'll stick with
vixie. I was thinking about switching but that could just cause another
problem. So, I would have a problem either way. May as well stay where
I am with a problem I know. lol
Dale
:-) :-)
-- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
