http://bugzilla.opensuse.org/show_bug.cgi?id=899755 Bjørn Lie changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |zaitor@opensuse.org -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899755 Dominique Leuenberger changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |855993 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899755 Michael Andres changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |IN_PROGRESS -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899755 http://bugzilla.opensuse.org/show_bug.cgi?id=899755#c4 Michael Andres changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dimstar@opensuse.org Flags| |needinfo?(dimstar@opensuse. | |org) --- Comment #4 from Michael Andres --- @Dominique: I found some time to enhance libzypps global lock. A new libzypp-16.0.2 is currently available here: obs://build.opensuse.org/zypp:Head obs://build.suse.de/Devel:zypp:SLE12SP2 Zypp no longer holds an internal reference to the lock file. So as soon as PK drops it's last pointer to the ZYpp object, the lock file will vanish without need to shutdown PK. ZYpp::Ptr zypp = ZYppFactory::instance().getZYpp(); // ZYpp object + lock ZYpp::Ptr zypp2 = ZYppFactory::instance().getZYpp(); // 2nd ref to ZYpp zypp = nullptr; zypp2 = nullptr; // drops the lock zypp = ZYppFactory::instance().getZYpp(); // acquires the lock With this, it's basically possible to let PK live longer than 15 seconds. Note that the ZYpp object itself is currently not destroyed. If you reacquire the lock, the returned ZYPP object will be in the state as you left it. The IMO next step is to test and enhance PK with libzypp-16.0.2. If PK lifetime is prolonged, then it will be possible the system content got modified by zypper while PK was sleeping. So you probably need to take care repos and target are refreshed and reloaded in case they have changed. Otherwise PK will operate on outdated data. If this works, I'll need to enhance zypper, to suggest waiting until PK has dropped it's lock rather than killing PK. Thet we can think about prolonging the lifetime. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899755 http://bugzilla.opensuse.org/show_bug.cgi?id=899755#c16 --- Comment #16 from Michael Andres --- According to comment#1 PK is currently configured to terminate after 15 seconds idleness. Reason for this was, that the PK-backend was not able to drop the libzypp-lock while it's idle. This way a running PK prevented zypper/yast from running, even if PK was idle. This has been fixed with libzypp-16.1.1, PK is now able to drop and re-acquire the libzypp-lock. It may however be the system has been modified while PK was idle. So after re-acquiring the libzypp-lock PK-backend must sync it's data with the systems current state, but this does not always work (see comment#6). In comment#7 I sketched a demo which - in a loop - acquires the libzypp-lock and syncs it's data. This is basically what the PK-backend needs to do, if you want to stop terminating after 15 seconds. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899755 http://bugzilla.opensuse.org/show_bug.cgi?id=899755#c21 Dominique Leuenberger changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(dimstar@opensuse. | |org) | --- Comment #21 from Dominique Leuenberger --- (In reply to Jonathan Kang from comment #20)

Any comment on the patch attached in previous comment?

I did not spot anything in particular wrong... the best way to test this on your machine is to switch to PackageKit-branding-upstream (there the lifetime is not configured to 15s, but infinite). While using zypper and pkcon / gpk-update-viewer / gnome-software interchangably, the information provided has to stay consistent - and as long as none of the tasks is actually doing anything at the moment, must not block the others -- You are receiving this mail because: You are on the CC list for the bug.