Created attachment 577747 [details] terminal output Description of problem: while trying to use yum, i've got a message that another app is holding the yum lock. the app is PackageKit. this happened for more than ten minutes. Version-Release number of selected component (if applicable): # rpm -q PackageKit PackageKit-0.7.3-1.fc17.i686 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: packagekit should hold the yum lock only if it's doing something, not when it's sleeping. also, when it's doing something thus holding the yum lock, it should provide an estimated time of freeing the lock. Additional info: in all this time PackageKit was actually running about 5 times, for about one or two seconds each.
(In reply to comment #0) > packagekit should hold the yum lock only if it's doing something, not when it's > sleeping. It doesn't hold the lock when sleeping. > also, when it's doing something thus holding the yum lock, it should > provide an estimated time of freeing the lock. Well, what was PK doing? If you do "pkmon" when it's busy, what is displayed? Richard.
today, after few days when the computer was not started: ... State : Sleeping, pid: 1644 Another app is currently holding the yum lock; waiting for it to exit... The other application is: PackageKit Memory : 52 M RSS (1.3 GB VSZ) Started: Thu Jun 14 22:43:22 2012 - 09:29 ago State : Sleeping, pid: 1644 Loading mirror speeds from cached hostfile ... all this time, pkmon displayed: $ pkmon\ > Transactions: [none] daemon connected=1 network status=online Transactions: 1 /85_ddbbdade_data Transactions: 1 /85_ddbbdade_data 2 /86_aaccdbdc_data /85_ddbbdade_data allow_cancel 1 /85_ddbbdade_data percentage -1 /85_ddbbdade_data role get-updates /85_ddbbdade_data status download-updateinfo /85_ddbbdade_data status finished /85_ddbbdade_data exit code: unknown /86_aaccdbdc_data allow_cancel 1 /86_aaccdbdc_data percentage -1 /86_aaccdbdc_data role get-distro-upgrades /86_aaccdbdc_data status wait /86_aaccdbdc_data status finished /86_aaccdbdc_data exit code: unknown
Current Rawhide - I logged in to install a couple of packages with yum, and got to wait for awhile: Another app is currently holding the yum lock; waiting for it to exit... The other application is: PackageKit Memory : 41 M RSS (447 MB VSZ) Started: Fri Sep 7 09:27:08 2012 - 23:13 ago State : Sleeping, pid: 1315 Another app is currently holding the yum lock; waiting for it to exit... The other application is: PackageKit Memory : 46 M RSS (452 MB VSZ) Started: Fri Sep 7 09:27:08 2012 - 23:15 ago State : Running, pid: 1315 [yum kicks in here] and pkmon showed this while waiting: Transactions: [none] daemon connected=1 network status=online Transactions: 1 /12_ceddedaa Transactions: 1 /12_ceddedaa 2 /13_adaadecd /12_ceddedaa allow_cancel 1 /12_ceddedaa percentage -1 /12_ceddedaa role get-updates /12_ceddedaa status download-changelog /12_ceddedaa status finished /12_ceddedaa exit code: unknown /13_adaadecd allow_cancel 1 /13_adaadecd percentage -1 /13_adaadecd role get-distro-upgrades /13_adaadecd status wait /13_adaadecd status finished /13_adaadecd exit code: unknown and this once my transaction was able to proceed: Transactions: 1 /13_adaadecd Transactions: 1 /13_adaadecd 2 /14_aaddeadd /14_aaddeadd allow_cancel 1 /14_aaddeadd percentage -1 /14_aaddeadd role update-packages /14_aaddeadd status wait /14_aaddeadd status finished /14_aaddeadd exit code: unknown Transactions: 1 /14_aaddeadd Transactions: [none] Is there any possibility that, after a couple of minutes, PackageKit could check for other applications attempting to acquire the yum lock and, if there are any, get out of the way, let them do their work, then try again later?
Got an even more extreme example today on a Fedora 18 i386 machine: ... Another app is currently holding the yum lock; waiting for it to exit... The other application is: PackageKit Memory : 31 M RSS (56 MB VSZ) Started: Mon Sep 10 10:25:15 2012 - 53:31 ago State : Sleeping, pid: 1222 Another app is currently holding the yum lock; waiting for it to exit... The other application is: PackageKit Memory : 31 M RSS (56 MB VSZ) Started: Mon Sep 10 10:25:15 2012 - 53:33 ago State : Running, pid: 1222 [yum gets to run here] pkmon output is similar to above, except it shows "download-updateinfo" instead of "download-changelog". I would really like some way of making PackageKit not start instantly when I login, or of telling it to exit and try again later, so I can do my yum transactions now instead of an hour from now.
An even more extreme example - Fedora 17 i386. Another app is currently holding the yum lock; waiting for it to exit... The other application is: PackageKit Memory : 48 M RSS (450 MB VSZ) Started: Fri Sep 14 10:35:15 2012 - 2 day(s) 22:10:15 ago State : Sleeping, pid: 1796 Another app is currently holding the yum lock; waiting for it to exit... The other application is: PackageKit Memory : 48 M RSS (450 MB VSZ) Started: Fri Sep 14 10:35:15 2012 - 2 day(s) 22:10:17 ago State : Sleeping, pid: 1796 Another app is currently holding the yum lock; waiting for it to exit... The other application is: PackageKit Memory : 48 M RSS (450 MB VSZ) Started: Fri Sep 14 10:35:15 2012 - 2 day(s) 22:10:19 ago State : Sleeping, pid: 1796 I ended up killing the yum update I was trying to run. I've tried killing the process holding the lock but it seems there is a huge backlog of other PackageKit processes waiting on the lock. My solution to this in the past has been to use two terminal windows one to setup the yum update which gets blocked and the other to kill the sleeping process holding the lock.
*** Bug 861602 has been marked as a duplicate of this bug. ***
Created attachment 619443 [details] [PATCH] yum-plugin: Ask PackageKit to quit when yum is started Following a conversation with Richard on Google+ [1], here is a patch to fix this issue. [1] https://plus.google.com/u/0/110933625728671692704/posts/jUTTvCmYKiM
(In reply to comment #7) > Created attachment 619443 [details] > [PATCH] yum-plugin: Ask PackageKit to quit when yum is started > > Following a conversation with Richard on Google+ [1], here is a patch to fix > this issue. I've applied this upstream, thanks. This means that any offline update that is being downloaded in the background gets cancelled and the packagekitd daemon quits. This allows the yum CLI to run successfully. The offline update client then re-requests the offline update and the daemon is started up and the download continues. Using the yum backend it still takes a few seconds for the process to quit, but that's substantially better than what we have now.
PackageKit-0.8.4-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/PackageKit-0.8.4-1.fc18
Package PackageKit-0.8.4-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing PackageKit-0.8.4-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-15147/PackageKit-0.8.4-1.fc18 then log in and leave karma (feedback).
PackageKit-0.8.4-3.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/PackageKit-0.8.4-3.fc18
I tried with PackageKit-0.8.4-3.fc18, using "pkcon --only-download --background update" to download updates in the background (or waiting until the automatic process catches on) and then running yum. I have to say it doesn't seem fixed, I receive usual warnings that yum lock is being held. Is this fixed in PackageKit, or in some yum plugin?
Kamil, can you please paste the exact output from yum in this bug? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
The same old stuff: $ sudo yum repolist enabled Loaded plugins: langpacks, presto, refresh-packagekit Existing lock /var/run/yum.pid: another copy is running as pid 1631. Another app is currently holding the yum lock; waiting for it to exit... The other application is: PackageKit Memory : 67 M RSS ( 90 MB VSZ) Started: Tue Oct 9 11:13:56 2012 - 01:38 ago State : Sleeping, pid: 1631 ...
PackageKit-0.8.4-3.fc18.i686 yum-utils-1.1.31-6.fc18.noarch PackageKit-yum-0.8.4-3.fc18.i686 yum-3.4.3-45.fc18.noarch yum-langpacks-0.3.0-2.fc18.noarch yum-metadata-parser-1.1.4-7.fc18.i686 PackageKit-yum-plugin-0.8.3-2.fc18.i686 yum-presto-0.9.0-1.fc18.noarch
Your PackageKit-yum-plugin is outdated. You need 0.8.4-1 or newer. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #16) > Your PackageKit-yum-plugin is outdated. You need 0.8.4-1 or newer. Well then it's clear, https://admin.fedoraproject.org/updates/PackageKit-0.8.4-3.fc18 does not fix this bug. An update with PackageKit-yum-plugin must be created and pushed to Bodhi.
No, you are wrong. this update *does* contain PackageKit-yum-plugin because PackageKit-yum-plugin is a subpackage of PackageKit. You don't need to explicitly include subpackages in bodhi updates (actually I'm pretty sure you can't even if you want to). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Aha, I see. The problem is that https://admin.fedoraproject.org/updates/PackageKit-0.8.4-3.fc18 is no longer in updates-testing (that's why I haven't received PK-yum-plugin update afterwards). It was unpushed, or it broke because it was edited, or maybe it's a Bodhi bug. In all cases, it needs to be pushed to updates-testing again.
After manually downloading PackageKit-yum-plugin-0.8.4-3.fc18.i686 from Koji, I can confirm this is fixed! Great job, guys. Now we just need to push this to updates :-)
https://admin.fedoraproject.org/updates/FEDORA-2012-17371 is the latest one.
Another app is currently holding the yum lock; waiting for it to exit... The other application is: PackageKit Memory : 28 M RSS ( 52 MB VSZ) Started: Wed Nov 21 21:40:24 2012 - 05:23 ago State : Sleeping, pid: 2768 with $ rpm -q PackageKit PackageKit-0.7.5-1.fc17.i686 and $ rpm -q PackageKit-yum-plugin PackageKit-yum-plugin-0.7.5-1.fc17.i686 In updates-testing i've found only ver. 0.7.6 .
cornel, this was improved in Fedora 18 (I can confirm that it works much better now), but I don't think it was backported into Fedora 17. Richard, do you plan to backport it to F17 as well?
I saw it once this morning: Another app is currently holding the yum lock; waiting for it to exit... The other application is: PackageKit Memory : 175 M RSS (1.3 GB VSZ) Started: Wed Dec 12 19:14:36 2012 - 00:17 ago # rpm -q PackageKit-yum-plugin PackageKit-yum-plugin-0.8.6-1.fc18.x86_64
(In reply to comment #24) > I saw it once this morning Well, it will sometime happen. We ask the deamon to quit, but sometimes it can't quit because it's busy. A way to fix this might be asking the deamon to quit more than once (we ask it to quit once when we start yum, and that's it) but I'm not sure if that's possible with the current yum plugin architecture. My patch makes this issue way less frequent, anyway.
(In reply to comment #25) > (In reply to comment #24) > > I saw it once this morning > > Well, it will sometime happen. > We ask the deamon to quit, but sometimes it can't quit because it's busy. A > way to fix this might be asking the deamon to quit more than once (we ask it > to quit once when we start yum, and that's it) but I'm not sure if that's > possible with the current yum plugin architecture. > > My patch makes this issue way less frequent, anyway. Actually, when I posted my comment, it was once. However, I have been doing a lot of package install/remove today and I have seen it several times. Yes, you are right that earlier it used to persist longer - i think its for a relatively shorter duration now.