daylight saving time messes up cron

[Miek Gieben]

I've scheduled my backups so that they are performed between 2 and 3 o' clock at night.

Now tonight we (CET) to summertime. So we move one hour forward and skip the hour between 2 and 3.

Cron doesn't know about this and therefor did not run my backup cronjobs this night.

I don't know if this is fixeable in cron or that some other solution must be
sought.

[Miek Gieben (miek)]

I've scheduled my backups so that they are performed between 2 and 3 o' clock at night.

Now tonight we (CET) to summertime. So we move one hour forward and skip the hour between 2 and 3.

Cron doesn't know about this and therefor did not run my backup cronjobs this night.

I don't know if this is fixeable in cron or that some other solution must be
sought.

[Miek Gieben (miek)]

When CRON is run with full debugging (needs a recompile) and you force the
time one hour forwards, it sure sees that DST is in effect and runs it's jobs. But it only seems to run the wildcard jobs... hmmm

[18857] TargetTime=1144824600, sec-to-wait=60
[18857] load_database()
[18857] system dir mtime unch, check files now.
        /etc/cron.d/anacron: [checked]
        /etc/cron.d/test: [checked]
[18857] spool dir mtime unch, no load needed.
[18857], DST begins 56 minutes to go
[18857] tick(45,9,11,3,3) Wildcard only
user [root:0:0:...] cmd="test -x /usr/sbin/anacron || run-parts --report /etc/cron.monthly"
user [root:0:0:...] cmd="test -x /usr/sbin/anacron || run-parts --report /etc/cron.weekly"
user [root:0:0:...] cmd="test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily"
user [root:0:0:...] cmd=" run-parts --report /etc/cron.hourly"
user [root:0:0:...] cmd="test -x /etc/init.d/anacron && /usr/sbin/invoke-rc.d anacron start >/dev/null"
user [root:0:0:...] cmd="/home/miekg/cronsh"
[18857] do_command(/home/miekg/cronsh, (*system*test,0,0))
[18864] child_process('/home/miekg/cronsh')
[18857] main process returning to work
[18865] grandchild process Vfork()'ed
log_it: (root 18865) CMD (/home/miekg/cronsh)
[18864] child continues, closing pipes
[18864] child reading output from grandchild
[18864] got data (64:d) from grandchild
[18864] closing pipe to mail
log_it: (root 18864) MAIL (mailed 83 bytes of output but got status 0x0001)

[Miek Gieben (miek)]

I have a cron job that starts every 2 minutes after the hour
2 * ... ...

when DST is in effect, cron does:

cron.c: line 220:

/* run wildcard jobs for current minute */
find_jobs(timeRunning, &database, TRUE, FALSE);

this should match my cron, but it gets started at the wrong minute, so
it missing my cron job.

Next: cron.c: line 222:
/* run fixed-time jobs for each minute missed */
do {
        if (job_runqueue())
                sleep(10);
        virtualTime++;
        find_jobs(virtualTime, &database, FALSE, TRUE);
        set_time();
        ...

Now all cron jobs get run without any wildcards (FALSE, TRUE), so my
2 minute after the hour cron is missed:
(i've added some debugging):
## = my comments

[19419] tick(2,10,11,3,3) No wildcard
user [root:0:0:...] cmd="test -x /usr/sbin/anacron || run-parts --report /etc/cron.monthly"
user [root:0:0:...] cmd="test -x /usr/sbin/anacron || run-parts --report /etc/cron.weekly"
user [root:0:0:...] cmd="test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily"
user [root:0:0:...] cmd=" run-parts --report /etc/cron.hourly"
user [root:0:0:...] cmd="test -x /etc/init.d/anacron &&
/usr/sbin/invoke-rc.d anacron start >/dev/null"
user [root:0:0:...] cmd="/home/miekg/cron2sh"
not adding
flags 13
## this cron2sh should have been added because we on minute 2: tick(2, ...)
## but it isn't, flags is 0x13 indicating that wildcards are in effect
user [root:0:0:...] cmd="/home/miekg/cronsh"
not adding
flags 1b

cron.c: line 347
if ((doNonWild && !(e->flags & (MIN_STAR|HR_STAR)))
                || (doWild && (e->flags &
                                (MIN_STAR|HR_STAR)))) {
        job_add(e, u);

because doWild is FALSE the 'or' statement in the 'if' isn't executed
and the job isn't added.

I don't know what effect making doWild true has on the rest of CRON,
but it could be a fix.

[Miek Gieben (miek)]

This patch seems to fix the case when DST is enabled, i.e going forward
in time. I'll check what happens when we go back.

[Miek Gieben (miek)]

I've done some investigation to why this happens to cron.
Currrently I have patch for when DST is enabled.

Everything is documented in:
https://launchpad.net/malone/bugs/36690

--
grtz,
  - Miek

  http://www.miek.nl http://www.nlnetlabs.nl
  PGP: 6A3C F450 6D4E 7C6B C23C F982 258B 85CF 3880 D0F6

[Miek Gieben (miek)]

Normal cron without time changes, still seem to work:
[1072] tick(2,10,12,3,4) user [root:0:0:...] cmd="test -x /usr/sbin/anacron || run-parts --report /etc/cron.monthly"
user [root:0:0:...] cmd="test -x /usr/sbin/anacron || run-parts --report /etc/cron.weekly"
user [root:0:0:...] cmd="test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily"
user [root:0:0:...] cmd=" run-parts --report /etc/cron.hourly"
user [root:0:0:...] cmd="test -x /etc/init.d/anacron && /usr/sbin/invoke-rc.d anacron start >/dev/null"
user [root:0:0:...] cmd="/home/miekg/cron2sh"
[1072] do_command(/home/miekg/cron2sh, (*system*test,0,0))
[1680] child_process('/home/miekg/cron2sh')

[Miek Gieben (miek)]

Sadly, this bug is *still* there. It's 30 March 2008 and DST was enabled last night. Any crons I had scheduled between 2 and 3 haven't run.
(I was expecting this ofcourse, but still)

[Justin Pryzby (justinpryzby-users)]

merge 217836 458123 474157
tag 474157 fixed-upstream
thanks

On Tue, Apr 01, 2008 at 10:21:30AM +0400, Petya Kohts wrote:
> Jobs scheduled to run between 1 and 2 am
> are not run when time moves forward
> for 1-3 hours (at the beginning of DST) and
> are run twice when time moves backward
> for 1-3 hours (at the end of DST).
>
> Included is the patch against current trunk.
Thanks for reporting. It seems to be the same as bug#217836. Can you
describe the derivation of your patch? It seems to be applied to
upstream cron code in version 4.1 from ISC.

I'm a bit confused about the state of DST handling; there was a patch
applied in Debian revision -53, but the patch is large (and combined
with other changes) so the (intended) effect of the changes aren't
entirely clear to me. As I recall, that patch also seemed to have
been applied in the ISC release.

Steve, do you recall what this patch was supposed to do? Where can I
find the openbsd diff (just looked, without success).

[Serge (serge-de-souza)]

The patch seems to totally ignore jobs in this format:

59 1 * * * date >> /tmp/ran.59.1.$$

[Paul Slootman (paul-wurtel)]

On Mon 27 Oct 2003, Mark Ferlatte wrote:

> Package: cron
> Version: 3.0pl1-72
>
> Jobs scheduled to run between 1 and 2 am get run twice when the machine in
> question is in the Pacific timezone. I don't believe that this is correct
> behavior.

This is _still_ a problem in 3.0pl1-100, as I just watched it happen
(CEST -> CET end of daylight savings time).
If there has been a patch for 2 years, and it's confirmed fixed upstream
for half a year now, why is there not a fixed version in Debian?

Paul Slootman

[Laurens (laurensb)]

found 217836 3.0pl1-105
severity 217836 important

The bug also still occurs in version 3.0pl1-105 in testing (Lenny).

This bug has been reported 5 years ago! Please apply patch ASAP.

Laurens

[Laurens (laurensb)]

found 217836 3.0pl1-105
severity 217836 important
thanks

[Javier Fernández-Sanguino (jfs)]

On Sun, Oct 26, 2008 at 02:20:50AM +0100, Paul Slootman wrote:
> If there has been a patch for 2 years, and it's confirmed fixed upstream
> for half a year now, why is there not a fixed version in Debian?

The patch submitted to Ubuntu has not been included upstream. The patch at
Launchpad has not been (to my knowledge tried widely) and I'm not going to
introduce it in Debian's cron.

Actually, this is set as 'fixed upstream' because a fix was already
introduced to fix the "duplicate jobs being run" issue.

The fix, however, does not work in all cases. Reportedly, it does not work
when wildcards are in use. I still don't have a patch for that issue.

Regards

Javier

[Paul Slootman (paul-debian)]

On Sun 26 Oct 2008, Paul Slootman wrote:
>
> This is _still_ a problem in 3.0pl1-100, as I just watched it happen
> (CEST -> CET end of daylight savings time).

And tonight I've noticed that at the start of daylight savings time
CET -> CEST that jobs scheduled between 2:00 and 3:00 are not run at
all, in blatant conflict with the manpage which explicitly states that
cron _will_ take this into account.

This is observed with 3.0pl1-105.

If you're not going to fix this DST mess, at least change the manpage to
document the way it's working!

Paul Slootman

[Launchpad Janitor (janitor)]

This bug was fixed in the package cron - 3.0pl1-113ubuntu1

---------------
cron (3.0pl1-113ubuntu1) maverick; urgency=low

  * Merge from debian unstable. Fixes:
    - LP: #46493 (this should have been fixed way back in 3.0pl1-87, and I
      confirmed it is no longer a problem)
    - LP: #118168 (Debian #79037)
    - LP: #151231 (Debian #155109, #443615)
    - LP: #308341 (Debian #437180)
  * Remaining changes:
    - debian/control:
      + Build-Depends on debhelper >= 7.3.15ubuntu2, for Upstart
      + Drop MTA and lockfile-args to Suggests
    - add debian/cron.upstart
    - debian/postinst: remove calls to update-rc.d, invoke-rc.d and
      /etc/init.d/cron
    - debian/postrm: remove call to update-rc.d
    - debian/prerm: remove calls to invoke-rc.d and /etc/init.d/cron
    - debian/rules: install Upstart job
  * Drop the following changes, now in debian:
    - popen.c: check return code of initgroups() in cron_popen()
    - debian/control: add missing ${misc:Depends}
    - debian/control: Depends bump on lsb to >= 3.2.12ubuntu2. No longer
      required now that we use Upstart
    - debian/cron.pam: switch from including common-session to including
      the new common-session-noninteractive
    - pathnames.h: use sensible-editor

cron (3.0pl1-113) unstable; urgency=medium

  [ Christian Kastner / Javier Fernandez-Sanguino ]
  * debian/postinst:
    - Now that permissions and ownership of crontabs are changed unconditionally,
      do not attempt to chown user crontabs if none are present. Closes: #585636
    - Only change permissions if the crontabs directory exist

cron (3.0pl1-112) unstable; urgency=low

  [ Christian Kastner ]
  * do_command.c:
    - Don't send mail when a job exits non-zero, only send mail if the job sent
      output to stderr. This behaviour was introduced erroneously; while it
      does have merit, it is completly against standard cron behaviour.
      Closes: #581612
  * debian/compat:
    - Bumped debhelper compatibility to 7
  * debian/control:
    - Bumped Standards-Version to 3.8.4 (no change needed)
    - Build-Depend on debhelper (>= 7.0.50~)
    - Added dependency on ${misc:Depends} to package cron
  * debian/cron.init:
    - Changed Default-Stop from (1) to (empty). rc0 and rc6 were removed in
      3.0pl1-101 because the stop action -- sending SIGTERM/SIGKILL to cron
      on shutdown/reboot -- was redundant. This, however, also applies to
      rc1, because killprocs will do that for us.
  * debian/postinst:
    - Removed obsolete dpkg file backup code, this has been handed over to dpkg
      in 3.0pl1-109
    - Removed last remaining stop action (for rc1) from upate-rc.d (see above)
    - Add dpkg-statoverride for /usr/bin/crontab, and unconditionally change
      permissions of /var/spool/cron/crontabs. Closes: #304036, #460095
  * debian/standard.monthly:
    - Removed because it had been empty for years and therefore served no
      purpose
  * debian/cron.bug-{control,script}
    - Added to extend information submitted by reportbug
  * debian/rules:
    - Applied changes for standard.monthly and cron.bug-{control,script} above
  * debian/copyright:
    - Updated to reflect recent contribution...