[Bug 1202796] New: Zypper can't stop PackageKit
https://bugzilla.suse.com/show_bug.cgi?id=1202796 Bug ID: 1202796 Summary: Zypper can't stop PackageKit Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: 64bit OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: libzypp Assignee: zypp-maintainers@suse.de Reporter: 95kreaninw95@gmail.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202796 Archer Allstars <95kreaninw95@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |95kreaninw95@gmail.com -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202796 https://bugzilla.suse.com/show_bug.cgi?id=1202796#c1 Michael Andres <ma@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(95kreaninw95@gmai | |l.com) --- Comment #1 from Michael Andres <ma@suse.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202796 https://bugzilla.suse.com/show_bug.cgi?id=1202796#c2 --- Comment #2 from Archer Allstars <95kreaninw95@gmail.com> --- Created attachment 861141 --> https://bugzilla.suse.com/attachment.cgi?id=861141&action=edit My zypper.log as per requested -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202796 https://bugzilla.suse.com/show_bug.cgi?id=1202796#c3 --- Comment #3 from Archer Allstars <95kreaninw95@gmail.com> --- Created attachment 861142 --> https://bugzilla.suse.com/attachment.cgi?id=861142&action=edit My pk_backend_zypp as per requested -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202796 https://bugzilla.suse.com/show_bug.cgi?id=1202796#c4 --- Comment #4 from Archer Allstars <95kreaninw95@gmail.com> --- @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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202796 https://bugzilla.suse.com/show_bug.cgi?id=1202796#c5 --- Comment #5 from Archer Allstars <95kreaninw95@gmail.com> --- Created attachment 861143 --> https://bugzilla.suse.com/attachment.cgi?id=861143&action=edit Zypper agrument with PackageKit in action The only way to stop PackageKit successfully is to fire: sudo systemctl stop packagekit. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202796 https://bugzilla.suse.com/show_bug.cgi?id=1202796#c6 Michael Andres <ma@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(95kreaninw95@gmai | |l.com) | --- Comment #6 from Michael Andres <ma@suse.com> --- (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... -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202796 https://bugzilla.suse.com/show_bug.cgi?id=1202796#c7 Michael Andres <ma@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |songchuan.kang@suse.com Flags| |needinfo?(songchuan.kang@su | |se.com) --- Comment #7 from Michael Andres <ma@suse.com> --- @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? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202796 https://bugzilla.suse.com/show_bug.cgi?id=1202796#c8 Jonathan Kang <songchuan.kang@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(songchuan.kang@su | |se.com) | --- Comment #8 from Jonathan Kang <songchuan.kang@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202796 https://bugzilla.suse.com/show_bug.cgi?id=1202796#c9 Michael Andres <ma@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo? --- Comment #9 from Michael Andres <ma@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202796 https://bugzilla.suse.com/show_bug.cgi?id=1202796#c10 --- Comment #10 from Jonathan Kang <songchuan.kang@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202796 Dead Mozay <dead_mozay@opensuse.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dead_mozay@opensuse.org -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202796 Milachew <milachew@mail.lv> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |milachew@mail.lv -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202796 Tomasz Osak <tomasz.osak.80@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tomasz.osak.80@gmail.com -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@suse.com