This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 450958 - queuing a check via dbus should reset the run_interval timer
queuing a check via dbus should reset the run_interval timer
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: yum (Show other bugs)
5.2
All Linux
low Severity low
: rc
: ---
Assigned To: James Antill
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-11 17:39 EDT by James Ralston
Modified: 2008-06-12 18:04 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-11 18:03:03 EDT
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 James Ralston 2008-06-11 17:39:31 EDT
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 18:03:03 EDT
 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 18:04:22 EDT
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.