Bug 641691

(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.

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.

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...

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.

Re-opening for comment on the waiting idea.

(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.

(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.

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.

PackageKit could even just display a different icon or stop displaying notifications until it has had chance to re-check with yum.

(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>
Date:   Wed Oct 20 11:09:46 2010 +0100

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

Fair enough. Let's see how that works out.

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

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

This no longer occurs in Fedora 14. Closing.