Bug 436694

Summary: cronie runs job 61 times after start of DST
Product: [Fedora] Fedora Reporter: Jonathan Kamens <jik>
Component: cronieAssignee: Marcela Mašláňová <mmaslano>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: low    
Version: rawhideCC: drees76, jianhai.luan, tmraz
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
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 07:02:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Fix for the bug
none
Proposed patch none

Description Jonathan Kamens 2008-03-09 15:21:55 UTC
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 10:52:12 UTC
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 05:53:15 UTC
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 21:43:30 UTC
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-09 01:41:02 UTC
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 06:32:22 UTC
Got hit by this one this morning on a couple of F9 and F10 machines.

Comment 6 Jonathan Kamens 2009-03-09 10:32:30 UTC
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 12:25:45 UTC
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 14:32:13 UTC
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 09:28:41 UTC
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 13:38:32 UTC
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 12:01:10 UTC
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 21:25:12 UTC
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 15:25:13 UTC
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 15:16:41 UTC
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 07:02:06 UTC
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 19:57:56 UTC
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 05:46:01 UTC
  RHEL6.3 miss the patch.