Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
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:


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.