Description of problem: The cron jobs check /var/lock/subsys/yum-cron to see if the service is enabled, however they do not create/remove/check for lock files for a running instance. This can result in multiple copies running simultaneously. Even worse, if the yum-updatesd is also installed and running, it will prevent the yum-cron processes from ever running (this may another issue; maybe yum-cron needs to conflict with yum-updatesd?). Then a theoretical unlimited number of yum processes will be started by the yum-cron jobs. I've attached a patch which adds some extra checking to the daily yum.cron script to fix these problems. I haven't verified if yum-updatesd would prevent the weekly package cleaning script from also running (I'm guessing so), but that should be looked at too. Version-Release number of selected component (if applicable): yum-cron-0.4-1.fc7
Created attachment 210911 [details] patch
Good catch on the multiple instances - will get better lockfiling rolled in based on your patch for daily and weekly jobs. Regarding its interaction with yum-updatesd. As I understand it, yum-updatesd should only be locking access to command line yum when it's actually yum-ing something rather than sleeping. At least, in bug 212507 locking out yum access forever was described as a bug, and allegedly fixed. What exactly is yum-updatesd locking? Not that I'd adverse to putting in a conflicts, but I could imagine that a workstation power user sort of person might want the goodness of yum-cron at night and on weekends, while still getting his blinky gnome button for updates that are pushed when he's logged in.
I haven't observed the yum-updatesd behavior changing. How I noticed this was about a week ago my computer lost power. After restarting it yum-updatesd was started again (I thought I had previously disabled it, but maybe installing an upgrade re-enables it?). When I noticed that my /var/log/yum.log lacked recent updates, I assumed yum-cron wasn't working. Instead 'ps' showed 3 instances of yum.cron running as well as yum-updatesd. Killing the yum.cron processes resulted in me receiving 3 cron emails containing hundreds (thousands?) of lines from yum.cron saying that it was waiting for the yum lock to release. Therefore, either yum-updatesd still holds a global lock, or there's a super-recent (within 1 week) update that changes that behavior.
Pushed yum-cron-0.5-1 to {devel, FC-6, F-7, EPEL-5} with Steve's lockfile stuff in both the daily and weekly yum-cron scripts. Should show up in F-7's testing repository soon. However, I am still doing research on how yum-updatesd works or is supposed to work, so will leave this bug open until we figure out what do to about yum-cron vs yum-updatesd conflicts.
yum-cron-0.5-1.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update yum-cron'
yum-cron-0.5-1.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
So Bodhi closed this bug automatically before I would have, but after doing more research on the yum-updatesd problems, it seems that yum-updatesd only locks out other yum transactions when it is either actively doing something (a good thing) or when it's hung (a bad thing). But hanging yum-updatesd is outside the scope of this bug, and for installations where yum-updatesd is behaving there's no reason to put in a conflicts -- the user might really want to have cron deal with updates when they're not logged in, but still get the blinky notification icon if they're working. Steve's lockfile magic does keep yum-cron from misbehaving. Apparently yum-updatesd has been completely re-written for F-8 and is much more stable. I would be interested in hearing from people running both packages on F-8.
Thanks for investigating yum-updatesd. IMHO it's the weakest point in Fedora. I sure hope the rewrite makes it usable.