Bug 162835 - Too late scheduling in /etc/cron.daily/
Too late scheduling in /etc/cron.daily/
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Depends On:
  Show dependency treegraph
Reported: 2005-07-09 23:09 EDT by Jan Kratochvil
Modified: 2014-01-21 17:52 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-18 16:19:34 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 Jan Kratochvil 2005-07-09 23:09:58 EDT
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):

How reproducible:

Steps to Reproduce:
1. yum install yum prelink rpm
2. Configure /etc/yum* for standard daily updates.
3. Wait till 4am.
Actual results:
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.

Expected results:
Everything affected by Fedora repository update should get done in one nightly run.

Additional info:
# l /etc/cron.daily/
total 36
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.
Comment 1 Milan Kerslager 2005-09-16 19:47:06 EDT
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.
Comment 2 Milan Kerslager 2005-09-16 19:51:58 EDT
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
Comment 3 Jeremy Katz 2005-09-21 15:29:40 EDT
We could do this, but the delay seems like it's going to make things less than
ideal.  Bill -- your thoughts?
Comment 4 Bill Nottingham 2005-09-21 15:58:16 EDT
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.
Comment 5 Milan Kerslager 2005-09-22 01:54:49 EDT
What about moving /etc/cron.daily/prelink to /etc/cron.daily/zz-prelink so the
prelink will be run after yum script?
Comment 6 Jan Kratochvil 2005-09-22 21:43:04 EDT
(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.
Comment 7 Milan Kerslager 2005-09-23 00:50:29 EDT
This breaks order of hourly-daily-weekly-monthly.

Ok. So you have to have:

I think that this is pretty easy change.
Comment 8 Jeremy Katz 2006-09-18 16:19:34 EDT
The yum automatic update stuff is now handled in yum-updatesd which will make
things not fall directly at 4 am anymore

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