Bug 470168 - Default anacron config adds excessive delay to manual invocation of anacron.
Default anacron config adds excessive delay to manual invocation of anacron.
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: anacron (Show other bugs)
10
All Linux
medium Severity low
: ---
: ---
Assigned To: Marcela Mašláňová
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-05 23:12 EST by Chris Snook
Modified: 2009-02-06 09:54 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-06 09:54:21 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chris Snook 2008-11-05 23:12:11 EST
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.
Comment 1 Marcela Mašláňová 2008-11-24 09:04:34 EST
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.
Comment 2 Chris Snook 2008-11-24 10:46:36 EST
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.
Comment 3 Bug Zapper 2008-11-25 23:51:05 EST
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
Comment 4 Marcela Mašláňová 2009-02-06 09:54:21 EST
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.

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