Bug 812668 - PackageKit holds the yum lock too often
PackageKit holds the yum lock too often
Status: CLOSED DUPLICATE of bug 810530
Product: Fedora
Classification: Fedora
Component: PackageKit (Show other bugs)
17
All Unspecified
high Severity high
: ---
: ---
Assigned To: Richard Hughes
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-15 16:06 EDT by Dan Mashal
Modified: 2012-05-29 00:01 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-04-18 22:36:09 EDT
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)

  None (edit)
Description Dan Mashal 2012-04-15 16:06:23 EDT
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 16:18:35 EDT
*** Bug 810530 has been marked as a duplicate of this bug. ***
Comment 2 Dan Mashal 2012-04-15 16:28:40 EDT
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 16:32:35 EDT
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 16:34:01 EDT
*** Bug 745281 has been marked as a duplicate of this bug. ***
Comment 5 Dan Mashal 2012-04-15 16:35:15 EDT
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 16:36:52 EDT
*** Bug 756406 has been marked as a duplicate of this bug. ***
Comment 7 Adam Williamson 2012-04-18 22:36:09 EDT
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 02:01:09 EDT
Sounds good.

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