Bug 197598 - anacron is not run first in /etc/cron.daily and /etc/cron.weekly
anacron is not run first in /etc/cron.daily and /etc/cron.weekly
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: anacron (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Radek Vokal
Brock Organ
Depends On:
Blocks: 176344
  Show dependency treegraph
Reported: 2006-07-04 09:12 EDT by Landon Curt Noll
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-05 15:47:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Landon Curt Noll 2006-07-04 09:12:48 EDT
Description of problem:
The 0anacron script is not before all other scripts in the
/etc/cron.daily and /etc/cron.weekly job set.  If one of those
earlier jobs takes a long time to complete or becomes stuck for
a long time, anacron may try to start a second daily or weekly
cron run.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.ls /etc/cron.daily
2.ls /etc/cron.weekly
Actual results:
In /etc/cron.daily, both 00-logwatch and 00-makewhatis.cron run before anacron.
In /etc/cron.weekly, 00-makewhatis.cron runs before anacron

Expected results:
The anacron cron job is run before all other jobs.

Additional info:
As the 0anacron file says:

# The script is called "0anacron" to assure that it will be executed
# _before_ all other scripts.

Now one could simply rename the /etc/cron.*/0anacron file to
something like 000-anacron.  Unfortunately other package developers
have started naming their cron tasks in such a way to leap ahead of
anacron.  It would be only a matter of time before someone names
their cron script 0000-xyzzy.  Worse yet, there may be systems
with local cron jobs where this 0000-ing has already happened.

A better solution would be to have the run-parts shell script
execute the "anacron -u arg" command directly before it runs
any other cron script.  This patch:

--- /usr/bin/run-parts.old  2004-09-20 14:58:09.000000000 -0700
+++ /usr/bin/run-parts      2006-07-04 05:54:32.000000000 -0700
@@ -15,6 +15,9 @@
        exit 1

+# force anacron to run first
+chkconfig anacron && anacron -u $(basename "$1")
 # Ignore *~ and *, scripts
 for i in $1/*[^~,] ; do
        [ -d $i ] && continue

would force the "anacron -u dir" command to be run before
all other cron scripts if the anacron system was chkconfiged
on.  With this patch, one could remove the /etc/cron.*/0anacron files.

If for some reason, run-parts were used somewhere else
other than for /etc/cron.{daily,weekly,monthly}, this patch
would still do no harm.  An "run-parts /curds/whey" would
trigger a call to "anacron -u whey".  However unless there
was a "whey" entry in /etc/anacrontab, the anacron command would
do nothing.

One could add an optional -a argument to run-parts and modify
/etc/crontab to invoke run-parts with an -a, but I think this
would be going too far.
Comment 1 Landon Curt Noll 2006-07-04 09:20:39 EDT
I should have pointed out that on one of our production servers,
00-logwatch did become stuck long enough for anacron to kick in
a second /etc/cron.daily run.  In addition to a 2nd run of
00-logwatch, a double daily run occured with various bad side
effects.  That is why we rated this bug priority higher than normal.
Comment 2 Landon Curt Noll 2006-07-06 15:47:06 EDT
FYI: This was observed on a system running:

Red Hat Enterprise Linux WS release 4 (Nahant Update 3)
Comment 3 RHEL Product and Program Management 2006-09-05 15:35:00 EDT
The component this request has been filed against is not planned for inclusion
in the next update. The decision is based on weighting the priority and number
of requests for a component as well as the impact on the Red Hat Enterprise
Linux user-base: other components are considered having higher priority and the
number of changes we intend to include in update cycles is limited.
Comment 4 RHEL Product and Program Management 2006-09-05 15:47:25 EDT
Product Management has reviewed and declined this request.  You may appeal this
decision by reopening this request. 
Comment 5 Landon Curt Noll 2006-09-05 17:42:28 EDT
I understand that you are not planning to not include this fix in the next
update for reasons that you stated.  What is not understandable is that the bug
was closed as WONTFIX.  A WONTFiX implies that you will never fix the problem,
which is much less acceptable.

The bug will continue to exist after the next release, in my appeal I am
requested a DEFERRED status so that it may be fixed in some future release.

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