Bug 481775 - hourly, daily, weekly, monthly jobs will not run without anacron installed?
hourly, daily, weekly, monthly jobs will not run without anacron installed?
Product: Fedora
Classification: Fedora
Component: crontabs (Show other bugs)
All Linux
low Severity urgent
: ---
: ---
Assigned To: Marcela Mašláňová
Fedora Extras Quality Assurance
Depends On:
Blocks: F11Blocker/F11FinalBlocker
  Show dependency treegraph
Reported: 2009-01-27 10:04 EST by Jonathan Kamens
Modified: 2009-04-07 10:16 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-04-07 10:16:14 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 Jonathan Kamens 2009-01-27 10:04:43 EST
It appears that the crontabs and anacron RPMs were modified recently so that anacron is exclusively responsible for running the jobs in /etc/cron.hourly, daily, weekly, and monthly.

I consider this change to be VERY WRONG.  Servers that are intended to be up all the time and to provide mission-critical services which heavily utilize the server's resources should NOT run daily, weekly and monthly jobs at random times in the middle of the day.  The reason why those jobs are scheduled to run in the middle of the night is because they, too, are heavy resource consumers, and the middle of the night is when few people are using the server.  If anacron decides to fire them off in the middle of the day, perhaps suffers, and users suffer.

For this reason, we completely remove anacron from any servers which are intended to be up all the time.  If our server crashes and doesn't get brought up until the next morning, we don't WANT the daily, weekly or monthly jobs to run shortly after we bring the server up; we want them to skip a night and wait until the next night to run, when the server won't be handling many user requests.

This NEEDS to be put back the way it was.  It is simply wrong to require anacron for a functioning system.
Comment 1 Tomas Mraz 2009-01-27 11:33:34 EST
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.
Comment 2 Jonathan Kamens 2009-01-27 12:49:28 EST
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.
Comment 3 Tomas Mraz 2009-01-28 03:39:06 EST
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.
Comment 4 Jonathan Kamens 2009-01-28 07:34:05 EST
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.
Comment 5 Tomas Mraz 2009-01-28 11:20:08 EST
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.
Comment 6 Jonathan Kamens 2009-01-28 11:27:25 EST
"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.
Comment 7 Tomas Mraz 2009-01-28 11:49:01 EST
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.
Comment 8 Marcela Mašláňová 2009-02-06 09:16:25 EST
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.
Comment 9 Jonathan Kamens 2009-02-10 00:47:09 EST
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]
Comment 10 Marcela Mašláňová 2009-02-10 05:58:52 EST
This should be fixed in anacron-2.3-69.fc11.
Comment 11 Jonathan Kamens 2009-02-11 08:04:39 EST
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?
Comment 12 Tomas Mraz 2009-02-11 08:28:36 EST
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.
Comment 13 Jonathan Kamens 2009-02-11 09:02:39 EST
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.
Comment 14 Marcela Mašláňová 2009-02-19 09:27:06 EST
Ok, I made another attempt to fix this problem in anacron-2.3-70.fc11. Any other comment or idea is welcomed.

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