Description of problem: Some application is holding the yum lock. However, performing concurrent 'sudo yum update' results in a flood (several per second!) of the warning printed into the console. In the past it used to be one per second or so. It also makes the PID of the holding process disappear pretty quickly: [ykaul@ykaul ~]$ sudo yum update Loaded plugins: auto-update-debuginfo, fastestmirror, langpacks, presto, : refresh-packagekit Repository fedora-debuginfo is listed more than once in the configuration Repository fedora-source is listed more than once in the configuration Existing lock /var/run/yum.pid: another copy is running as pid 4422. Another app is currently holding the yum lock; waiting for it to exit... Another app is currently holding the yum lock; waiting for it to exit... Another app is currently holding the yum lock; waiting for it to exit... Another app is currently holding the yum lock; waiting for it to exit... Another app is currently holding the yum lock; waiting for it to exit... Another app is currently holding the yum lock; waiting for it to exit... Another app is currently holding the yum lock; waiting for it to exit... Another app is currently holding the yum lock; waiting for it to exit... Another app is currently holding the yum lock; waiting for it to exit... Another app is currently holding the yum lock; waiting for it to exit... Another app is currently holding the yum lock; waiting for it to exit... ^C Exiting on user cancel. [ykaul@ykaul ~]$ rpm -qa |grep yum yum-3.4.3-5.fc16.noarch yum-langpacks-0.2.2-1.fc16.noarch anaconda-yum-plugins-1.0-6.fc15.noarch yum-utils-1.1.31-2.fc16.noarch PackageKit-yum-plugin-0.6.19-2.fc16.x86_64 yum-plugin-auto-update-debug-info-1.1.31-2.fc16.noarch yum-presto-0.7.0-1.fc16.noarch PackageKit-yum-0.6.19-2.fc16.x86_64 yumex-3.0.3-1.fc16.noarch yum-plugin-fastestmirror-1.1.31-2.fc16.noarch yum-metadata-parser-1.1.4-5.fc16.x86_64 Version-Release number of selected component (if applicable): yum-3.4.3-5.fc16.noarch How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
*** This bug has been marked as a duplicate of bug 812668 ***
This is clearly not a dupe of 812668. It's complaining about the nature of the output yum prints when it encounters a lock, not the fact of the lock itself. Re-opening. Dan, please be careful when wielding the dupe stick. It can be dangerous.
It's related pretty closely, IMO. Yum normally retries the lock every 2s but when it fails to show the lock owner, it assumes its 'exiting' anyway, and retries every 0.1s. show_lock_owner(PID) does some /proc parsing which errs on zombies. Ignoring such lockers early fixes both issues (lock not obtained + flooding the screen).
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This is still happening on Rawhide.
*** This bug has been marked as a duplicate of bug 810530 ***
No, not a dupe. The description specifically states the objection here: that the message is printed too rapidly.
what is the status of this? if it's not a dupe can we get an update please? It's been more than 2+ weeks.
I'm not able to reprocude this bug. Please, when this happens again, make a copy of /proc/4422/status and /proc/4422/stat files, and attach these (replace 4422 with the actual locker PID. If it's already off the screen, You'll find it in /var/run/yum.pid).
Haven't encountered for quite some time. I guess providing the comments above when the bug actually happened and not half a year later, would have been more productive, but this is a repeating pattern with most of my Fedora bugs. I'll close with INSUFFICIENT_DATA.
Sounds good. Not receiving it anymore either.
yum-3.4.3-28.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/yum-3.4.3-28.fc17
yum-3.4.3-28.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.