Bug 641691 - Packagekit background activity annoyingly disrupts commandline yum
Summary: Packagekit background activity annoyingly disrupts commandline yum
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: PackageKit
Version: 14
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-10-10 10:34 UTC by cam
Modified: 2012-04-15 20:14 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-04-15 20:14:11 UTC
Type: ---


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 812668 high CLOSED PackageKit holds the yum lock too often 2021-01-20 06:05:38 UTC

Internal Links: 812668

Description cam 2010-10-10 10:34:59 UTC
Description of problem:
When issuing yum commands I often see:

Another app is currently holding the yum lock; waiting for it to exit...

This message is repeated until PackageKit has finished whatever it was doing. I expect PackageKit won't automatically install things for me, although it may download things automatically for later installation (which should not lock anything).

Would it be possible to have PackageKit background activity to be of a lower priority to yum commands, or marked as a 'readonly' operation on the yum database such that the package kit activity is suspended / interrupted and restarted transparently when the user wants to issue a yum command? Ideally these background activities that don't lead to installing anything should never lock out a user wanting to issue a yum command.


Version-Release number of selected component (if applicable):
PackageKit-0.6.9-4.fc14.i686


How reproducible:
Intermittent, depending on Packagekit activity. However it seems to be triggered by the yum DB changing, so maybe issuing several yum commands in series increases the probability of seeing the message.

Steps to Reproduce:
1.boot machine
2.issue a yum command or two
3.
  
Actual results:
See the message interrupt your yum experience

Expected results:
No interruptions!

Additional info:

Comment 1 Richard Hughes 2010-10-13 08:09:51 UTC
(In reply to comment #0)
> Would it be possible to have PackageKit background activity to be of a lower
> priority to yum commands, or marked as a 'readonly' operation on the yum
> database such that the package kit activity is suspended / interrupted and
> restarted transparently when the user wants to issue a yum command? Ideally
> these background activities that don't lead to installing anything should never
> lock out a user wanting to issue a yum command.

No, yum requires us to have a read/write lock on the rpmdb and the metadata store. I agree it sucks.

> How reproducible:
> Intermittent, depending on Packagekit activity. However it seems to be
> triggered by the yum DB changing, so maybe issuing several yum commands in
> series increases the probability of seeing the message.

If you want to reduce the chance of this happening, remove PackageKit-yum-plugin and this stops PackageKit from updating caches when you run a manual yum command. This does mean the GUI won't match reality if you start using rpm and yum on the command line tho, so it's really a compromise.

Also checkout /etc/PackageKit/PackageKit.conf for lots of things to tweak if you want to be a power user. I hope that helps.

Richard.

Comment 2 Jon Masters 2010-10-14 13:05:07 UTC
Could not PackgeKit delay running this update until after any pending yum commands have completed? Perhaps wait 3-5 minutes in case a second command is run? That way, you get both out of the box. Sadly, I remove PackageKit entirely from most of my "production" machines because of this behavior and overall CPU usage of various bits.

Comment 3 cam 2010-10-14 14:45:58 UTC
Waiting for 5 minutes or so would probably work well.

Does PackageKit also wake immediately when a machine unsuspends? A delay then would have benefits too, giving the user the full capacity of the machine for whatever it is they unsuspended it to do...

Comment 4 Jon Masters 2010-10-15 08:27:06 UTC
It's funny. Now that I know it does this, I notice it even more every time I run yum, and I'm convinced that the fix is to hold off locking yum for 5 minutes, adding another 5 minutes if yum is locked again during the wait. That way the user can just do what they need on the command line.

Comment 5 Jon Masters 2010-10-15 08:27:39 UTC
Re-opening for comment on the waiting idea.

Comment 6 Richard Hughes 2010-10-18 08:12:22 UTC
(In reply to comment #3)
> Waiting for 5 minutes or so would probably work well.

5 minutes is a very log time to display the wrong information in a GUI..

> Does PackageKit also wake immediately when a machine unsuspends? A delay then
> would have benefits too, giving the user the full capacity of the machine for
> whatever it is they unsuspended it to do...

See /etc/PackageKit/PackageKit.conf, specifically:

# The time in seconds to wait when we get the StateHasChanged method
#
# This should be used when a native tool has been used, and the update UIs
# should be updated to reflect reality.
#
# default=5
StateChangedTimeoutPriority=5

# The time in seconds to wait after the computer has been resumed or any non
# package related system event
#
# We don't want to be doing an update check at the busy time after a resume
#
# default=600
StateChangedTimeoutNormal=600

You probably just want to set the first parameter to something like 600 as well.

Comment 7 cam 2010-10-18 10:35:26 UTC
(In reply to comment #6)
> (In reply to comment #3)
> > Waiting for 5 minutes or so would probably work well.
> 
> 5 minutes is a very log time to display the wrong information in a GUI..

What is the incorrect information? If it's the availability of updated software then I'm happy to wait five minutes for that. I wasn't aware of any other information routinely displayed by PackageKit.

Whenever I use a GUI to pull in updates there are still delays, so any background activity isn't avoiding those. I expect some delay when doing this anyway.

> > Does PackageKit also wake immediately when a machine unsuspends? A delay then
> > would have benefits too, giving the user the full capacity of the machine for
> > whatever it is they unsuspended it to do...
> 
> See /etc/PackageKit/PackageKit.conf, specifically:
> 
> # The time in seconds to wait when we get the StateHasChanged method
> #
> # This should be used when a native tool has been used, and the update UIs
> # should be updated to reflect reality.
> #
> # default=5
> StateChangedTimeoutPriority=5
> 
> # The time in seconds to wait after the computer has been resumed or any non
> # package related system event
> #
> # We don't want to be doing an update check at the busy time after a resume
> #
> # default=600
> StateChangedTimeoutNormal=600
> 
> You probably just want to set the first parameter to something like 600 as
> well.

It's good to know that the resume case has been dealt with - thanks for the info. I will try adjusting the first parameter and see if there is a perceived improvement. I think 60 seconds will be fine, if I haven't issued another command by then I probably won't.

Comment 8 Jon Masters 2010-10-20 07:59:19 UTC
Agreed. There's no problem in waiting. If you're running yum on the command line, you're not the GUI-only user and consequently would rather have yum run immediately and live with a few minutes of "wrong" information.

Comment 9 Jon Masters 2010-10-20 08:00:24 UTC
PackageKit could even just display a different icon or stop displaying notifications until it has had chance to re-check with yum.

Comment 10 Richard Hughes 2010-10-20 10:10:30 UTC
(In reply to comment #9)
> PackageKit could even just display a different icon or stop displaying
> notifications until it has had chance to re-check with yum.

Well, the delay is actually the delay in sending out the UpdatesChanged DBus signal, which advises the clients that the cached update lists are not valid anymore. We don't actually specify what timeout the client should wait before getting the update lists again, which is why we delay the signal.

I agree 5 seconds is a bit keen, and think 30 seconds is a good compromise:

commit 2c62053ed70de4383658409f13b5e720bd2ecd0c
Author: Richard Hughes <richard@hughsie.com>
Date:   Wed Oct 20 11:09:46 2010 +0100

    Raise the default of StateChangedTimeoutPriority from 5 seconds to 30 seconds. Fixes rh#641691

Comment 11 Jon Masters 2010-10-20 23:58:11 UTC
Fair enough. Let's see how that works out.

Comment 12 Fedora Update System 2010-11-01 19:59:09 UTC
PackageKit-0.6.10-2.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/PackageKit-0.6.10-2.fc14

Comment 13 Fedora Update System 2010-11-02 22:16:50 UTC
PackageKit-0.6.10-2.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update PackageKit'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/PackageKit-0.6.10-2.fc14

Comment 14 Dan Mashal 2012-04-15 20:14:11 UTC
This no longer occurs in Fedora 14. Closing.


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