Description of problem: In order to ensure that the system is in a known state, it is sometimes desirable to run all system cronjobs synchronously before proceeding with an administration task. This is accomplished with 'anacron -n -d', with the -n flag meaning 'now'. The F10 versions of the /etc/cron.*/0anacron scripts each insert a 0-4095 second delay, computed pseudorandomly from the last 12 bits of the md5sum of the hostname, even when the -n flag is specified. Depending on the hostname, this can delay the administrative task in question by up to 3 hours and 24 minutes if there is no manual intervention. Version-Release number of selected component (if applicable): anacron-2.3-65.fc10.x86_64 How reproducible: 100% Steps to Reproduce: 1. Install F10-Preview, with the anacron service disabled in kickstart, and the hostname 'rawhide' 2. Invoke 'anacron -n -d' Actual results: Anacron waits 1110 seconds, three times, before completing, causing nearly an hour delay, if the system has the hostname 'rawhide'. Some systems may suffer a delay of more than 3 hours. Expected results: All jobs are completed within a few minutes, as with F9. Additional info: The stated purpose of the pseudorandom delay is to prevent a large number of systems that share resources from launching their jobs simultaneously. This is a needless reimplementation of the delay feature that can be configured in anacrontab, and directly contradicts the intent of the -n flag to anacron. If for some reason we're stuck using this sort of hack to randomize jobs instead of using /etc/anacrontab the way it was intended, we should probably use the last 8 bits of the md5sum, not the last 12 bits. That would give us a maximum delay of 4 minutes 15 seconds at each step, for a total delay of 12 minutes 45 seconds in the worst case. On the scale of cronjobs that take a few minutes to complete, that would be acceptable. Taking a few hours is not. Also, F9 doesn't have this misfeature.
If you run 'anacron -n', then /etc/anacrontab should be interpreted. In case I invoke 'anacron -n' the delay was as long as was set in /etc/anacrontab. Also this behaviour was already in F-8. Could you please provide more information about this problem? I'm not sure if shorter delay f.e. 12 minutes is enough for more computers on one line. Maybe the delay should be changed on zero and administrators should change it for their purposes.
The problem isn't with /etc/anacrontab, it's with the scripts that get invoked when anacron runs. Invoking anacron -n is supposed to ignore the delays in anacrontab, and it does, but the scripts still add a pseudorandom sleep, which is not in F-9, is not documented anywhere other than the scripts themselves, and clearly violates the user's intent. Even worse, the delay this sleep imposes may not be noticeable in testing, and only reveal itself to be enormous on occasion when deployed, yet fail to reproduce when a user complains, due to the pseudorandom nature. When a user invokes anacron -n, it should complete without any unnecessary delay. The sleep hack in /etc/cron.daily/0anacron and /etc/cron.weekly/0anacron is clearly not the right way to solve the problem it aims to address.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I can hardly change config file in F-10 and therefore I'd like to close this bug as next release because I removed this delay and introduced new option as you proposed. Since anacron-2.3-68.fc11 could be set RANDOM_DELAY in /etc/anacrontab. If this solution isn't sufficient, please let me know.