Bug 450958 - queuing a check via dbus should reset the run_interval timer
Summary: queuing a check via dbus should reset the run_interval timer
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: yum
Version: 5.2
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: James Antill
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-06-11 21:39 UTC by James Ralston
Modified: 2008-06-12 22:04 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-06-11 22:03:03 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description James Ralston 2008-06-11 21:39:31 UTC
1:yum-updatesd-0.9-2.el5.noarch

On our servers, I've set run_interval = 86400 (24 hours) in
/etc/yum/yum-updatesd.conf, and put a script in /etc/cron.daily that first waits
a random amount of time (between 0 seconds and 10 minutes), and then uses
dbus-send to queue a check:

$ /bin/dbus-send --system --type=method_call --dest=edu.duke.linux.yum /Updatesd
edu.duke.linux.yum.CheckNow

The goal is to cluster all of the yum-updatesd notices at around the same time,
instead of having them occur randomly throughout the day and night (depending on
when the server was last rebooted and thus yum-updatesd was last started).

Surprisingly, queueing a check via dbus does *not* reset yum-updatesd's notion
of how long it needs to wait for the next run interval.  For example, if I
reboot a server at 18:00, when yum is started, it immediately goes to sleep for
the run_interval value.  Sometime between 04:02 and 04:12 the next day, the
cron.daily job requests a check via dbus, which yum dutifully obeys. However, at
18:00 that same day, yum-updatesd will initiate yet another check, because the
interval between yum's start time and the current time has exceeded the
run_interval, even though the interval between the last check and the current
time has NOT exceeded the run_interval.

For now, I'm working around this behavior by having the cron.daily job perform a
condrestart on yum-updatesd before it requests a re-check via dbus.  But I think
yum-updatesd's behavior here is highly non-intuitive: queueing a check via dbus
should cause yum-updatesd to reset the run_interval timer.

Comment 1 James Antill 2008-06-11 22:03:03 UTC
 yum-updatesd isn't designed to be used that way to do what you want. What you
probably want is to _not_ run the yum-updatesd service, but to just call
"/usr/sbin/yum-updatesd --oneshot" from your cron script. And/or install
yum-cron from epel.

 The whole point of the run_interval code is to try and make the yum-updatesd's
run at different times. For instance if 90%+ of people log onto their machines
between 8:55 and 9:05, triggering a check update in some way, we don't want all
of their yum-updatesd's to syncronize within that 10 minute window.


Comment 2 James Ralston 2008-06-12 22:04:22 UTC
Ah; --oneshot wasn't mentioned in the (stub) man page for yum-updatesd.  Yes,
that's definitely want I want here.

Suggestion: consider documenting --oneshot in the yum-updatesd(8) man page...



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