Bugzilla – Bug 1202796
Zypper can't stop PackageKit
Last modified: 2025-09-11 07:47:03 UTC
On openSUSE Tumbleweed, If I run "sudo zypper dub" while PackageKit is still running, Zypper will ask me that whether I want PackageKit to stop. Unfortunately, even if I say yes, Zypper can't stop it no matter how many times I say yes. I have to stop PackageKit manually by: sudo systemctl stop packagekit Only then, I can use Zypper. This issue on openSUSE is very severe, since Zypper doesn't work in harmony with PackageKit, unlike DNF and APT from my experiences with Fedora and Ubuntu. On those distros, DNF or APT can run along PackageKit, no need to stop PackageKit before DNF or APT operation. And to make matter worse, PackageKit (GNOME Software) uses a huge amount of time to start and finish its operation after the system boot. To summarize this issue, Zypper should be able to stop PackageKit when the user tells it to stop PackageKit. I don't know the code behind Zypper, but Zypper should fire "sudo systemctl stop packagekit" when the user tells it to do so.
Could you please attach the /var/log/zypper.log after such a failed attempt. If available also the /var/log/pk_backend_zypp. zypper sends a dbus request asking PackageKit to quit and release the lock ASAP. OTOH should PK hold the lock only while performing some action. If you are constantly blocked by PK, then something broke. The logs should reveal it.
Created attachment 861141 [details] My zypper.log as per requested
Created attachment 861142 [details] My pk_backend_zypp as per requested
@Michael Andres Hi, thanks for your support. > zypper sends a dbus request asking PackageKit to quit and release the lock ASAP. Unfortunately. PackageKit won't listen to Zypper at all, no matter how many times I tell Zypper to stop it. The only way to stop PackageKit is to fire: sudo systemctl stop packagekit, as explained in the first post. > OTOH should PK hold the lock only while performing some action. If you are constantly blocked by PK, then something broke. The logs should reveal it. I don't think PackageKit is broken in my system. Because PackageKit doesn't block Zypper constantly, as it only hold the lock while performing its action (after logging in to my user ID). But the problem is, this process takes a very long time in some instances (sometimes, I experienced 10-30 mins). It might take this long on Fedora and Ubuntu also, but it's transparent to the user since DNF and APT work without having PackageKit to stop, or they are able to stop PackageKit successfully and also be able to restart PackageKit automatically after finished their operations. From my experiences with DNF and APT, never once they fail to perform their operation when I asked them to. Zypper on the other hand, has this issue.
Created attachment 861143 [details] Zypper agrument with PackageKit in action The only way to stop PackageKit successfully is to fire: sudo systemctl stop packagekit.
(In reply to Archer Allstars from comment #4) > action (after logging in to my user ID). But the problem is, this process > takes a very long time in some instances (sometimes, I experienced 10-30 > mins). According to the pk_backend_zypp log the individual actions do not take that long, but PK is permanently doing something. So it re-aquires the lock almost immediately after it released it. Maybe something using PK is running wild: > lock from 18:36:12 to 18:38:19 for 127 sec - lock free for 0 sec > lock from 18:38:19 to 18:38:20 for 1 sec - lock free for 0 sec > lock from 18:38:20 to 18:38:20 for 0 sec - lock free for 5 sec > lock from 18:38:25 to 18:38:37 for 12 sec - lock free for 0 sec > lock from 18:38:37 to 18:38:37 for 0 sec - lock free for 0 sec > lock from 18:38:37 to 18:38:51 for 14 sec - lock free for 0 sec > lock from 18:38:51 to 18:39:06 for 15 sec - lock free for 0 sec > lock from 18:39:06 to 18:39:24 for 18 sec - lock free for 0 sec > lock from 18:39:24 to 18:40:24 for 60 sec - lock free for 0 sec > lock from 18:40:24 to 18:40:37 for 13 sec - lock free for 0 sec > lock from 18:40:37 to 18:40:49 for 12 sec - lock free for 0 sec > lock from 18:40:49 to 18:41:02 for 13 sec - lock free for 0 sec > lock from 18:41:02 to 18:41:14 for 12 sec - lock free for 0 sec > lock from 18:41:14 to 18:41:26 for 12 sec - lock free for 0 sec > lock from 18:41:26 to 18:41:41 for 15 sec - lock free for 0 sec > lock from 18:41:41 to 18:41:53 for 12 sec - lock free for 0 sec > lock from 18:41:53 to 18:42:04 for 11 sec - lock free for 0 sec > lock from 18:42:04 to 18:42:18 for 14 sec - lock free for 0 sec > lock from 18:42:18 to 18:43:35 for 77 sec - lock free for 0 sec > lock from 18:43:35 to 18:44:10 for 35 sec - lock free for 0 sec > lock from 18:44:10 to 18:44:24 for 14 sec - lock free for 0 sec > lock from 18:44:24 to 18:44:37 for 13 sec - lock free for 0 sec > lock from 18:44:37 to 18:44:50 for 13 sec - lock free for 0 sec > lock from 18:44:50 to 18:45:06 for 16 sec - lock free for 0 sec > lock from 18:45:06 to 18:45:22 for 16 sec - lock free for 0 sec > lock from 18:45:22 to 18:45:39 for 17 sec - lock free for 0 sec > lock from 18:45:39 to 18:45:57 for 18 sec - lock free for 0 sec > lock from 18:45:57 to 18:46:12 for 15 sec - lock free for 0 sec > lock from 18:46:12 to 18:46:27 for 15 sec - lock free for 0 sec > lock from 18:46:27 to 18:46:42 for 15 sec - lock free for 0 sec > lock from 18:46:42 to 18:46:59 for 17 sec - lock free for 0 sec > lock from 18:46:59 to 18:47:14 for 15 sec - lock free for 0 sec > lock from 18:47:14 to 18:47:29 for 15 sec - lock free for 0 sec We can try to enable zypper to reserve the next free slot. Nevertheless the behavior is weird the the first glimpse and constantly eats up resources. I'll try to figure out mote...
@Jonathan, in the pk_backend_zypp log we see PK almost constantly running a sequence > [packagekit] ../backends/zypp/pk-backend-zypp.cpp(backend_find_packages_thread):3089 {T:140685635233344} > [packagekit] ../backends/zypp/pk-backend-zypp.cpp(ZyppJob):565 {T:140685635233344} locking zypp > [packagekit] ../backends/zypp/pk-backend-zypp.cpp(zypp_refresh_cache):1661 {T:140685635233344} 0 > [packagekit] ../backends/zypp/pk-backend-zypp.cpp(~ZyppJob):583 {T:140685635233344} unlocking zypp Is there a way to figure out what is causing those requests?
(In reply to Michael Andres from comment #7) > @Jonathan, > in the pk_backend_zypp log we see PK almost constantly running a sequence > > > [packagekit] ../backends/zypp/pk-backend-zypp.cpp(backend_find_packages_thread):3089 {T:140685635233344} > > [packagekit] ../backends/zypp/pk-backend-zypp.cpp(ZyppJob):565 {T:140685635233344} locking zypp > > [packagekit] ../backends/zypp/pk-backend-zypp.cpp(zypp_refresh_cache):1661 {T:140685635233344} 0 > > [packagekit] ../backends/zypp/pk-backend-zypp.cpp(~ZyppJob):583 {T:140685635233344} unlocking zypp > > Is there a way to figure out what is causing those requests? This is called by GNOME Software, which tries to search some application metadata files. Simply searching a file shouldn't take much time, but the current implementation of this in PK's zypp backend calls refresh-cache. So this might take some time to finish. I'll prepare a patch for this.
(In reply to Jonathan Kang from comment #8) (In reply to Jonathan Kang from comment #8) > This is called by GNOME Software, which tries to search some application > metadata files. Simply searching a file shouldn't take much time, but the > current implementation of this in PK's zypp backend calls refresh-cache. So > this might take some time to finish. AFAIK zypp calls the appdata plugin at the end of any refresh IFF new metadata were downloaded for a repo. So they trigger metadata refreshes every 20 sec. or so, just so check for new software? Sounds like a waste of resources to me.
(In reply to Michael Andres from comment #9) > just so check for new software? GNOME Software does this only on the first startup, and it's for showing detailed information for each application. There is nothing wrong with this. The issue is that the current implementation of search-file/package in PK's zypp backend refreshes all repos before searching, which is unnecessary(this should be done manually like calling "zypper ref"). Removing this should be able to significantly reduce PK's running time on system startup. Therefore, metadata refreshes are only triggered when really needed.
(In reply to Jonathan Kang from comment #8) > I'll prepare a patch for this. As I see, you already have prepared patch for Tumbleweed with marking this bug : https://build.opensuse.org/package/view_file/GNOME:Factory/PackageKit/PackageKit-zypp-dont-refresh-before-searching.patch?expand=1 Thanks! Does this mean that the problem should already be fixed or is the work still ongoing?
(In reply to Milachew from comment #11) > (In reply to Jonathan Kang from comment #8) > > I'll prepare a patch for this. > > As I see, you already have prepared patch for Tumbleweed with marking this > bug : > https://build.opensuse.org/package/view_file/GNOME:Factory/PackageKit/ > PackageKit-zypp-dont-refresh-before-searching.patch?expand=1 > > Thanks! > > Does this mean that the problem should already be fixed or is the work still > ongoing? What I did at PackageKit side only mitigates this issue. The bug was meant to let zypper stop PackageKit on user request. This is not fixed yet.
Will zypper ever improve on this side? :)
*** Bug 1224475 has been marked as a duplicate of this bug. ***
(In reply to Jonathan Kang from comment #12) > What I did at PackageKit side only mitigates this issue. The bug was meant > to let zypper stop PackageKit on user request. This is not fixed yet. Jonathan, how? Zypper sends > dbus-send --system --dest=org.freedesktop.PackageKit --type=method_call \ > /org/freedesktop/PackageKitorg.freedesktop.PackageKit.SuggestDaemonQuit But this neither stops PK faster nor does it prevent PK from being respawned. As Bug 1224475 reports it seems to be impossible to disable PK: > # systemctl stop packagekit > # systemctl disable packagekit > # systemctl status packagekit > ○ packagekit.service - PackageKit Daemon > Loaded: loaded (/usr/lib/systemd/system/packagekit.service; static) > Active: inactive (dead) > hobbes:~ (1)# pkcon search foobaa > Searching by details [=========================] > Starting [=========================] > Refreshing software list [=========================] > Querying [=========================] > Finished [=========================] > hobbes:~ (0)# systemctl status packagekit > ● packagekit.service - PackageKit Daemon > Loaded: loaded (/usr/lib/systemd/system/packagekit.service; static) > Active: active (running) since Tue 2024-05-21 17:51:27 CEST; 12s ago I almost think we can drop all this PK handling from zypper because it's useless. From the user's POV it does not matter whether zypper does not stop PK or PK does not respond or PK respawns so fast. We can try to offer a --[no]-wait-for-lock CLI option for zypper which mimics > ZYPP_LOCK_TIMEOUT=0 zypper .... (don't wait for the lock) or > ZYPP_LOCK_TIMEOUT=-1 zypper .... (wait forever) and use some default (maybe 'ZYPP_LOCK_TIMEOUT=60' sec). The environment variable is already handled by libzypp. We just need some visual feedback in zypper. Otherwise one may think it hangs.
(In reply to Michael Andres from comment #15) > (In reply to Jonathan Kang from comment #12) > > What I did at PackageKit side only mitigates this issue. The bug was meant > > to let zypper stop PackageKit on user request. This is not fixed yet. > > Jonathan, how? Zypper sends > > dbus-send --system --dest=org.freedesktop.PackageKit --type=method_call \ > > /org/freedesktop/PackageKitorg.freedesktop.PackageKit.SuggestDaemonQuit > > But this neither stops PK faster nor does it prevent PK from being > respawned. As Bug 1224475 reports it seems to be impossible to disable PK: > > # systemctl stop packagekit > > # systemctl disable packagekit > > # systemctl status packagekit > > ○ packagekit.service - PackageKit Daemon > > Loaded: loaded (/usr/lib/systemd/system/packagekit.service; static) > > Active: inactive (dead) > > hobbes:~ (1)# pkcon search foobaa > > Searching by details [=========================] > > Starting [=========================] > > Refreshing software list [=========================] > > Querying [=========================] > > Finished [=========================] > > hobbes:~ (0)# systemctl status packagekit > > ● packagekit.service - PackageKit Daemon > > Loaded: loaded (/usr/lib/systemd/system/packagekit.service; static) > > Active: active (running) since Tue 2024-05-21 17:51:27 CEST; 12s ago > > > I almost think we can drop all this PK handling from zypper because it's > useless. From the user's POV it does not matter whether zypper does not stop > PK or PK does not respond or PK respawns so fast. > > The current implementation of PackageKit's SuggestDaemonQuit isn't as quick as we expected. It simply waits for the last job to be finished and then quit. It doesn't ask jobs in queue to cancel so that it quit asap. So this is definitely a PackageKit issue.
> So this is definitely a PackageKit issue. I manage multiple Linux distros via Ansible: Debian, Fedora, Ubuntu & openSUSE Tumbleweed. The only distro which has a problem with PackageKit is TW. Ansible is unusable with it if I don't mask the service. The best thing one can do after installing TW is: sudo systemctl disable --now packagekitd sudo systemctl mask packagekitd It's the first thing in my Ansible: - name: Disable PackageKit systemd_service: name: packagekit enabled: false masked: yes state: stopped tags: ['zypper']
For what it's worth I have slow internet, and a repository refresh takes multiple minutes as a minimum. So if that for example isn't canceled, and packagekitd maybe even does that often (which in my opinion maybe it shouldn't but other comments suggested it currently does) that would explain why it never quits. However, KDE Discover also seems to aggressively restart packagekitd from how it looks like to me, that seems like part of the problem. My apologies if I observed any of these things incorrectly.
Jonathan, I'm passing it to you (c#16) although I don't think it's PK alone. Reports appear to be less meanwhile (from our POV). I don't know whether it's possible for PK to detect who's aggressively restarting PK or to block/delay application flooding PK with requests.