Bug 269961

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

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).

*** Bug 264741 has been marked as a duplicate of this bug. ***

Doesn't having this check for cron.daily in the run-parts script affect all cron
jobs?

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.

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.

When is this due to hit updates-testing or updates? I'm not seeing it and
getting spammed hourly by cron is highly annoying.

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.

Bug #271501 is a duplicate of this.

Still broken.  What's the problem with backing out the update until a fix is
provided.

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
 

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.

Installing crontabs-1.10-16.fc8 from Fedora devel didn't seem to help me - the
offending lines were still there.

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?

My apologies, I thought the delay was introduced by this update.  I get it now. :-)

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.

Sooo, after reading the comments, has a fix been released yet or going to be soon?

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!

I agree, having a critical issue like this broken for 5 days now is completely
ridiculous.

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?

A new package to fix this has been built in koji. I went to:

http://koji.fedoraproject.org/koji/packageinfo?packageID=675

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.

crontabs-1.10-16.fc7 has hit updates within the last hour.

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`"
 

--
Ian

The problem has been fixed by the crontabs-1.10-16.fc7 in updates.
Thanks.

*** Bug 271501 has been marked as a duplicate of this bug. ***

*** Bug 276831 has been marked as a duplicate of this bug. ***