|
Bugzilla – Full Text Bug Listing |
| Summary: | packagekitd locks the packaging system when pk-update-icon is running | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.0 | Reporter: | JP Rosevear <jpr> |
| Component: | GNOME | Assignee: | Scott Reeves <sreeves> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Critical | ||
| Priority: | P5 - None | CC: | captain.magnus, ma |
| Version: | Alpha 3 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | packagekit_devel, gnome-showstopper | ||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
JP Rosevear
2008-03-26 16:47:41 UTC
The default shutdown timeout of packagekitd is 300s and during timeframe libzypp is locked. You can change this value in /etc/PackageKit.conf See documentation: ShutdownTimeout This is the time that the daemon waits when idle before shutting down. A smaller number will result in slower response times when running many transactions in a small amount of time. A longer timeout will lock the underlying packaging backend for longer, although the daemon will start and stop less often. Please check if libzypp stays locked after this timeframe. No it doesn't, killing packagekit solves the issue. But only pk-update-icon is running and that only checks for updates at most hourly, so does zypp need to lock when its doing nothing? Or could pk-update-icon explicitly shutdown packagekitd after running a check (if no other transactions are queued). This affects the livecd as well when trying to install :-( My two main worries about decreasing the timeout were 1. Exceeding the timeout value in a subpart of a transaction when the backend is not emitting signals. For example if simply downloading file 3 of 20 took longer than timeout the backend would emit no signals and would we lose state or suffer performance hits. This is not an issue as the transaction list is still > 0 so the timeout is not started until that list is cleared. 2. The interactive apps performance. For example pull up gpk-application, select a package, click the depends tab, wait > timeout, click the files tab. We will timeout and the engine will exit but it starts up in about 1 second (on my box) so it's not bad. Moving the timeout down to 15 seconds. *** Bug 386663 has been marked as a duplicate of this bug. *** I just tried pre-beta3 and this is not a problem anymore. Closing as fixed. Really closing as fixed this time. |