Bug 212507

Upon upgrade from FC5 the yum-updatesd package is missing (should of been
installed and wasn't). 

In addition. Changing the conf file in /etc/yum/yum-updatesd.conf so that
autoupdates are applied seems to do absolutely nothing.

Trying to run puplet gives the following error

libnotify-Message: Unable to get session bus: Unable to determine the address of
the message bus (try 'man dbus-launch' and 'man dbus-daemon' for help)
Error: unable to initialize pynotify

dbus confirmed as running.

Why was this released? It's not ready. AND I really don't like the fact that you
guys REMOVED the old yum update package as well, so now I have to hand create a
cron job to run "yum update" until this gets fixed. 

I'm seeing this as well. yum-updatesd is running and configured to do updates
automatically (and email me when updates are found), but it doesn't seem to do
anything (and doesn't email me).

To add to the fun, yum-updatesd uses the same lock file as yum, so if one wants
to do manual yum work, one has to shut the service down, then restart it when
you're done.  Shouldn't the daemon use its own lockfile, only touching the
yum.pid lockfile when it's actually executing yum?

This change to a daemon is a whole lot of extra work and dependancies to do
something which worked just fine as a cron job.  PLus, why tie up resources with
a daemon for something which really only needs checked once a day?  Presumably
to simply make a button blink for desktop users?  Wholly inappropriate for
server use anyway, or on centrally maintained workstations where one doesn't
want users in charge of updates.  Will pull the crontab stuff back out of FC5
and use that instead.

Plus, the default is to check for updates every hour.  Seems excessive to
multiply update checking traffic by a factor of 24, especially when combined
with the poorly maintained mirrors list as described in
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193052

Confirmed the same behaviour on two fc6 machines here.

(In reply to comment #1)
> libnotify-Message: Unable to get session bus: Unable to determine the address of
> the message bus (try 'man dbus-launch' and 'man dbus-daemon' for help)
> Error: unable to initialize pynotify
> 
> dbus confirmed as running.

FYI: utility /usr/bin/dbus-launch is not included in dbus*.rpm. You must have
dbus-x11*.rpm installed to get dbus-launch utility.

After FC5 --> FC6 upgrade my GNOME session started claiming with the sam kind of
error message. After 'yum install dbus-x11' it's been working fine.

Cannot confirm if installing dbus-x11 helps for your you autoupd problem.

I can confirm I have the same dbus error on running puplet.

I have installed FC6 from scratch (rather than upgrade from FC5) but keeping my
/home directory intact. The puplet notification worked at first, but has since
stopped working. I am afraid there has been so many changes (updates/third-party
RPMs installation) that I cannot pinpoint when the dbus error started happening..

Created attachment 139978 [details]
a package containing the old cron-based up update files

Putting my money where my mouth is (apologies for the grumpy tone of the last
post), here's a workaround for the current lack of auto-updates, in the form of
a quick repackaging of FC5's cron-based yum updates.  This successfully
auto-updated a lab full of FC6 machines for me last night.

You might need to disable yum-updatesd for this to work, due to dueling
lockfile issues.  But presumably you'd only be installing this if the daemon
solution is alreayd not working, so that shouldn't be a problem.

Created attachment 139979 [details]
a SRPM package containing the old cron-based up update files

The SRPM of the yum cron files, since there are certainly those who either
write better .spec files than I and/or who wold want to customize what they
roll out.

Both files GPG signed, look me up on your favorite public keyserver.

(In reply to comment #7)
> Created an attachment (id=139978) [edit]
> a package containing the old cron-based up update files
> 
> Putting my money where my mouth is (apologies for the grumpy tone of the last
> post), here's a workaround for the current lack of auto-updates, in the form of
> a quick repackaging of FC5's cron-based yum updates.  This successfully
> auto-updated a lab full of FC6 machines for me last night.
> 
> You might need to disable yum-updatesd for this to work, due to dueling
> lockfile issues.  But presumably you'd only be installing this if the daemon
> solution is alreayd not working, so that shouldn't be a problem.
> 


Thanks for the repackage. I liked the old system.

Now if only we could get Jeremy to comment on what happened (not looking to
flame him, just curious as to what it looks like the problem is)

I've also seen these symptoms, both yum-updatesd failing to find/install updates
(despite me making the necessary changes to /etc/yum/yum-updatesd.conf) and the
hogging of /var/run/yum.pid.

I'm assuming that the yum.pid hogging is a bug - possibly related to the first
symptom.  When you first launch yum-updatesd it doesn't hog the yum.pid and yum
still works.  When the updatesd first tries to look for updates something goes
wrong, the updates aren't found and the lock isn't released.

I can see that the updatesd needs to use the same lock file as yum (so you can't
interfere with it mid-update), so I'm suspecting a wider bug is at play.

I've looked for any useful messages in the logs, but didn't find anything.

I've tried to do some more debugging on this but have failed miserably.

How do you get any debugging information out of yum-updatesd?  For that matter
how do you get anything at all out of it?

I've set the daemon to emit notifications via syslog and have set the loglevel
to debug and despite restarting a few times I've not seen *any* messages hit the
logs.

I ran a strace on it to see if I could capture an update check but because the
program makes itself into a daemon it only captures the first few seconds after
launch and then detaches.

Any suggestions for how to start to debug this are most welcome!

(In reply to comment #11)
> I've tried to do some more debugging on this but have failed miserably.
> 
> How do you get any debugging information out of yum-updatesd?  For that matter
> how do you get anything at all out of it?
> 
> I've set the daemon to emit notifications via syslog and have set the loglevel
> to debug and despite restarting a few times I've not seen *any* messages hit the
> logs.
> 
> I ran a strace on it to see if I could capture an update check but because the
> program makes itself into a daemon it only captures the first few seconds after
> launch and then detaches.
> 
> Any suggestions for how to start to debug this are most welcome!

Is'nt there a source code rpm for it? Possibly making a slight change to the
code to non-daemonize it would help.

I think I may have found something.

I managed to get an strace out of the updatesd using:

sudo strace python /usr/share/yum-cli/yumupd.py -f 

A lot of stuff goes by, but at the end of an update cycle I see the following
suspicious entry:

clone(child_stack=0xb7a824b4,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID
                                   |CLONE_CHILD_CLEARTID,
parent_tidptr=0xb7a82bd8, {entry_number:6, base_addr:0xb7a82b90, limit:1048575,
seg_32bit:1, contents:0, read_exec_o                                    nly:0,
limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0xb7a82bd8) = 16013
futex(0x8d72218, FUTEX_WAKE, 1Exception in thread UpdateInstallThread:
Traceback (most recent call last):
  File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap
    self.run()
  File "yumupd.py", line 269, in run
    self.updd.downloadPkgs(dlpkgs)
NameError: global name 'dlpkgs' is not defined

)         = 1
select(0, NULL, NULL, NULL, {0, 0})     = 0 (Timeout)

I'll attach the full strace in case there's anything useful further up.

Created attachment 140244 [details]
Strace of a failed updatesd run

This strace runs from starting yum-updatesd manually and finishes just after
the first attempt at update retrieval.	Updates are not successfully retrieved
and the yum.pid lock file is left in place.

Just before the end of the file is a yum traceback which looks like a likely
culprit.

Can you try grabbing http://people.redhat.com/~katzj/yum-updatesd.py and
replacing /usr/share/yum-cli/yumupd.py with it?  This is just a quick test based
on the output above; delving deeper is on my list for Monday if this isn't it.

Sure... doing that now.  Restarted the service... tail'ing /var/log/messages...
I'll keep you posted

Thank you, Alec, for the yum-cron package!  It works like a charm.

I think the new approach is a real step backward.  Enabling automatic updates
used to take one simple command: "chkconfig yum on".  It was one of the first
things I'd do on any FC1-FC5 system I'd install.  (Quite frankly they ought to
have been enabled by default, so the unwashed masses, who are unlikely to have
problems with automatic updates, would get them by default.)  But with FC6 all
that was gone, replaced with something that doesn't seem to work at all, and
even if it did work it's not as simple and straightforward to enable automatic
updates, as opposed to just a little notification icon on the desktop.  Security
experts keep harping on the need to have systems configured securely right out
of the box, so why did Fedora move in the opposite direction in this release?

Maybe a stupid question but could someone add the yum-cron package to the extras
repository? It would make my life much simpler after I decide to upgrade all my
servers to FC6.

Guys... I've got an idea... lets fix the actual bugs found here.  yum + cron was
nice... this yum daemon idea is better.  Be patient, and work to *fix* this bug
please.

Jeremy, that new /usr/share/yum-cli/yumupd.py doesn't seem to do anything
differently... at least the results are the same as the original broken one 

I have a reversion to the comment I made previously - where I said that
yum-updatesd did not work. In fact although I had changed the config file to
contain:
[main]
# how often to check for new updates (in seconds)
run_interval = 43200
# how often to allow checking on request (in seconds)
updaterefresh = 600

# how to send notifications (valid: dbus, email, syslog)
emit_via = dbus

# automatically install updates
do_update = yes
# automatically download updates
do_download = yes
# automatically download deps of updates
do_download_deps = yes

I had forgotten to restart the service via
service yum-updatesd restart
so the new config file had not been activated.  Also at the time there was a
conflict for totem/totem-xine so that yum would not find any updates.  With the
correct config file, and having restarted the daemon all is well - clean install
FC6, and running KDE - all up to date.

Mike

Created attachment 140447 [details]
Strace of a failed updatesd run using new yumupd.py

I tried the updated file from comment #15.  The traceback from the previous
strace is now gone, but the updates still don't work.

I've attached an abridged strace from the new verison, but it looks like it's
getting stuck in a loop where it continually re-reads the rpm database over and
over again.  With this new version the updatesd stays active and just keeps
taking (about 50%) CPU until it's killed.  Grep this file for ^access and
you'll see the repeating pattern fairly easily.

To keep the size of this file down I've removed futex, pread, _llseek, read and
rt_sigprocmask entries (which would have added another 117Mb!)

The dueling lock files between yum-updatesd and yum need to be fixed. However,
it isn't something that is always a problem. Most times you can run yum with
yum-updatesd running and there is no conflict.

I suspect that their is a window on time when yum-updatesd is checking for
updates that the lock files clash.

Definately it should be fixed. One should not block the other.

Hopefully the same fix allow for the use of a "yum search" command while a "yum
install" is running.

Okay, I think I've got this pretty happy now.  Can you grab
http://people.redhat.com/~katzj/yum-updatesd.py and replace
/usr/share/yum-cli/yumupd.py, restart yum-updatesd and see if it works better?

It seems my comment at 20 was wrong after all - there is a log file produced but
it did not run yum after all.  So the other postings from everyone else are more
relevant.

Mike

Sorry, but the last update from #23 makes no difference on my test machine.  It
still ends up in a loop where it re-reads the rpm database over and over again
(strace looks like it's about the same as #21).

I'm more than happy to run debugging code on my machine if this is something
which you can't reproduce on your systems.

Please ignore comment 25.  I'm an idiot.  I didn't spot that wget had appended a
.1 on the end of the filename so was re-trying the same file from #15.

I've now tried the new file with different, but somewhat mixed results.

I tried running an strace on the new file on my test system and it seemed to be
working in as much as there was a burst of activity and then it went back to
sleep again (no more looping reading the database).  However when I killed it I
got an error about a failed scriptlet in cups which might mean I actually
interupted a trascation.

On another system I looked for what updates should have been available and then
checked with rpm on my test system and they *did* appear to have been applied. 
All looking good so far.

However, I then tried another system (the one where I'd checked for updates but
not applied them) where I installed the new .py file and launched updatesd
through /etc/init.d.  Again there was a burst of activity which stopped. 
Looking in /var/log/yum.log and directly with rpm nothing had been added.  Doing
/etc/init.d/yum-updatesd status gave:

yum-updatesd dead but subsys locked

There's nothing I can see in any of the logs.

I then tried on a third system without checking or touching anything, just
replacing the file and restarting, and it worked.  It applied updates, went back
to sleep and didn't die (Hooray!).  However there was still nothing appended to
/var/log/yum.log.  Rpm did show the new packages were in place though.

So the remaining problems seem to be:

1) Updatesd doesn't cope with updates which have had their headers downloaded,
but not applied (ie run a yum update and then cancel when it says "Is this OK").
 The updatesd seems to die.

2) I'm still not seeing anything in any of the logs even on a successful run. 
In all cases /var/log/yum.log should be updated and since I've got emit_via =
syslog probably something in /var/log/messages as well.

Sorry about the bogus report before.

yum-3.0.1-2.fc6 has been pushed for fc6, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

Created attachment 141037 [details]
Strace of updatesd segfault using yum-3.0.1-2.fc6

The new yum in updates testing still shows the same problems I reported in #26.


I played around a bit on the machine on which updatesd dies and it doesn't seem
to matter whether you've downloaded headers before or not.  It still dies even
after a yum clean all.	The attached strace shows a session which dies.  Again
there's nothing in the logs to suggest what happened.

I should also note that even on the machines on which updatesd runs, it still
does not log anything (despite updatesd.conf specifying logging to syslog).   A
note in the logs to show each time it ran would be useful.  A log in yum.log to
say what's been changed is essential.  If that's not present then I've got no
way to tell what's been changed on these machines.

Another possible avenue to investigate...

On my machine which fails I'm wondering if the failure is related to
https://bugzilla.redhat.com/bugzilla/211917

The symptoms described there sound exactly like the state this machine ends up
in after the updatesd dies (rpm unresponsive - requires a reboot and a rebuildb
to work again).

The updatesd only dies once it starts the rpm transaction.  The header and
package downloads work OK but the first transaction dies.

There is a suggestion that a kernel update helps.  I've installed this but can't
test as I've no outstanding updates waiting.  I'll try it again tomorrow and see
if it gets any further.

(In reply to comment #29)
> I'll try it again tomorrow and see if it gets any further.

I tried again.  It didn't get any further.  Same segfault as in #28 as far as I
can see.  Ends with:

rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Process 5531 detached

I've still only ever seen this when using updatesd.  It leaves the system in a
state where rpm is unresponsive to further queries.

If I delete /var/lib/rpm __db.* then rpm works again and an immediate yum update
also works.

yum-3.0.1-2.fc6 has been pushed for fc6, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

Still seeing a /var/run/yum.pid file... and no automatic updates.

Let me add more detail.  After I upgraded... I removed the lock file, changed
/etc/yum/yum-updatesd.conf to say "do_update = yes", and restarted yum-updatesd.
 A day or two later, I'm seeing this:

[joshua@fc6 ~]$ sudo yum check-update
Loading "installonlyn" plugin
Loading "protectbase" plugin
Loading "fastestmirror" plugin
Existing lock /var/run/yum.pid: another copy is running. Aborting.

[joshua@fc6 ~]$ ps -ef | grep `cat /var/run/yum.pid`
root      3712     1  0 02:12 ?        00:00:03 /usr/bin/python
/usr/sbin/yum-updatesd

The 'yum' process stopped working on my system and it appeared to be a conflict
with 'rpmq'.  I ran 'ps -aef|grep rpm' and came up with 20 days of this:

root     19255     1  0 Oct31 ?        00:00:00 /usr/lib/rpm/rpmq -q --all --qf
%{name}-%{version}-%{release}.%{arch}.rpm\n
root     19257 18688  0 Oct31 ?        00:00:00 awk -v
progname=/etc/cron.daily/rpm progname {?????   print progname ":\n"?????  
progname="";????       }????       { print; }

After killing any 'yum' and 'rpmq' processes, I rebuilt the RPM database.  Your
issue may not be related.  Not enough time has passed for me to know whether or
not the issue is fixed on my system.

I disabled updates via yum-cron to see if the updated yum-updatesd would work
now.  Like Joshua, I changed yum-updatesd.conf to say "do_update = yes", and
also set do_download and do_download_deps to yes for good measure.  I restarted
the yum-updatesd service, and after several hours I also get the same error when
running "yum check-update".  It seems that yum-updatesd grabs the
/var/run/yum.pid file and doesn't let it go when it's finished (or it never
finishes).  After restarting yum-updatesd again, I can run yum check-update for
a little while until yum-updatesd grabs the pid file again.

I did get notices in the notification area of the GNOME panel that updates were
successfully installed (4 yesterday, 3 today), but each time, after restarting
yum-updatesd and rerunning yum check-update, it seems there are more updates
available that it never got around to installing.  Also, absolutely nothing gets
logged in /var/log/yum.log (nor anywhere else in /var/log) to say what packages
got updated by yum-updatesd.  Again, this might suggest that the process is
getting stuck before completing its task.

I think I'll turn off do_update in yum-updatesd.conf and re-enable yum-cron,
unless you can suggest something else I should try.

This discussion appears to be a mix of several different bugs. I see some of the
problems reported here, and don't see others. yum-3.0.1-2.fc6 is installed. My
/etc/yum/yum-updatesd.conf is as follows:

[main]
# how often to check for new updates (in seconds)
run_interval = 3600
# how often to allow checking on request (in seconds)
updaterefresh = 600

# how to send notifications (valid: dbus, email, syslog)
emit_via = syslog

# automatically install updates
do_update = yes
# automatically download updates
do_download = yes
# automatically download deps of updates
do_download_deps = yes

Despite these settings no updates get installed until I run Yum manually, and I
see no log messages whatsoever from Yum-updatesd, neither in /var/log/messages
nor in /var/log/yum.log. I haven't seen any crashes or excessive CPU usage. It
stopped hogging /var/run/yum.pid when I changed emit_via from dbus to syslog.

As of 12-3-06, yum-updatesd still desn't work as best I can tell with a newly
installed Fedora Core 6 and the latest upgraded package.

Here is the script in /usr/sbin/yumupdatesd
#!/usr/bin/python
import sys
try:
   import yum
except ImportError:
   print >> sys.stderr, """\
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:

   %s

Please install a package which provides this module, or
verify that the module is installed correctly.

It's possible that the above module doesn't match the
current version of Python, which is:
%s

If you cannot solve this problem yourself, please go to 
the yum faq at:
  http://wiki.linux.duke.edu/YumFaq
  
""" % (sys.exc_value, sys.version)
   sys.exit(1)

sys.path.insert(0, '/usr/share/yum-cli')
try:
    import yumupd
    yumupd.main()
except KeyboardInterrupt, e:
    print >> sys.stderr, "\n\nExiting on user cancel."
    sys.exit(1)

I tried running python manually and entering the commands.  (I am not a python
programmer, so I was guessing.
import sys worked
import yum worked
import yumupd failed.  It claimed there is no such module.

Indeed there is no such package in the yum packages directory.  There is such a
package in a share directory.  I tried linking to it, but it made no difference.


 

(In reply to comment #19)
...
> yum + cron was nice... this yum daemon idea is better.
...

I'm not a yum expert, so I'm certainly open to being wrong, but the simplicity
of yum+cron vs. yum-updatesd:
---
 wc -l /etc/init.d/yum /etc/cron.daily/yum.cron  /etc/yum/yum-daily.yum
  69 /etc/init.d/yum
   6 /etc/cron.daily/yum.cron
   3 /etc/yum/yum-daily.yum
  78 total
---
wc -l /etc/init.d/yum-updatesd /usr/sbin/yum-updatesd /usr/share/yum-cli/yumupd.py
   63 /etc/init.d/yum-updatesd
   32 /usr/sbin/yum-updatesd
  622 /usr/share/yum-cli/yumupd.py
  717 total
---

seems pretty compelling, especially for those of us who either aren't
dealing with graphical systems, or don't care about notification
applets (what else is there which makes use of the daemon+dbus stuff
at the moment?).

I don't want to unnecessarily promote there being 2 ways to do
something, but until someone explains how this is sufficiently better
then yum+cron as to not bother with such a simple and functional
system, I would also like to see an extras package for yum+cron, even
once this bug is fixed, and on that note, my take on debugging is
appended below.

If you're having trouble duplicating yum-updatesd's dysfunctionality,
I suggest trying it on a minimal install.  I have yet to actually see
it work at all on any system and that's across a heterogenous (diff
hardware, some upgrades - some fresh installs, diff people doing the
install, some desktops - some embedded, etc) mix of ~10 different
systems.

----------------------------------------------------------------------
> uname -a
Linux grx3.bio.bnl.gov 2.6.18-1.2798.fc6 #1 SMP Mon Oct 16 14:37:32 EDT 2006
i686 i686 i38\
6 GNU/Linux
> rpm -qf /usr/share/yum-cli/yumupd.py
yum-3.0.1-2.fc6
-added 'proxy=http://<ip>[:<port>]' entry to /etc/yum.conf
-changed /etc/yum/yum-updatesd.conf:
        run_interval = 21600
        do_{update,download{,_deps}} = yes

-found the '-f' flag to /usr/share/yum-cli/yumupd.py -> main()

-tweaked startup script:
diff /etc/init.d/yum-updatesd{,~}
23,26c23
< # matts attempt to debug auto update issue
<       export PYTHONDEBUG=3
<       daemon yum-updatesd -f
< #     daemon yum-updatesd
---
>       daemon yum-updatesd

-started yum-updatesd as:
> strace /etc/init.d/yum-updatesd start 2>yum-updates.stderr | tee
yum-updates.stdout
Starting yum-updatesd: Loading "installonlyn" plugin

-after initially running the above and immediately getting the above (and only)
stdout output, I could still 'yum list updates' just fine.

-the next day (2 "run_interval"s later), no additional stdout output,
but I got the following additional stderr output (I was 'tail -f'ing
the stderr file and had hit return a couple times after the initial
spew of strace output), and 'yum list updates' then complained
about another copy running:

** Message: sqlite cache needs updating, reading in metadata
gconfd-2: no process killed
Exception in thread UpdateInstallThread:
Traceback (most recent call last):
  File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap
    self.run()
  File "/usr/share/yum-cli/yumupd.py", line 300, in run
    self.success()
  File "/usr/share/yum-cli/yumupd.py", line 267, in success
    self.updd.emitUpdateApplied()
  File "/usr/share/yum-cli/yumupd.py", line 523, in emitUpdateApplied
    map(lambda x: x.updatesApplied(self.updateInfo), self.emitters)
  File "/usr/share/yum-cli/yumupd.py", line 523, in <lambda>
    map(lambda x: x.updatesApplied(self.updateInfo), self.emitters)
  File "/usr/share/yum-cli/yumupd.py", line 197, in updatesApplied
    self.dbusintf.UpdatesAppliedSignal(updinfo)
  File "/usr/lib/python2.4/site-packages/dbus/decorators.py", line 56, in
emit_signal
    iter.append(arg)
  File "dbus_bindings.pyx", line 1081, in dbus_bindings.MessageIter.append
  File "dbus_bindings.pyx", line 1305, in dbus_bindings.MessageIter.append_array
IndexError: list index out of range

Exception in thread UpdateInstallThread:
Traceback (most recent call last):
  File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap
    self.run()
  File "/usr/share/yum-cli/yumupd.py", line 300, in run
    self.success()
  File "/usr/share/yum-cli/yumupd.py", line 267, in success
    self.updd.emitUpdateApplied()
  File "/usr/share/yum-cli/yumupd.py", line 523, in emitUpdateApplied
    map(lambda x: x.updatesApplied(self.updateInfo), self.emitters)
  File "/usr/share/yum-cli/yumupd.py", line 523, in <lambda>
    map(lambda x: x.updatesApplied(self.updateInfo), self.emitters)
  File "/usr/share/yum-cli/yumupd.py", line 197, in updatesApplied
    self.dbusintf.UpdatesAppliedSignal(updinfo)
  File "/usr/lib/python2.4/site-packages/dbus/decorators.py", line 56, in
emit_signal
    iter.append(arg)
  File "dbus_bindings.pyx", line 1081, in dbus_bindings.MessageIter.append
  File "dbus_bindings.pyx", line 1305, in dbus_bindings.MessageIter.append_array
IndexError: list index out of range
...repeat that repeating chunck every "run_interval"...
----------------------------------------------------------------------

and yes... dbus is running on my system

> /etc/init.d/messagebus status
dbus-daemon (pid 1569) is running...
> ps -ef|grep dbus
dbus      1569     1  0 Nov27 ?        00:00:00 dbus-daemon --system
root     21053 11991  0 09:18 pts/9    00:00:00 grep dbus

Curious what the status of this is...

I upgraded fc5 to fc6 a few days ago and noticed that yum-updatesd didn't seem 
to be working.  However, after a few days of monitoring, I see that it does 
seem to be updating but the notification is not working.  I can't find anywhere 
that indicates that updates have taken place other than the fact that if I rpm -
qi package, I can see that it was installed after I last checked.

Last night before calling it a night I ran "yum update" to see if there were 
any updates available...
---> Package parted.i386 0:1.8.1-1.fc6 set to be updated
---> Package squid.i386 7:2.6.STABLE6-1.fc6 set to be updated
---> Package grep.i386 0:2.5.1-54.1.2.fc6 set to be updated
---> Package vte.i386 0:0.14.1-1.fc6 set to be updated
---> Package ghostscript.i386 0:8.15.3-1.fc6 set to be updated

I said no to installing the updates then checked again this morning.  I 
ran "yum update" and got "No Packages marked for Update/Obsoletion".

As you can see, grep did in fact update:
rpm -qi grep
Name        : grep                         Relocations: (not relocatable)
Version     : 2.5.1                             Vendor: Red Hat, Inc.
Release     : 54.1.2.fc6                    Build Date: Wed 22 Nov 2006 
01:42:25 PM CST
Install Date: Tue 12 Dec 2006 10:32:08 PM CST      Build Host: hs20-bc2-
2.build.redhat.com

So, from my standpoint, I'd say yum-updatesd appears to be doing the updates 
but not sending any notifications.
(I tried dbus as well as email)

As far as I can tell nothing has changed since I wrote comment 26.  On a well
bahaved system the updatesd runs and will download and apply updates.  However
it won't log this fact anywhere, no matter what options you set in
updatesd.conf.  This isn't right.  At the very least all actions should be
logged to /var/log/yum.log and if you've set to log to syslog then something
should appear in /var/log/messages (or somewhere more specific).

On other systems a lot of people (including me) have reported that the updatesd
crashes but leaves the lock file in place which stops further use of yum.  It
also often corrupts the rpm database so you need to manually intervene to get
things working again.

As nothing has appeared in this report from the maintainer in well over a month
I'm afraid I've had to give up on this and now just use a cron job to apply
updates nightly.  I've had no problems with this approach even on systems whic
for which updatesd crashed.  Getting updates reliably isn't something I can
manage without for this long and I didn't want to wait any longer to migrate my
remaining systems over from FC5.

My yum-updatesd.conf is set up just to notify me via dbus that updates are
available.   Sometimes it works and sometimes it doesn't, and i can't figure out
why.  It may have something to do with whether or not I've recently rebooted.

I'd rather see this as a serious security problem for many 'average users' not
getting updates. So we'd better consider this 'urgent' I think.

(And yes: I liked the old simple yum+cron more too)

Upon additional checking, I find that I am notified via dbus if there are
updates available only after a shut down the computer and restart it.  Just
rebooting doesn't appear to do it.

Sorry to sound like an idiot but how do I get yum to update with a cron and
accept the changes. This is really mental that this is not automatic.

is this right

yum -y update

Cheers

Comment 7 and Comment 8 have binary and source RPM packages for the old
mechanism. [Note I haven't actually tried these].

The old script was simply:

#!/bin/sh

/usr/bin/yum -R 10 -e 0 -d 0 -y update yum
/usr/bin/yum -R 120 -e 0 -d 0 -y update


..just drop this in /etc/cron.daily, make it executable and you're good to go.

Thanks for that, still learning all this. I was trying to do it another way, but
I will go with you on this one:

I did try the following as my setup script

echo '@Daily yum -y update' >> /var/spool/cron/root

I just want to echo that yum-updatesd is broken on my workstation as well; I
came in this AM to a sluggish workstation, and found it was consuming ~250M RAM.
 I've turned it off and am installing the above cron job.  I agree this is a
serious issue.

It's a double-serious issue due to the chicken-and-egg problem.  Not only are
people not getting updates (and won't even know it if they're not paying closer
 attention than your average user), but when the problem is fixed, they won't
get pushed the update (since the update feature is what's broken) - so will be
perpetually un-updated until they upgrade to a future, working version of Fedora. 

Here's hoping there's not a serious security flaw in FC6 which will need patched
at some point.

I installed Fedora 6 today for the first time and am very new to this Linux 
stuff.  I get the same problem but if you stop yum-updatesd and then tell the 
system to do the updates, there are 165 of them according to the info listed 
in the brown notification bag.  Currently it is doing the updates.  At first I 
thought it had hung but left it alone and it continued on to then show a list 
of updates available.

So I am currently in the middle of that.

An update:

My yumupdatesd daemon process two days ago was using 250+ megs of memory.  I
can't see using this any longer as it grinds my machine to a halt, and doesn't
actually perform updates.

Hello,

I experienced these problems as well, on many machines.

Actually, the yum-updatesd.conf is as follows
[main]
# how often to check for new updates (in seconds)
run_interval = 86400
# how often to allow checking on request (in seconds)
updaterefresh = 600

# how to send notifications (valid: dbus, email, syslog)
emit_via = dbus

# automatically install updates
do_update = yes
# automatically download updates
do_download = yes
# automatically download deps of updates
do_download_deps = yes

and I only get a lock stating that "another instance of yum is already running".

I consider this a serious bug, since many routers don't get updates.

Regards,
Răzvan

Hello,

I experienced these problems as well, on many machines.

Actually, the yum-updatesd.conf is as follows
[main]
# how often to check for new updates (in seconds)
run_interval = 86400
# how often to allow checking on request (in seconds)
updaterefresh = 600

# how to send notifications (valid: dbus, email, syslog)
emit_via = dbus

# automatically install updates
do_update = yes
# automatically download updates
do_download = yes
# automatically download deps of updates
do_download_deps = yes

and I only get a lock stating that "another instance of yum is already running".

I consider this a serious bug, since many routers don't get updates.

Regards,
Răzvan

I have a slightly different problem, in that after upgrading from Fedora 5 (with
all the updates added) to Fedora 6, I have no YUM service available to
start/run.  I also have no /etc/yum/yum-updatesd.conf on the drive.  I am sure
that the service was available and working before the upgrade to Fedora 6.  I am
new to Fedora so I am working my way through this problem very cautiously.

Thank you
Paul Cushing

I can see Segmentation fault aftery trying to run yum-updatesd manually from
console. I am using this configuration to test it:

[main]
run_interval = 10
updaterefresh = 10
emit_via = email
email_to = root@localhost
do_update = yes
do_download = yes
do_download_deps = yes

Without do_update=yes it is working, when yum is trying to update packages it
hangs. I have tryed to switch off selinux without success.

There is it's output:
[root@work ~]# yum-updatesd -f
error: cannot open Packages database in /var/lib/rpm
error: cannot open Packages database in /var/lib/rpm
error: cannot open Packages database in /var/lib/rpm
error: cannot open Packages database in /var/lib/rpm
... many same lines ...
error: rpmdbNextIterator: skipping h#     962 Header V3 DSA signature: BAD, key
ID 4f2a6fd2
error: rpmdbNextIterator: skipping h#     962 Header V3 DSA signature: BAD, key
ID 4f2a6fd2
error: rpmdbNextIterator: skipping h#     984 Header V3 DSA signature: BAD, key
ID 4f2a6fd2
error: rpmdbNextIterator: skipping h#     984 Header V3 DSA signature: BAD, key
ID 4f2a6fd2
error: rpmdbNextIterator: skipping h#     689 Header V3 DSA signature: BAD, key
ID 4f2a6fd2
error: rpmdbNextIterator: skipping h#     689 Header V3 DSA signature: BAD, key
ID 4f2a6fd2
error: rpmdbNextIterator: skipping h#     398 Header V3 DSA signature: BAD, key
ID 4f2a6fd2
Segmentetion fault
[root@work ~]#

In response to comment #54 from Paul Cushing: the yum package is now split into 3 separate 
packages - yum, yum-updatesd (which apparently didn't automatically get installed when you 
upgraded from FC5 to FC6), and yum-cron (the unofficial but working update package from 
comment #7 by Alec Habig).  Your best bet would probably be to get the yum-cron package 
attached to this bug report, and not bother with yum-updatesd as it doesn't seem to be working 
for quite a lot of people, and even when it works it doesn't log anything.

I am still having this problem.  I'm using the latest FC6 update:

yum-updatesd-3.0.3-1.fc6

This is my config:

[main]
# how often to check for new updates (in seconds)
run_interval = 3600
# how often to allow checking on request (in seconds)
updaterefresh = 600

# how to send notifications (valid: dbus, email, syslog)
emit_via = dbus email syslog

# automatically install updates
do_update = yes
# automatically download updates
do_download = yes
# automatically download deps of updates
do_download_deps = yes

The process is running since Jan 17:

root      4755  0.0 35.0 739544 679056 pts/2   S      Jan 17 00:00:18
/usr/bin/python /usr/sbin/yum-updatesd

rpm -qa --last confirms that I've received no updates since Jan 17.  There is
nothing at all logged in /var/log/yum.log or /var/log/messages from yum-updatesd
since I last ran 'yum update' manually.  I cannot run 'yum update' now due to
the pid file lock:

# yum update
Loading "installonlyn" plugin
Existing lock /var/run/yum.pid: another copy is running. Aborting.

I am still having this problem.  I'm using the latest FC6 update:

yum-updatesd-3.0.3-1.fc6

This is my config:

[main]
# how often to check for new updates (in seconds)
run_interval = 3600
# how often to allow checking on request (in seconds)
updaterefresh = 600

# how to send notifications (valid: dbus, email, syslog)
emit_via = dbus email syslog

# automatically install updates
do_update = yes
# automatically download updates
do_download = yes
# automatically download deps of updates
do_download_deps = yes

The process is running since Jan 17:

root      4755  0.0 35.0 739544 679056 pts/2   S      Jan 17 00:00:18
/usr/bin/python /usr/sbin/yum-updatesd

rpm -qa --last confirms that I've received no updates since Jan 17.  There is
nothing at all logged in /var/log/yum.log or /var/log/messages from yum-updatesd
since I last ran 'yum update' manually.  I cannot run 'yum update' now due to
the pid file lock:

# yum update
Loading "installonlyn" plugin
Existing lock /var/run/yum.pid: another copy is running. Aborting.

I've left yum-updatesd running since Jan 17.  It is now taking 2.6gig memory,
813meg resident in RAM:


 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 4755 root      15   0 2664m 813m 2288 S    0 43.0  14:48.25 yum-updatesd       

How can I help debug this?

I've been seeing lots of RPM database corruption on fc5 and fc6 (which is
probably a different bug, perhaps bdb related) - could this just be a symptom of
it?  Simon mentioned deleting the *log files back in November, but I've found a
more kosher approach is to:

1) kill everything trying to access the rpm database - rpm, rpmq, yum, etc.
2) cd /var/lib/rpm
3) sudo db_recover

Anybody want to try that for some extra data points?

My system did not have db_recover, but I installed it and run the command.

No differences what so ever, yum-updatesd is running, the yum-pid file was left
there, no updates, no emails, nothing.

My system finally horked when all memory (2G) and all swap (2G) was used up by
mainly two processes, yum-updatesd (800+ MB resident RAM) and clock-applet (500+
MB resident RAM).  I've stopped using yum-updatesd and switched to yum-cron instead.

My system finally horked when all memory (2G) and all swap (2G) was used up by
mainly two processes, yum-updatesd (800+ MB resident RAM) and clock-applet (500+
MB resident RAM).  I've stopped using yum-updatesd and switched to yum-cron instead.

This is basically a "me too" added to this bug report.  

Using yum-updatesd is an exercise in frustration.  Every once in a while, it
appears to work.  Then it stops working for some reason, perhaps a system
reboot.  There are no error messages, notifications, warnings... certainly no
e-mails even though I set "emit-via = email" in /etc/yum/yum-updatesd.conf. 
There isn't even a reliable Changelog in /usr/share/doc, rpmfind.net, or other
resources so I can know what the latest fixes are.  Yum-updatesd is the "silent
package" -- no logs, no warnings, no errors, no info, no debug options... and
apparently does nothing.

This is particularly annoying because I maintain a cluster of systems that
require automatic updates.  The FC6 boxes on the cluster are not being updated
reliably with yum-updatesd.  I have no choice but to disable this package and go
with yum-cron indefinitely, even with future Fedora releases.  I'll have to
stick with this approach until there is a positive statement from the package
developer that these issues have been resolved.

Joining the Chorus of Discontent. I've been trying to get this daemon to do
something - anything - since FC6 release. Latest rev 3.0.3-1.fc6 loads fine but
never updates or logs anything. My config is the same as #36 above. Sometimes I
get the pid.lock, but I just clear it an manually run yum. Identical non-results
on two different machines. Can't find anything to capture as error log
information. This really needs some attention.

I just 'yum upgraded' three systems from fc5 to fc6. Yes, I did the
groupupdates for Base, etc and I have the new yum and yum-utils installed.

I modified the config file for yum-updatesd to "yes" in all three
places, and the system are not auto-updating.

I've disabled /etc/init.d/yum-updatesd (chkconfig --del yum-updatesd) and I'm
reverting back to the /etc/cron.daily/yum method.

People keep saying that the yum-updatesd method is better
than the old method, but if it doesn't work properly, I just don't
see how it's "better". Didn't we go from auto-updates working
properly by default in fc5 to it not being the default and
not working at all in fc6?

-David

Shouldn't this bug be marked as security critical?  I've run into several Fedora
users here at Sydney Uni who don't realise they're not getting updates, which is
a pretty serious security problem!  (Of course fixing this bug isn't going to
help people who aren't getting updates and don't realise there's a problem,
since they'll never get the fixed yum-updatesd...)

I'd like to ad a "Me to" to this bug. My computer runs FC6 on x86_64. I have
been updating manually. I have configured yum-updatesd to get updates. With
yum-updatesd running I do not get updates. yum-updatesd leaks huge amounts of
memory. I can not run yum when yum-updatesd has run-away. I can not stop a
run-away yum-updatesd. When I kill a run-away yum updatesd, I get rpm database
corruption.

*** Bug 211767 has been marked as a duplicate of this bug. ***

Hello,


I'm trying to summarize: it seems that the official yum-updatesd still have no
working correction for the "Existing lock /var/run/yum.pid: another copy is
running. Aborting." matter. On the other hand, I see in comment #56 that there
*is* a parallel working solution, namely yum-cron.

I have the described problem, too, on a large number of systems, no matter if
they are installed from scratch with FC6 or upgraded from previous versions.

For the time being, please, is it possible to publish yum-cron as an "official"
update that will temporarily (but automatically) disable/replace yum-updatesd
until a solution is found for the latest? Manually installing yum-cron, to
replace yum-updatesd on a large number of systems, is a tedious task, especially
if a future upgrade will want to do the reverse, when a (fixed) version of
yum-updatesd is published...


Many thanks,
Răzvan

Not exactly. I don't have a problem with locks or the lock file. The problem I
described is that yum-updatesd won't do the updates no matter what the settings
are in its .conf file.

So, there's the lock file problem, the problem with logging not logging properly
and the problem that it won't do the updates at all and that the default
settings don't do automatic updates. The previous set of defaults for nightly
updates is that yum would default to updating Fedora based systems.

-David

Thank you.

However, as I said above, is it possible, please, to:

- insert the package yum-cron as a default "update", in order to substitute
yum-updatesd via default channels;
- automatically disable yum-updatesd (disable, not uninstall!) , at least until
a solution is found ?


The problem is that, on big installations where tens or hundreds of systems are
running, it is pretty difficult for the administrator to manually install
yum-cron on each system and disable yum-updatesd...


Thanks a lot,
Răzvan

Thank you.

However, as I said above, is it possible, please, to:

- insert the package yum-cron as a default "update", in order to substitute
yum-updatesd via default channels;
- automatically disable yum-updatesd (disable, not uninstall!) , at least until
a solution is found ?


The problem is that, on big installations where tens or hundreds of systems are
running, it is pretty difficult for the administrator to manually install
yum-cron on each system and disable yum-updatesd...


Thanks a lot,
Răzvan

Thank you.

However, as I said above, is it possible, please, to:

- insert the package yum-cron as a default "update", in order to substitute
yum-updatesd via default channels;
- automatically disable yum-updatesd (disable, not uninstall!) , at least until
a solution is found ?


The problem is that, on big installations where tens or hundreds of systems are
running, it is pretty difficult for the administrator to manually install
yum-cron on each system and disable yum-updatesd...


Thanks a lot,
Răzvan

I second the solution proposed in comment #72.

If this is impossible than, please, add yum-cron to the extras repository as I
already suggested in comment #18 on November 3, that is over three months ago
(sigh).

Yes, it can be enough for all users. I want to ask him too, add yum-cron to Core
or Extras.

If somebody has tens of systems, it can update them manually, if hundreds and he
has no it's own repository, it is a crazy man, especially, if he is trying not
fully functional systems on all of them. :)

Er, me too. I've had yum-updatesd use up all the memory it can twice now,
invoking oom-killer and crashing the machine. Kinda sucks when the machine is on
the other side of town.

Hate to join the Me To list, but here I am.
Fresh new FC6 install, same problem.

Besides, I'm running KDE, and I understand that the nifty little notification
icon will only show in Gnome?
If so, I have really no need for the deamon, and will probably just run the cron
job. Only added benefit of the deamon would be to receiving email notification
that updates had been done. That would let me know if I needed to boot the box
up on a new kernel release.

Guess the Cron job could somehow be extended to capture and mail the new entries
in /var/log/yum.log instead.

Thanks for providing the yum-cron RPM by the way.

Br
Jan 

The yum cron job, like all root cron jobs, outputs mail to root already.  Just
alias root to your user account in /etc/aliases.

Even better - thanks for the tip (I am still newby in Linux).

I had added a quick and dirty check for updates in yum.log.
It compares the log entries to current date, and sends the output to the mail
address of choice if any matching log entries where found.

But your suggestion to use alias seams easier and more clean.

Br
Jan

In response to the last few comments:

Cron jobs generally only mail to root if they've got output from stdin or
stderr.  yum-cron doesn't generate any if it works, it will if there's a problem.

However, no need to hack the thing to look in yum.log - that's what logreader is
for.  logreader knows about yum.log and will add a nice summary of what yum's
done to your daily system status email.  If you've not already enabled
logreader, I highly reccommend it.

I'm running yum out of cron and that seems to work ok, but /var/log/yum.log is
not being updated.  This is happening across at least four machines.

Do I need to do something more than having logfile=/var/log/yum.log in
/etc/yum.conf?

In reply to #82 there was another bug introduced in a yum update which stopped
the yum.log file being updated if you use -d 0 on the command line (which was
the default in yum cron to keep it quiet).

I've had to ammend my /etc/cron.daily/yum.cron to use 

/usr/bin/yum -R 10 -e 0 -d 2 -y update yum
/usr/bin/yum -R 10 -e 0 -d 2 -y update yum

This causes yum.log to be updated again but also generates a cron mail everyday
due to the other unwanted debugging output.

I did put this in another bugzilla report (there was one open already), but I
don't think it's seen any attention.

Simon's comment #83 about the lack of logging got me wondering (the most recent
kernel update blindsided me since yum.log wasn't updated), so here's the other
bugzilla report:

  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=222835

It's closed as "fixed upstream in the next version of yum", but that was a month
ago.

and it was fixed in 3.0.4. that's what 'upstream' means in this context.

sorry it took so long for a release of 3.0.X for fc6, I've been busy with my
$dayjob stuff and haven't had the time.

and it was fixed in 3.0.4. that's what 'upstream' means in this context.

sorry it took so long for a release of 3.0.X for fc6, I've been busy with my
$dayjob stuff and haven't had the time.

after 5 months of back and forth what is the resolution?
1) did 3.0.4 fix everything? lockfiles, loging, memory use?
2) on 3/18, the latest fc6 yum is 3.0.3-1 where do you get 3.0.4
3) will yum-updatesd only announce update via gnome desktop?
4) will yum-cron be an added package available via yum?

(In reply to comment #87)
> 2) on 3/18, the latest fc6 yum is 3.0.3-1 where do you get 3.0.4

3.0.4-1 (and even 3.0.5-1) are in Updates/testing, FWIW. In your favorite HTTP 
repository, go to the updates directory (so ultimately not updates/6/<arch>/, 
rather updates/testing/6/<arch>/).

Thanks Moritz.  Just to save everybody 5 minutes, for i386 (and maybe all arches
since this is a 'noarch' package?) do:

rpm -Uhv
http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/6/i386/yum-3.0.5-1.fc6.noarch.rpm
http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/6/i386/yum-updatesd-3.0.5-1.fc6.noarch.rpm
rpm -e yum-cron
/sbin/chkconfig --level 345 yum-updatesd on
/sbin/service yum-updatesd start

to get from yum-cron to yum-updatesd to test this.  When I ran mine it said no
packages were marked for update (yum-cron was working), so it'll be n days
before I know if it's working.  Fingers are crossed!

Update: I had another machine exhibiting symptoms that was offline for a few
weeks.  I did the above procedure on it and got 12 updates via yum-updatesd.
They were logged in /var/log/yum and  I got a dbus notification on X about it as
well.  With yum-updatesd still running, I was able to 'yum -y install htop'
without lockfile errors.  These are all problems apparently solved.  Yay!

WRT memory, yum-updatesd is running 39M RES, now polling by the second for
gettimeofday().  By way of comparison, X runs at 13M and mythbackend runs at
12M.  This seems excessive.

Apologies for declaring premature victory.

Last night I got another machine online that needed updates.  Lots of 'em -
1.2GB worth.

I did a 'yum -y update' and made sure it started downloading and went to bed. 
ETA was 07:30 based on current speed.  

Come in this morning, and there was a conflict with some atrpms packages in the
transaction test, so that failed.  Took care of that and did 'yum -y update',
and I got the PID file error.

I went and looked at the PID file and it was from 04:02, owned by yum-updatesd.
 I straced yum-updatesd and it was doing gettimeofday() each second, waiting to
wake up again, I presume.

I restarted yum-updatesd and was able to do my updates with yum.

So, the PID file problem doesn't appear to be fixed in current testing.

Reopening.  Running with yum-3.0.5-1.fc6 and the following conf file:

[main]
# how often to check for new updates (in seconds)
run_interval = 3600
# how often to allow checking on request (in seconds)
updaterefresh = 600

# how to send notifications (valid: dbus, email, syslog)
emit_via = email

# automatically install updates
do_update = yes
# automatically download updates
do_download = yes
# automatically download deps of updates
do_download_deps = yes

No updates have been applied.  "yum upgrade" indicates that there are a number
of packages to update.

yum-updatesd is also the largest memory user on the system at the moment:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 2514 root      15   0  481m 227m 3412 S  0.0 22.7   9:17.69 yum-updatesd
 3012 orion     15   0  237m 105m  14m R  7.3 10.5  47:54.36 firefox-bin

I do not believe the 3.0.5-1 release of yum and yum-updatesd has fixed all the
issues. Following the recent update push (that I got via yum cron) I shut down
the yum service, started yum-updatesd, and chkconfiged it. No problems reported.
My .conf matches #92 except emit_via=syslog. Rebooted system yesterday and
checked logwatch today: no packages. I then noticed the yum-updatesd was not
running. So I checked the following:
[root@dellinux ~]# yum --version
3.0.5
[root@dellinux ~]# chkconfig --list yum-updatesd
yum-updatesd    0:off   1:off   2:off   3:on    4:on    5:on    6:off
[root@dellinux ~]# service yum-updatesd status
yum-updatesd dead but subsys locked

Never seen that before. It always ran but did nothing. What is the same is that
there is nothing in yum.log for diagnostic help. Back to the reliable cron
process for now.

Maybe it's time to stop this fanaticism, obsolete this broken package and
replace it with yum-cron?

(In reply to comment #94)
> Maybe it's time to stop this fanaticism, obsolete this broken package and
> replace it with yum-cron?

my 2 cent as someone that was bitten by this bug and not a developer of said
packages:

I think it's time to close this bug (or better: close it again and leave it
closed) and open new ones for specific issues that still exists with the current
packages -- this one is much to long and confusing to really to be productive.
Annouce those new bugs here here you suspect other people in the CC list of this
bug have the same problem

/me removes himself from the CC

BTW: everybody afaics is free to submitt a yum-cron package to Fedora
http://fedoraproject.org/wiki/PackageMaintainers/Join

I don't know why you want to close it. The auto-update feature was working, then
it stopped working and I switched back to the cron.daily/yum method.

All I can say is that I watched it for a week, and watched update after update
get posted, and nothing updated with yum-updatesd, even though yum saw them.

It's not clear to me how "does not do anything at all" can be broken down into
"more specific issues"...

I've tried it on at least half a dozen machines, servers and desktops, clean
installs and machines that have been upgraded all the way from RH7.3, and on
none of them has yum-updatesd ever installed any packages, logged any messages
of any kind, or in fact show any signs of activity at all.

Now yumupdatesd is using 925m of memory.  It *is* performing automatic updates
though.  Memory leak or something?

I have some problem.

May be we need a "yum-updatesd-cron" script which restarts yum-updatesd daily or
hourly. :-)))

"yum-cron" works well without problems.

Checked if yum-updatesd-3.2.0-1.fc7.noarch.rpm in Fedora 7 solved any of the 
problems, but on two machines my experience is that automatic updates is still 
not working.  Removed yum-updatesd and installed yum-cron.

Even if yum-updatesd was working fine, I'm in the camp that says that a daemon 
is overkill for this purpose.  Why not a cron-based solution that can do the 
auto updates and/or notify the desktop through dbus?

Hello,

I noted that yum-cron was still not included in final version of Fedora 7. On
the other hand, the problem with yum-updatesd is still not solved.

Can we have a solution to this, somehow, please ? This tends to become a
"religious war"...

Maybe the best idea is to include *both* yum-crom and yum-updatesd in distro and
let users choose which of them to activate/use. Probably server administrators
will choose yum-cron and desktop users will activate yum-updatesd (when its
problems will be finally solved).



Regards,
Răzvan

Here's how to get a package added to Fedora:
  http://fedoraproject.org/wiki/PackageMaintainers/Join

It would be great if somebody here could champion it.

Created attachment 157386 [details]
an RPM of the scripts to drive yum updates via a cron file

In response to #102 and #95, I've beat on the yum-cron package a bit and signed
up for mailing lists to get this thing into the extras repository.  Before I
send it in, could interested parties on this bug test it for a week.  Updated
rpm, srpm attached, and it's signed with my public gpg keys as always.

Created attachment 157387 [details]
The SRPM of the scripts needed to drive yum updates via cron

The SRPM for the above RPM.  Please test these suckers out!

I'm happy someone decided to do this finally. I proposed adding it to extras
back in November (in comment #18).

If your package is no different from the November one, I can report 7 months of
testing on four fc6 boxes (one of them recently upgraded to f7). yum-cron worked
with no problem on all of them (and survived successfully the f7 upgrade).

Created attachment 157392 [details]
an RPM of the scripts to drive yum updates via a cron file

The most substantial change is the renaming of the init.d script from yum to
yum-cron to meet the fedora extras naming convention.  Many smaller specfile
changes to follow all the extras specfile writing guidelines (a few more in
this attachment, sorry for the spam).

So, "it should just work", which are famous last words, hence the request for
testing by the experts/people who care CC'd onto this bug.

Created attachment 157393 [details]
The SRPM of the scripts needed to drive yum updates via cron

...and the SRPM.

Can we split "add yum-cron" into a separate bug? That's a decent work-around,
but doesn't solve the problem. yum-updatesd potentially offers a much better
approach.

Matt - right, that's step 7 on getting the package added.  Alec's done 1-6
already, and I expect/hope he's going to let us know here what that bug number is.  

n.b. the link I posted hasn't been updated for F7 - it still references
fedora-extras, though that's obviously appropriate for getting the package in
for FC6 (the extras associated with FC6 that is... the new naming is easier to
talk about too).

and here's step 7, the proposal to add yum-cron to Extras:

  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244894

I think that once it moves along the review process I'll have the option of
adding it to the FC6 extras as well as the current version.

So anyway - we can now move all the yum-cron traffic to that bug (not that we
were masking much discussion on actually fixing yum-updatesd, to be cynical
about it).

If you get a chance - test yum and yum-updatesd from rawhide out and reopen this
bug if it doesn't fix it. I think you'll find it should be MUCH more fault tolerant

Will successful testing in rawhide infer an update for fc6?  As I understand it
(could be wrong) it'd only make it into an f7 update if it's in rawhide (hence
this bug won't be fixed for fc6).

That's probably correct about fc6. There's 3 months left before the f8 release
so that means there is only 4 months of fc6 remaining. While it's possible this
could be backported it isn't incredibly likely.

Hehe, for me it didn't work because I had this in my config file:
 run_interval = 43200 # 12 hours
Only when running "yum-updatesd -f" I noticed the error and concluded it tried
to parse "43200 # 12 hours" as an integer number.

I guess I added this myself. Just wanted to let you know.