Bug 745281 - yum floods the screen with 'another app is currently holding the yum lock' (instead of periodic prints)
Summary: yum floods the screen with 'another app is currently holding the yum lock' (i...
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: yum
Version: 17
Hardware: Unspecified
OS: Linux
high
medium
Target Milestone: ---
Assignee: Fedora Packaging Toolset Team
QA Contact: Dan Mashal
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-10-11 21:17 UTC by Yaniv Kaul
Modified: 2014-01-21 23:20 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-18 10:15:48 UTC
Type: ---


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 812668 None None None Never

Internal Links: 812668

Description Yaniv Kaul 2011-10-11 21:17:00 UTC
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:

Comment 1 Dan Mashal 2012-04-15 20:34:01 UTC

*** This bug has been marked as a duplicate of bug 812668 ***

Comment 2 Adam Williamson 2012-04-19 02:32:39 UTC
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.

Comment 3 Zdeněk Pavlas 2012-04-19 13:37:35 UTC
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).

Comment 4 Fedora Admin XMLRPC Client 2012-04-27 15:28:26 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 5 Dan Mashal 2012-05-20 20:11:30 UTC
This is still happening on Rawhide.

Comment 6 Dan Mashal 2012-05-31 04:19:45 UTC

*** This bug has been marked as a duplicate of bug 810530 ***

Comment 7 Adam Williamson 2012-05-31 05:48:21 UTC
No, not a dupe. The description specifically states the objection here: that the message is printed too rapidly.

Comment 8 Dan Mashal 2012-06-18 09:14:05 UTC
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.

Comment 9 Dan Mashal 2012-06-18 09:14:58 UTC
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.

Comment 10 Zdeněk Pavlas 2012-06-18 10:12:49 UTC
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).

Comment 11 Yaniv Kaul 2012-06-18 10:15:48 UTC
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.

Comment 12 Dan Mashal 2012-06-18 16:10:25 UTC
Sounds good. Not receiving it anymore either.

Comment 13 Fedora Update System 2012-06-25 08:31:34 UTC
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

Comment 14 Fedora Update System 2012-06-28 03:41:12 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.