[gentoo-user] Daylight time change and cron run twice

[Michael George]

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?

--
-M

Rident stolidi verba Latina.
-Ovid

[Alan McKinnon]

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.


--
Alan McKinnon
alan.m...@gmail.com

[Michael George]

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.

What am I missing?

[Michael George]

On Sun, Nov 04, 2012 at 04:36:02PM +0200, Alan McKinnon wrote:

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?

[Michael Orlitzky]

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:

https://bugs.gentoo.org/show_bug.cgi?id=69777

[Michael George]

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?

[Michael Orlitzky]

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 '{}' \;

[Dale]

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

/etc/cron.d:

/etc/cron.daily:
hplip_cron logrotate.cron makewhatis mlocate

/etc/cron.hourly:

/etc/cron.monthly:

/etc/cron.weekly:
pfl
root@fireball / #

Thanks much.

Dale

:-) :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

[Michael Orlitzky]

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.

[Dale]

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