Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 110963 - two daily cron runs with daylight savings time change
Summary: two daily cron runs with daylight savings time change
Status: RESOLVED DUPLICATE of bug 69777
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Gentoo Linux bug wranglers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-30 19:26 UTC by Anton Koinov
Modified: 2005-11-05 02:33 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Anton Koinov 2005-10-30 19:26:14 UTC
Today for Paciffic time zone (PST) was the DST change, going one hour back.

I have two Gentoo installations, both ran the /etc/cron.daily scripts twice.


Reproducible: Didn't try
Steps to Reproduce:
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2005-10-30 22:49:23 UTC
And why is that a Gentoo bug?
Comment 2 Anton Koinov 2005-10-30 23:18:20 UTC
Well, good question. One would expect that the daily cron should not run twice
within one hour, because of the /var/spool/cron/lastrun/cron.daily lock file.

I am thinking that there is probably something wrong in /usr/sbin/run-crons. It
is creating the /var/spool/cron/lastrun/cron.daily, which is used to make sure
that the daily scripts are not run twice, right?

This should work even if the time changes by one hour back. The only thing I can
think of is that the final "find -newer" is deleting the lock file when the time
changes and therefore the cron is run again...

In other words, I think the reason for the double execution is somewhere in
/usr/sbin/run-crons.
Comment 3 Jakub Moc (RETIRED) gentoo-dev 2005-10-30 23:39:09 UTC
I assume you are using vixie-cron, right? This is an "upstream" bug or
"feature", not something Gentoo-specific. See 'man 5 crontab'

<snip>
The  format  of  a cron command is very much the V7 standard, with a number of
upward-compatible extensions.  Each line has five time and date fields, followed
by a user name if this is the system crontab file, followed by a command. 
Commands are executed by cron(8) when the minute, hour, and month of year fields
match the current time, and when at least one of the two day fields (day of
month, or day of week) match the current time (see 'Note' below).  Note  that 
this means  that  non-existant  times, such as "missing hours" during daylight
savings conversion, will never match, causing jobs scheduled during the "missing
times" not to be run.  Similarly, times that occur more  than  once  (again, 
during daylight savings conversion) will cause matching jobs to be run twice.
</snip>

Marking INVALID, according to man page this is an expected behaviour.
Comment 4 Anton Koinov 2005-10-31 00:05:34 UTC
I run vixie-cron, and you are completely correct about the man page.

But let's note that run-parts is executed every 10 minutes, ant that does not
cause double execution of any of the /etc/cron.* scripts. Therefore, simply
because cron would run run-parts "twice" should not cause double execution of
daily tasks (not to mention the meaning of "twice" in this case is pointless,
because run-parts is executed every 10 minutes anyway, as mentioned double
execution is prevented via a lock file).

Because the time changes back, something in the lock logic does not work as
expected -- otherwise it should never execute a daily task within the same hour.

Please do not close the bug. Give me a week, I will try to reproduce the problem
and understand why the lock file does not work as expected. I will update this
issue when I get more information.
Comment 5 Jakub Moc (RETIRED) gentoo-dev 2005-10-31 00:14:53 UTC
The main bug here is DST existence. :=) 

NEEDINFO, reopen when you find out something.
Comment 6 Jakub Moc (RETIRED) gentoo-dev 2005-11-05 02:33:14 UTC
Reopen to dupe this...
Comment 7 Jakub Moc (RETIRED) gentoo-dev 2005-11-05 02:33:24 UTC

*** This bug has been marked as a duplicate of 69777 ***