Bug 812938 - packagekit sleeps for ten minutes holding yum lock
packagekit sleeps for ten minutes holding yum lock
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: PackageKit (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Elad Alfassa
Fedora Extras Quality Assurance
:
: 861602 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-16 11:48 EDT by cornel panceac
Modified: 2013-02-04 19:37 EST (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-13 06:48:42 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
terminal output (73.90 KB, text/plain)
2012-04-16 11:48 EDT, cornel panceac
no flags Details
[PATCH] yum-plugin: Ask PackageKit to quit when yum is started (2.05 KB, patch)
2012-09-30 10:19 EDT, Elad Alfassa
no flags Details | Diff

  None (edit)
Description cornel panceac 2012-04-16 11:48:59 EDT
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.
Comment 1 Richard Hughes 2012-04-16 11:57:28 EDT
(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.
Comment 2 cornel panceac 2012-06-14 15:56:49 EDT
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
Comment 3 Jerry James 2012-09-07 11:55:38 EDT
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?
Comment 4 Jerry James 2012-09-10 13:20:44 EDT
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.
Comment 5 Glenn L. Jenkins 2012-09-17 04:12:07 EDT
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.
Comment 6 Elad Alfassa 2012-09-30 10:16:47 EDT
*** Bug 861602 has been marked as a duplicate of this bug. ***
Comment 7 Elad Alfassa 2012-09-30 10:19:11 EDT
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
Comment 8 Richard Hughes 2012-10-01 04:42:37 EDT
(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.
Comment 9 Fedora Update System 2012-10-01 09:23:59 EDT
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
Comment 10 Fedora Update System 2012-10-01 16:02:36 EDT
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).
Comment 11 Fedora Update System 2012-10-04 07:11:14 EDT
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
Comment 12 Kamil Páral 2012-10-09 10:28:49 EDT
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?
Comment 13 Elad Alfassa 2012-10-09 10:39:56 EDT
Kamil, can you please paste the exact output from yum in this bug?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 14 Kamil Páral 2012-10-09 11:19:14 EDT
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
...
Comment 15 Kamil Páral 2012-10-09 11:20:04 EDT
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
Comment 16 Elad Alfassa 2012-10-09 11:35:42 EDT
Your PackageKit-yum-plugin is outdated. You need 0.8.4-1 or newer.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 17 Kamil Páral 2012-10-10 05:18:02 EDT
(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.
Comment 18 Elad Alfassa 2012-10-10 05:28:54 EDT
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
Comment 19 Kamil Páral 2012-10-10 06:51:24 EDT
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.
Comment 20 Kamil Páral 2012-10-10 06:58:20 EDT
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 :-)
Comment 21 Rex Dieter 2012-11-05 08:46:58 EST
https://admin.fedoraproject.org/updates/FEDORA-2012-17371
is the latest one.
Comment 22 cornel panceac 2012-11-21 15:01:36 EST
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 .
Comment 23 Kamil Páral 2012-11-21 15:08:16 EST
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?
Comment 24 Amit Saha 2012-12-12 20:13:49 EST
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
Comment 25 Elad Alfassa 2012-12-13 06:48:42 EST
(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.
Comment 26 Amit Saha 2012-12-13 07:29:48 EST
(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.

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