Bug 481775

I think this could be solved by adding appropriate configuration options to anacron. For example it could be improved so the admin could configure that the jobs are never run after such and such time of the day.

The previous configuration which combined anacron and regular crond was extremely error prone - the jobs were either not run at all or in some cases even run multiple times.

I agree that the previous implementation was poor, but the new implementation, while it may be better for people who want anacron's functionality, is infinitely worse for people who don't.  Please put things back the way they were until such time as the configuration options you mention have been implemented.

I suppose you don't use rawhide on production servers. (If you do you don't. :)) Of course these options have to be implemented before F11.

There is another important issue here that needs to be resolved, and that is what will happen on upgrades for servers which have vixie-cron and crontabs installed but not anacron, or which have anacron installed but disabled.

With these changes, all of their hourly, daily, weekly and monthly cron jobs will suddenly stop working.

BTW, another issue I just encountered... "service anacron stop" doesn't work:

$ sudo service anacron stop
[sudo] password for jik: 
Stopping anacron:                                          [FAILED]
$ service anacron status
anacron (pid 20370) is running...
$ ps auxw | grep 20370
jik      18305  0.0  0.0   4432   648 pts/2    S+   07:30   0:00 grep 20370
root     20370  0.0  0.0   1936   732 ?        Ss   05:01   0:00 /usr/sbin/anacron -s

In any case, I have a suggestion for how to address the upgrade issue as well as the issue of what to do when anacron isn't installed in general... Put the cron jobs back in /etc/crontab, but write them like this:

/sbin/service anacron status >/dev/null 2>&1 || run-parts /etc/cron.hourly

This way, cron will execute the jobs, but only if anacron isn't currently running.

service anacron stop will stop anacron only when it is started as a service through the init script. It will not work if it is started just by calling anacron -s.

On upgrades the dependencies will pull anacron into the upgrade transaction so there should not be any problem of course modulo any user modifications of /etc/crontab which might interfere.

"service anacron stop will stop anacron only when it is started as a service
through the init script."

This is not so.  The anacron currently running on my machine was started through the init script, and "service anacron stop" did not stop it, as I showed in my previous comment.

I see, also, that "service anacron start" does not actually put the service into a started state, presumably because today's jobs have already been run:

$ sudo service anacron start
Starting anacron: ^[[60G[^[[0;32m  OK  ^[[0;39m]
$ sudo service anacron status
anacron is stopped
$ 

This is a poor design.  It is not consistent with how /etc/init.d scripts are supposed to work, and it'll prevent the scheme I proposed above from working.  It should be fixed so that even when anacron -s isn't running because the day's jobs have already been run, the service script should still think that the anacron service is on, and furthermore, the anacron cron jobs that actually fire up the daily jobs should be fixed so that when the service script does *not* think that anacron is running, they don't do anything.

"On upgrades the dependencies will pull anacron into the upgrade transaction"

What dependencies?  I see nothing obvious in the dependencies of either the crontabs or the cronie RPM that would pull in anacron.  Please be more specific.

I was wrong with the dependency - I'm sorry. I suppose there should be added a virtual provide to anacron and fcron which would allow pulling it by crontabs package. Or it could be done the other way so the cronie will directly require anacron (that's maybe even more appropriate).

The init script of anacron should be simply removed as it will not be needed anymore.

New anacron-2.3-68 has option START_HOURS_RANGE which should solve your problem. The cron tests every first minute of hour whether the cron.daily should be running or not. If the option will be set for example to 4-7, then the job will start in this hour range. It will start precisely at 4:01, if you don't have any other delays set in /etc/anacrontab.

Please take a look and let me know, whether there are some other problems.

I have "START_HOURS_RANGE=1-3" in /etc/anacrontab.

Here's what I just saw in my syslog (courtesy of my customized logwatch script, which catches debug log messages as well as messages that normally go into /var/log/messages):

anacron: START_HOURS_RANGE wasn't set correctly: 1
kernel: anacron[16421]: segfault at 0 ip 008c9238 sp bfef517c error 4 in libc-2.9.90.so[899000+16f000]

This should be fixed in anacron-2.3-69.fc11.

Perhaps it doesn't coredump anymore, but it also doesn't work.

I still have START_HOURS_RANGE=1-3 in my /etc/anacrontab, and yet anacron just ran, at 8:00 in the morning, and logged this:

Jobs will be executed sequentially
Will run job `cron.daily' in 5 min.
Will run job `cron.weekly' in 25 min.

Why is it running the jobs if I told it to only start them between 1 and 3am?

It will not really run them. The test for the hours range is done only at the actual time of the execution of the job and only a debug message is generated if the job is not run.

And then afterwards it logs a message claiming that the two jobs were run when in fact they were not.

This is a bug.  The program should not log things that are not true.  The logic for checking *all* the conditions which affect whether the job should run should take place early enough that anacron doesn't log that the jobs are going to run / have been when in fact they are not / have not.

Ok, I made another attempt to fix this problem in anacron-2.3-70.fc11. Any other comment or idea is welcomed.