Bug 470168

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.