Bug 505778

(the following may also be of some use)

[root@gaia ~]# uptime
 20:58:22 up 3 days,  6:23,  1 user,  load average: 0.00, 0.00, 0.00

[root@gaia ~]# date
Sat Jun 13 20:58:22 CEST 2009

[root@gaia ~]# tail -n 12 /var/log/cron
Jun  9 20:11:03 gaia crond[1751]: (CRON) INFO (running with inotify support)
Jun 10 14:06:17 gaia crond[1778]: (CRON) STARTUP (1.2)
Jun 10 14:06:17 gaia crond[1778]: (CRON) INFO (running with inotify support)
Jun 10 14:32:43 gaia crond[1761]: (CRON) STARTUP (1.2)
Jun 10 14:32:43 gaia crond[1761]: (CRON) INFO (running with inotify support)
Jun 13 03:12:40 gaia crond[29027]: (CRON) STARTUP (1.2)
Jun 13 03:12:40 gaia crond[29027]: (CRON) INFO (running with inotify support)
Jun 13 20:03:59 gaia crond[29288]: (CRON) STARTUP (1.2)
Jun 13 20:03:59 gaia crond[29288]: (CRON) INFO (running with inotify support)
Jun 13 20:08:32 gaia crontab[29302]: (root) LIST (root)
Jun 13 20:14:02 gaia crond[29333]: (CRON) STARTUP (1.2)
Jun 13 20:14:02 gaia crond[29333]: (CRON) INFO (running with inotify support)

[root@gaia ~]# tail -n 3 /var/log/yum.log
Jun 10 23:31:37 Installed: ntpdate-4.2.4p6-4.fc11.x86_64
Jun 10 23:31:43 Installed: ntp-4.2.4p6-4.fc11.x86_64
Jun 13 20:09:13 Installed: anacron-2.3-74.fc11.x86_64

(note: that I'm guessing at this point that installing anacron will have fixed the problem)

and indeed with anacron installed, cron works more like expected...

[root@gaia ~]# tail /var/log/cron 
Jun 13 20:14:02 gaia crond[29333]: (CRON) INFO (running with inotify support)
Jun 13 21:01:01 gaia CROND[29422]: (root) CMD (run-parts /etc/cron.hourly)
Jun 13 21:01:01 gaia run-parts(/etc/cron.hourly)[29422]: starting 0anacron
Jun 13 21:01:01 gaia anacron[29431]: Anacron 2.3 started on 2009-06-13
Jun 13 21:01:01 gaia anacron[29431]: Will run job `cron.daily' in 33 min.
Jun 13 21:01:01 gaia anacron[29431]: Will run job `cron.weekly' in 53 min.
Jun 13 21:01:01 gaia anacron[29431]: Jobs will be executed sequentially
Jun 13 21:01:01 gaia run-parts(/etc/cron.hourly)[29434]: finished 0anacron
Jun 13 21:01:01 gaia run-parts(/etc/cron.hourly)[29422]: starting test
Jun 13 21:01:02 gaia run-parts(/etc/cron.hourly)[29443]: finished test

Same problem here,  I just copied the old lines into crontab from another system  I don't have anacron.
Cron used to be easy, but lately it seems every upgrade breaks something...

So now cronie needs anacron? 
That's sounds horrible. Could we please have this reverted.

No. It won't be reverted.

Cronie does not need anacron. Fedora needs anacron to run the cron.daily, cron.weekly and cron.monthly jobs.

Cronie itself supports only /etc/crontab, /etc/cron.d, per-user crontabs and cron.hourly jobs.

And that's how it makes sense.

If you need some job to run at exactly specified time & day, put it into a crontab supported by cronie.

Great, breaking stuff that has worked for over 10 years, thanks very much...

What's broken when you install cronie, crontabs and anacron?

$ for i in /etc/cron.*; do echo "$i: `rpm -q --whatprovides $i`"; done

/etc/cron.d: cronie-1.2-7.fc11.x86_64
/etc/cron.deny: cronie-1.2-7.fc11.x86_64

/etc/cron.daily: crontabs-1.10-29.fc11.noarch
/etc/cron.hourly: crontabs-1.10-29.fc11.noarch
/etc/cron.monthly: crontabs-1.10-29.fc11.noarch
/etc/cron.weekly: crontabs-1.10-29.fc11.noarch

So all the directories are provided by cronie and/or crontabs.  Yet they don't work without anacron installed.

If anacron is the one that runs cron.daily/hourly/monthly/weekly, then it should own those directories.

IMHO, either those directories (/etc/cron.daily/hourly/weekly/monthly) should be moved to the anacron package, or crontabs should require anacron, or even just be rolled into anacron (considering how tiny it would end up being).  Alternatively crontabs should require some meta-package provided either by anacron, or by an alternate package which would run the stuff.

It's just illogical for the directory structure to be owned by something and yet not functional.

I believe it is possible to install a minimal fedora 11 system with cronie/crontabs, but without anacron, and even if that's not true [and I had manually uninstalled anacron] it shouldn't break with anacron not installed.

[I'll reopen the bug just to make sure there's some response ;-)]

 At least let cronie have a req. on anacron. 

And inform your users!

The new /etc/crontabs have exactly no information about this change.
The manpages in cronie don't have a word about anacron.
crontabs package has no doc at all.

anacron has:

It's part of triple - cronie, anacron
and crontabs, which care about execution of jobs also with often
reboots or hibernation.

My systems has uptimes in years, why do I need anacron to run /etc/cron.daily/* then? (Where my yum update scripts is proposed to run every night, no I don't login into 100 boxen and run some PackageKit applet every night.)

crond is critical part of a Linux system, please be more careful.

crontabs-1.10-30.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/crontabs-1.10-30.fc11

crontabs-1.10-30.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update crontabs'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-6688

Here's the content of the new package:
# rpm -q crontabs
crontabs-1.10-30.fc11.noarch
# rpm -Vv crontabs
.........    /etc/cron.daily
.........    /etc/cron.hourly
.........    /etc/cron.monthly
.........    /etc/cron.weekly
.........  c /etc/crontab
.........    /usr/bin/run-parts
.........  d /usr/share/man/man4/crontabs.4.gz

Here's the content of (the new) man crontab, for those that don't want to go to the trouble of updating their package:

CRONTABS(4)                 Crontabs users’ Manual                 CRONTABS(4)

NAME
       crontabs - configuration and scripts for running periodical jobs

SYNOPSIS
       run-parts <directory>

DESCRIPTION
       Crontabs  is  historical  name for run-parts script and system crontab.
       Run-parts runs all executables in the specified directory.  The  execu-
       tion of files can be allowed or denied by creating file jobs.allow
        or  jobs.deny  which  worked similar as other allow/deny config files.
       The file must be created in the specified directory.

       Historically the crontab file contained configuration which called run-
       parts  on  files in cron.{daily,weekly,monthly} directories. These jobs
       are now run indirectly through anacron  to  prevent  conflicts  between
       cron  and  anacron.  That means the anacron package has to be installed
       if the jobs in these  directories  should  be  running.  Refer  to  the
       anacron(8) how to limit the time of day of the job execution.

EXAMPLE
       /etc/cron.daily/jobs.deny  could  contain  for  example 0logwatch which
       forbid execution of this script.

SEE ALSO
       anacron(8), crontab(5).

Marcela Mašláňová                 2009-06-16                       CRONTABS(4)

*************************
***** Current state *****
*************************

# rpm -q --whatprovides /etc/cron.d/0hourly
anacron-2.3-75.fc11.x86_64

# cat /etc/cron.d/0hourly 
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
01 * * * * root run-parts /etc/cron.hourly

# rpm -q --whatprovides /etc/crontab
crontabs-1.10-30.fc11.noarch

# cat /etc/crontab 
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

# For details see man 4 crontabs

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  *  command to be executed



*************************
***** My suggestion *****
*************************

Delete the /etc/cron.d/0hourly file (remove it from the anacron package).
Make the following (or something like it) the new content of /etc/crontab (in crontabs):

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

# For details see man 4 crontabs

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  *  command to be executed

# run-parts
01 * * * * root run-parts /etc/cron.hourly
# The following are commented out because they normally get run via anacron
# Please uncomment if you are not installing anacron
#02 4 * * * root run-parts /etc/cron.daily
#22 4 * * 0 root run-parts /etc/cron.weekly
#42 4 1 * * root run-parts /etc/cron.monthly

(at the very least please add the commented lines so people don't have to go searching for what to add in there)

Great :-(. cronie now has a dependency on anacron, so since I eradicated
anacron from my system to prevent the nonsense complained about above, I can
no longer get updates to cronie without anacron being dragged back in.

# rpm -q --whatprovides /etc/cron.d/0hourly /etc/cron.hourly/0anacron 
anacron-2.3-75.fc11.x86_64
anacron-2.3-75.fc11.x86_64

Just delete (or better, comment out the contents of) those two files, and add the above-mentioned lines to /etc/crontab.

crontabs-1.10-30.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

I guess this is going to bite many many many people out there when they miss the "/etc/crontabs created as /etc/crontabs.rpmnew" during a routine update and then start wondering why their hourly/daily/weekly/monthly jobs have started running twice.  Cunning change.

This was not introduce during a routine update - this change was introduced in F11 release already. This update just adds some documentation and missing dependency.