Red Hat Bugzilla – Bug 436694
cronie runs job 61 times after start of DST
Last modified: 2013-04-17 01:46:01 EDT
I have this in my personal crontab:
0 3 * * * ~/scripts/rem -q -h
When DST started early this morning and the click shifted from 2:00 to 3:00,
cronie ran the job listed above 61 times.
Something wrong there, for sure.
Not sure what's rotten here. On F-8 machine make cronie job at 3am only 10times.
Thanks for report.
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
You know, when I filed this bug a year ago, I sort of figured it would be fixed by now. No such luck. Still broken in rawhide.
Created attachment 334457 [details]
Fix for the bug
find_jobs is buggy when the program is running in virtual time. Attached patch solves the problem.
Got hit by this one this morning on a couple of F9 and F10 machines.
The patch I submitted will break CRON_TZ functionality.
On the other hand, I'm pretty sure that it's the addition of the CRON_TZ functionality that caused the bug I was trying to fix, so turnabout is fair play.
Whoever added CRON_TZ needs to figure out how to fix this, since he/she broke it.
After some more thought about the current architecture of the code...
The code as it is currently implemented can support EITHER making up jobs missed due to the DST switch, OR CRON_TZ, but not both.
The code makes the assumption that the start/end of DST happens all at once for all scheduled jobs. This assumption becomes invalid when you start allowing some jobs to have different time zones from others -- DST will start/end at different (GMT) times in those different time zones. The code that notices the start/end of DST will notice it only in the default time zone.
You need to either throw away the idea of handling DST specially (i.e., jobs scheduled during the hour that's lost when DST starts will just not run, and jobs scheduled during the hour that happens twice when DST ends will run twice), or rearchitect the code so that it tracks wall-clock time separately for each time zone in which one or more jobs are scheduled. That is, the main loop code in cron.c would have to be run multiple times, once for each time zone being handled, with the wall clock time set appropriately in each zone, and a new argument would need to be added to find_jobs to filter based on time zone and only run jobs in the specified zone, or recontruct the data structures entirely so that the jobs in different time zones are stored in separate lists, and the appropriate list is passed into find_jobs.
Oh, and in that case, the code in find_jobs that is trying to adjust for CRON_TZ would just be removed, since it would no longer be relevant there.
In any case, you need to stop screwing over those of us who are smart enough not to schedule jobs during the DST witching hour -- there's no justification for a job scheduled to run at 3am to be messed up and missed or run multiple times because of the DST switch.
The CRON_TZ was added as a feature request for users, who knew it from debian. I supposed it has been tested for a long time and should be ok for my cron fork. Anyway I was wrong and I should create more time databases as you mentioned in your previous comment. In the meantime I will add comment into man page.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
It's somewhat pitiful that this bug is still broken two years after I first reported it, when I even took the time a year ago to fully analyze the problem and tell you exactly how you could fix it.
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '12'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 12's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 12 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Created attachment 482793 [details]
I finally got to make a patch that should fix this problem not breaking the CRON_TZ support. The CRON_TZ DST switch problems as described in comment 7 are not fixed but as the CRON_TZ support is a marginal feature it is not critical to have it super-correct.
Basically for the default timezone it handles the DST switch right and for the non-default timezones it ignores DST switches altogether (it will not try to compensate for the lost minutes).
cronie-1.4.7-1.fc15 has been submitted as an update for Fedora 15.
cronie-1.4.7-1.fc14 has been submitted as an update for Fedora 14.
cronie-1.4.7-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
cronie-1.4.7-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
RHEL6.3 miss the patch.