Red Hat Bugzilla – Bug 162835
Too late scheduling in /etc/cron.daily/
Last modified: 2014-01-21 17:52:04 EST
Description of problem:
cron.daily is in a wrong order thus making each daily update affects the system
differently for two days.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. yum install yum prelink rpm
2. Configure /etc/yum* for standard daily updates.
3. Wait till 4am.
In the morning prelink cache still contains entries for libraries BEFORE update.
/var/log/rpmpkgs still contains entries for packages BEFORE update.
The whole next day the system runs without prelinked updated packages.
As I use custom directory with hardlinked subset of the distribution all the
updated files get "->inode use count 1" for the first night and just
"etc/ld.so.cache" gets "->inode use count 1" in the second night.
Everything affected by Fedora repository update should get done in one nightly run.
# l /etc/cron.daily/
lrwxrwxrwx 1 root root 28 Jun 14 00:48 00-logwatch ->
-rwxr-xr-x 1 root root 276 Mar 16 22:06 0anacron*
-rwxr-xr-x 1 root root 180 Mar 31 21:54 logrotate*
-rwxr-xr-x 1 root root 418 Apr 8 13:11 makewhatis.cron*
-rwxr-xr-x 1 root root 2133 Nov 23 2004 prelink*
-rwxr-xr-x 1 root root 104 May 24 17:37 rpm*
-rwxr-xr-x 1 root root 246 Apr 16 21:58 slocate.cron*
-rwxr-xr-x 1 root root 286 Apr 16 12:59 tmpwatch*
-rwxr-xr-x 1 root root 158 May 25 19:46 yum.cron*
-rwxr-xr-x 1 root root 113 Jun 12 09:42 zz-apache-php-relink*
"yum.cron" should get named before at least: makewhatis.cron, prelink, rpm,
"0yum.cron" name should be IMO enough.
The renaming will push all the rest of the scripts one hour later because there
are random delays in /etc/cron.daily/yum.cron. I suggest to lower delay 120
minutes to 15, 20, 30 or so.
FC4 has some 0* entries already, so rename to 000-yum please:
# ls /etc/cron.daily/
00-logwatch certwatch logrotate rpm tetex.cron
00webalizer cups makewhatis.cron slocate.cron tmpwatch
0anacron disktest-smart prelink squirrelmail.cron yum.cron
We could do this, but the delay seems like it's going to make things less than
ideal. Bill -- your thoughts?
Obviously, we should rip out the the cron.daily subsystem and replace it with a
new cron replacement where you can specify dependencies between jobs and it will
reorder them for you.
We could take the delays out and rely on the mirror code to distribute the load.
Or, we could just leave the delays in, because I'd assume the number doing auto
updates would be a smaller portion of the installed base.
What about moving /etc/cron.daily/prelink to /etc/cron.daily/zz-prelink so the
prelink will be run after yum script?
(In reply to comment #5)
> What about moving /etc/cron.daily/prelink to /etc/cron.daily/zz-prelink so the
> prelink will be run after yum script?
Still would remain flawed (probably more, not much packages installed here):
* rpm: "/var/log/rpmpkgs" is EACH DAY obsolete now due to the mostly daily updates.
* slocate.cron: locate(1) is now also usually obsolete (not much serious, files
count usually does not change on updates).
What about moving "cron.daily" from its original 4:02 to 3:02 as "yum.cron" now
delays the execution by 65 minutes in average? This scheduling is already not
much useful due to the timezone differences anyway.
This breaks order of hourly-daily-weekly-monthly.
Ok. So you have to have:
I think that this is pretty easy change.
The yum automatic update stuff is now handled in yum-updatesd which will make
things not fall directly at 4 am anymore