Bugzilla – Bug 1202796
Zypper can't stop PackageKit
Last modified: 2023-10-05 13:54:11 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? :)