Description of problem: With latest update of yum-cron, I am receiving lock failed updates every week. Looks like cron.daily and cron.weekly are run in parallel and yum does not like it. Version-Release number of selected component (if applicable): yum-cron-0.8.4-2.fc10.noarch How reproducible: always, every week Steps to Reproduce: 1. install and enable yum-cron, set root alias to you 2. wait for week end Actual results: /etc/cron.weekly/yum.cron: yum-cron: lock failed, PID 26830 is active Expected results: Nothing. Additional info: Here is how yum-cron is called from cron: [root@central ~]# grep yum /var/log/cron Sep 20 04:16:40 central run-parts(/etc/cron.daily)[25706]: starting yum.cron Sep 20 04:33:49 central run-parts(/etc/cron.weekly)[26950]: starting yum.cron Sep 20 04:33:49 central run-parts(/etc/cron.weekly)[14826]: finished yum.cron Sep 20 05:01:34 central run-parts(/etc/cron.daily)[15488]: finished yum.cron [root@central ~]# We really need this cron.weekly script? If yes, can you test in cron.daily script, if today is sunday and if yes, then run this part?
Ahh, something which escaped my testing but makes perfect sense. Yes, this is a problem. We do need yum-weekly to run a "yum clean" periodically, as otherwise /var/cache/yum fills up with GBs of old update rpms. Your suggest of a test for Sunday-ness in the daily job is a good idea, will make it configurable of course. In the meantime, a workaround would be to remove the /etc/cron.weekly/yum.cron script to avoid the collision.
(In reply to comment #1) > In the meantime, a workaround would be to remove the /etc/cron.weekly/yum.cron > script to avoid the collision. Can you fix this problem in 1-2 weeks, at least in fedora-testing? I don't like this particular solution. If you can build and submit an updates-testing package, I can test it on aprox. 10 servers.
Maybe new locking code should be reworked as I suggested in another bureport (see bug #469566).
A note that as part of the larger rework to solve this bug, bug 445894 and bug 526452 will also get addressed. Not till next week though, real life is nuts this week.
A test build of yum to try which hopefully resolves this bug: https://koji.fedoraproject.org/koji/buildinfo?buildID=135389 Let me know if this either works or causes more trouble.
Please, submit at least testing update and then I can update all my servers to test it on multiple machines. Thank you.
yum-cron-0.9.0-1.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/yum-cron-0.9.0-1.fc11
yum-cron-0.9.0-1.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/yum-cron-0.9.0-1.fc10
yum-cron-0.9.0-1.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/yum-cron-0.9.0-1.fc12
Pushed to testing. Note that this can take a few days to percolate through the system, but you can always go to the koji page and download the rpm manually.
yum-cron-0.9.0-1.fc11 has been pushed to the Fedora 11 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'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10340
yum-cron-0.9.0-1.fc10 has been pushed to the Fedora 10 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'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-10358
OK, updated on all my servers, but looking, that it will not update sysconfig/yum-cron automatically and default for cleanup day is: DAY=${CLEANDAY:-0123456} May be it will be better to have same default for sysconfig file and same defined in source. On my servers cleanup is leaved for default now, may be I can update sysconfig file later. We will see after weekend, if it's working better.
Doh - cut-n-paste disease, thanks for catching that. I'll wait to collect this glitch any other soon-to-be-discovered problems into a new release. Do note that not replacing the sysconfig file is intended, I don't want to clobber peoples' config tweaks. It should drop a yum-cron.rpmnew file in there for people to look at and incorporate any config changes into their own file (this is the standard way rpm handles such files).
Looks like everything works well, on systems where sysconfig file was replaced by new one (there was no change in this file) and on systems, where CLEANDAY was never set (I think they clean daily, but it works too).
yum-cron-0.9.1-1.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/yum-cron-0.9.1-1.fc11
yum-cron-0.9.1-1.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/yum-cron-0.9.1-1.fc10
yum-cron-0.9.1-1.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/yum-cron-0.9.1-1.fc12
yum-cron-0.9.1-1.fc10 has been pushed to the Fedora 10 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'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-10519
yum-cron-0.9.1-1.fc11 has been pushed to the Fedora 11 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'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10541
yum-cron-0.9.1-1.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
yum-cron-0.9.1-1.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
Hi, just followed up on google results. it seems that this bug is not fixed yet in RHEL 6.7 is there a way to configure the workaround?