Bug 436694 - cronie runs job 61 times after start of DST
cronie runs job 61 times after start of DST
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: cronie (Show other bugs)
rawhide
All Linux
low Severity urgent
: ---
: ---
Assigned To: Marcela Mašláňová
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-09 11:21 EDT by Jonathan Kamens
Modified: 2013-04-17 01:46 EDT (History)
3 users (show)

See Also:
Fixed In Version: cronie-1.4.7-1.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-03-25 03:02:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Fix for the bug (723 bytes, patch)
2009-03-08 21:41 EDT, Jonathan Kamens
no flags Details | Diff
Proposed patch (5.16 KB, patch)
2011-03-07 16:25 EST, Tomas Mraz
no flags Details | Diff

  None (edit)
Description Jonathan Kamens 2008-03-09 11:21:55 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.
Comment 1 Marcela Mašláňová 2008-03-10 06:52:12 EDT
Not sure what's rotten here. On F-8 machine make cronie job at 3am only 10times.
Thanks for report.
Comment 2 Bug Zapper 2008-05-14 01:53:15 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 3 Jonathan Kamens 2009-03-08 17:43:30 EDT
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.
Comment 4 Jonathan Kamens 2009-03-08 21:41:02 EDT
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.
Comment 5 David Rees 2009-03-09 02:32:22 EDT
Got hit by this one this morning on a couple of F9 and F10 machines.
Comment 6 Jonathan Kamens 2009-03-09 06:32:30 EDT
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.
Comment 7 Jonathan Kamens 2009-03-09 08:25:45 EDT
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.
Comment 8 Marcela Mašláňová 2009-03-12 10:32:13 EDT
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.
Comment 9 Bug Zapper 2009-06-09 05:28:41 EDT
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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 10 Jonathan Kamens 2010-03-14 09:38:32 EDT
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.
Comment 11 Bug Zapper 2010-11-04 08:01:10 EDT
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 12 Tomas Mraz 2011-03-07 16:25:12 EST
Created attachment 482793 [details]
Proposed patch

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).
Comment 13 Fedora Update System 2011-03-15 11:25:13 EDT
cronie-1.4.7-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/cronie-1.4.7-1.fc15
Comment 14 Fedora Update System 2011-03-16 11:16:41 EDT
cronie-1.4.7-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/cronie-1.4.7-1.fc14
Comment 15 Fedora Update System 2011-03-25 03:02:06 EDT
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.
Comment 16 Fedora Update System 2011-03-30 15:57:56 EDT
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.
Comment 17 Luan Jianhai 2013-04-17 01:46:01 EDT
  RHEL6.3 miss the patch.

Note You need to log in before you can comment on or make changes to this bug.