Bug 269961 - run-parts /etc/cron.daily does not work after update to crontabs-1.10-15.fc7
run-parts /etc/cron.daily does not work after update to crontabs-1.10-15.fc7
Product: Fedora
Classification: Fedora
Component: crontabs (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Marcela Mašláňová
Fedora Extras Quality Assurance
: 271501 276831 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2007-08-30 20:41 EDT by s_h_o_
Modified: 2007-11-30 17:12 EST (History)
22 users (show)

See Also:
Fixed In Version: crontabs-1.10-16.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-09-05 19:33:16 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 s_h_o_ 2007-08-30 20:41:39 EDT
Description of problem:
run-parts /etc/cron.daily does not work after update to crontabs-1.10-15.fc7

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

How reproducible:

Steps to Reproduce:
1. At 4:02 am, cron starts "run-parts /etc/cron.daily".
Actual results:
The contents of /etc/cron/daily are not executed

Expected results:
The contents of /etc/cron/daily should be executed

Additional info:
I think the /usr/bin/run-parts is wrong.

# if cron.daily was run today
AUX1=`cat /var/spool/anacron/cron.daily`
AUX2=`date +%Y%m%d`
[ "$AUX1" == $AUX2 ] || exit 0

This should be
[ "$AUX1" == $AUX2 ] && exit 0
Comment 1 s_h_o_ 2007-08-30 20:50:17 EDT
Sorry. Typo (/etc/cron/daily -> /etc/cron.daily).

Actual results:
The contents of /etc/cron.daily are not executed

Expected results:
The contents of /etc/cron.daily should be executed
Comment 2 Marcela Mašláňová 2007-08-31 04:02:45 EDT
Already fixed in crontabs-1.10-16.fc7. Problem was that there is no such file
like cron.daily in F-7 (in devel exists).
Comment 3 Marcela Mašláňová 2007-08-31 04:02:57 EDT
*** Bug 264741 has been marked as a duplicate of this bug. ***
Comment 4 Mike Lilley 2007-08-31 10:42:37 EDT
Doesn't having this check for cron.daily in the run-parts script affect all cron

In particular, unless I'm misunderstanding the mechanisms involved, once anacron
has updated its time stamp, no cron jobs will be run for the remainder of that
day (including hourly and monthly runs).  Since the default cron.daily forces an
update of anacron timestamps (at least on my system, which I haven't knowingly
altered from the default), this seems likely to cause problems.
Comment 5 Tom Horsley 2007-08-31 15:44:27 EDT
Yea, I agree with comment #4. Whatever the problem the change to run-parts
was trying to fix, this isn't the way to fix it, that change should just
be backed out, run-parts is used for each of the hourly, daily, weekly, and
monthly script invocations, and checking something that only makes sense
for daily is a bad idea.
Comment 6 David Rees 2007-08-31 20:05:21 EDT
When is this due to hit updates-testing or updates? I'm not seeing it and
getting spammed hourly by cron is highly annoying.
Comment 7 Piete Brooks 2007-09-01 02:23:09 EDT
I agree with comment #5

I also fear that as it causes cron jobs not to run, machines which use cron to
update RPMs will never pick up the fixed RPM.
Comment 8 Nigel Metheringham 2007-09-01 04:00:32 EDT
Bug #271501 is a duplicate of this.
Comment 9 Dan O'Brien 2007-09-01 07:40:33 EDT
Still broken.  What's the problem with backing out the update until a fix is
Comment 10 Vadym Chepkov 2007-09-01 08:09:23 EDT
check of cron.daily file in run-parts is completely illogical, what about 
hourly jobs, for instance?

This should be removed from /usr/bin/run-parts:

# if cron.daily was run today
AUX1=`cat /var/spool/anacron/cron.daily`
AUX2=`date +%Y%m%d`
[ "$AUX1" == $AUX2 ] || exit 0
Comment 11 Anduin Withers 2007-09-02 15:37:04 EDT
In addition to the other flaws already pointed out, this change requires run-
parts to run as root (to have access to /var/spool/anacron/cron.daily). If some 
version of this change is going to remain, please do some more checking so non-
root can continue to use run-parts.
Comment 12 Greg Trounson 2007-09-03 00:03:04 EDT
Installing crontabs-1.10-16.fc8 from Fedora devel didn't seem to help me - the
offending lines were still there.
Comment 13 Pete Chown 2007-09-03 04:34:25 EDT
I agree with comment #9, this should be backed out, as it will be causing
ongoing problems for a lot of people.

What was the random delay trying to fix?  Unless it was an urgent thing, I can't
help wondering if it would have been better to wait until Fedora 8.  Even if the
update had worked, it would have changed the behaviour of everyone's machines
without them taking any active steps, and is that really what we want?
Comment 14 Pete Chown 2007-09-03 04:38:46 EDT
My apologies, I thought the delay was introduced by this update.  I get it now. :-)
Comment 15 Rick Mavrick 2007-09-03 23:46:06 EDT
It is also worth noting that the changes stop non-su users from using run-parts
as they do not have access to the /var/spool/anacron/* files by default.
Comment 16 Mike Chambers 2007-09-04 09:49:28 EDT
Sooo, after reading the comments, has a fix been released yet or going to be soon?
Comment 17 Gustavo Maciel Dias Vieira 2007-09-04 10:08:54 EDT
Same problem here, and probably everywhere.

I'm used to be very polite in bug reports (after all, you got to give some
credit to guys who are going to fix *your* problem). But, in this case, I will
open an exception. This is just ridiculous. This seemingly small change has very
big implications, and it is clear that the change wasn't well tough and was even
worse implemented. This should be reverted, and should be reverted now!
Comment 18 David Rees 2007-09-04 13:42:27 EDT
I agree, having a critical issue like this broken for 5 days now is completely

Because of this issue, many of my systems missed processing many of their normal
cron.[daily|hourly|monthly] jobs.

What needs to be done to escalate this issue?
Comment 19 Norman Gaywood 2007-09-04 17:51:21 EDT
A new package to fix this has been built in koji. I went to:


dowloaded crontabs-1.10-16.fc7 and did a:

yum localinstall crontabs-1.10-16.fc7

on all my systems. The changes in this package are an enhancement to the delay
feature and a revert of the anacron check thing that is causing this bug.

cron is now working for me as expected. I suspect this update will make it out
to updates eventually but as someone noted above, if you depend on cron to get
updates, you will have to do this step manually.

Comment 20 David Rees 2007-09-04 18:48:25 EDT
crontabs-1.10-16.fc7 has hit updates within the last hour.
Comment 21 Ian Mortimer 2007-09-04 21:52:45 EDT
A minor quibble about the new 000-delay.cron:

The variable name (DELAY) is misleading: reading it quickly an overworked
sysadmin might think it specified the length of delay (in some units).
DELAY_FACTOR would be more accurate.

In view of that, maybe setting DELAY=0 to turn off the delay should be allowed.
(Currently it will get a divide by zero error).  Something like:

--- 000-delay.cron.default      2007-09-05 11:37:19.000000000 +1000
+++ 000-delay.cron      2007-09-05 11:44:18.000000000 +1000
@@ -9,7 +9,7 @@
 # License: GPLv2
 [ -f /etc/sysconfig/crontab ] && . /etc/sysconfig/crontab
-if [ ! -z "$DELAY" ]; then
+if [[ -n $DELAY && $DELAY -ne 0 ]]; then
        # Create md5sum of hostname (static over system lifetime)
         md5sum="`echo ${HOSTNAME} | md5sum`"

Comment 22 s_h_o_ 2007-09-04 23:57:38 EDT
The problem has been fixed by the crontabs-1.10-16.fc7 in updates.
Comment 23 Marcela Mašláňová 2007-09-10 03:14:55 EDT
*** Bug 271501 has been marked as a duplicate of this bug. ***
Comment 24 Marcela Mašláňová 2007-09-10 11:10:23 EDT
*** Bug 276831 has been marked as a duplicate of this bug. ***

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