Bug 812668

Summary: PackageKit holds the yum lock too often
Product: [Fedora] Fedora Reporter: Dan Mashal <dan.mashal>
Component: PackageKitAssignee: Richard Hughes <hughsient>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: high    
Version: 17CC: awilliam, collura, dan.mashal, hughsient, jonathan, kparal, kvolny, mads, oliver.henshaw, robatino, rvitale, smparrish, tomek, ykaul
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-19 02:36:09 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Dan Mashal 2012-04-15 20:06:23 UTC
Description of problem:

Whenever trying to any packages via yum I quite often get a message that PackageKit has yum locked.


How reproducible:

Often

Steps to Reproduce:
1. Try to run a yum update or a yum install <package>

Actual results:

[root@Fedora17 dan]# yum install telnet
Loaded plugins: auto-update-debuginfo, fastestmirror, langpacks, presto,
              : refresh-packagekit
Existing lock /var/run/yum.pid: another copy is running as pid 1810.
Another app is currently holding the yum lock; waiting for it to exit...
  The other application is: PackageKit
    Memory :  43 M RSS (447 MB VSZ)
    Started: Sun Apr 15 13:01:37 2012 - 00:07 ago
    State  : Sleeping, pid: 1810
Another app is currently holding the yum lock; waiting for it to exit...
  The other application is: PackageKit
    Memory :  43 M RSS (447 MB VSZ)
    Started: Sun Apr 15 13:01:37 2012 - 00:09 ago
    State  : Sleeping, pid: 1810
Loading mirror speeds from cached hostfile
updates-debuginfo/metalink                               |  16 kB     00:00     
updates-testing-debuginfo/metalink                       |  12 kB     00:00     
 * fedora: mirrors.solfo.com
 * fedora-debuginfo: mirrors.kernel.org
 * updates: mirrors.usc.edu
 * updates-debuginfo: mirrors.usc.edu
 * updates-testing: mirrors.solfo.com
 * updates-testing-debuginfo: mirrors.solfo.com
Resolving Dependencies
--> Running transaction check
---> Package telnet.x86_64 1:0.17-52.fc17 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package         Arch            Version                  Repository       Size
================================================================================
Installing:
 telnet          x86_64          1:0.17-52.fc17           fedora           61 k

Transaction Summary
================================================================================
Install  1 Package

Total download size: 61 k
Installed size: 113 k
Is this ok [y/N]: 



Expected results:

PackageKit should lock yum way less often.

Comment 1 Dan Mashal 2012-04-15 20:18:35 UTC
*** Bug 810530 has been marked as a duplicate of this bug. ***

Comment 2 Dan Mashal 2012-04-15 20:28:40 UTC
As seen in the history this has hapepned over multiple releases of Fedora, and
is currently happening extremely often in Fedora 17 and is quite annoying. We
should not go final with this kind of issue. Proposed as a Fedora 17 final
blocker.

Comment 3 Kamil Páral 2012-04-15 20:32:35 UTC
Waiting for 9 seconds is no problem, waiting for 9 minutes is! If you kill that PID that holds the lock, PackageKit immediately spawns another thread and locks it again.

Comment 4 Dan Mashal 2012-04-15 20:34:01 UTC
*** Bug 745281 has been marked as a duplicate of this bug. ***

Comment 5 Dan Mashal 2012-04-15 20:35:15 UTC
Kamil, 

Nobody should have to wait at all to install a package via yum. As seen in this bug, people have had to wait a lot longer than a few seconds.

Comment 6 Dan Mashal 2012-04-15 20:36:52 UTC
*** Bug 756406 has been marked as a duplicate of this bug. ***

Comment 7 Adam Williamson 2012-04-19 02:36:09 UTC
Let's have the earlier filed bug with more information as the 'primary' bug and the later filed bug with less information as the dupe, rather than the other way around, shall we?

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

Comment 8 Dan Mashal 2012-04-19 06:01:09 UTC
Sounds good.