Description of problem: On some reboots, PackageKit Daemon is holding up the shutdown. Looks like Gnome Software needs to be run, maybe even add or remove a package (not sure of the pattern, but merely logging in and rebooting doesn't appear to reproduce the problem). Version-Release number of selected component (if applicable): How reproducible: Always, as described Steps to Reproduce: 1. Login, launch gnome-software, add or remove something 2. Reboot 3. Actual results: Hang, systemd reports a stop job is running for PackageKitDaemon, times out after 1m30s. Expected results: PK should not hold up boot. Additional info:
Created attachment 1577276 [details] shutdown log https://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1 followed the Shutdown Completes Eventually section to capture this; all I can see it shows is a 90s delay from the time systemd asks it to shutdown to the time it's forced to shutdown
PackageKit-1.1.12-5.fc30.x86_64 python3-hawkey-0.31.0-3.fc31.x86_64 Those are the same versions Fedora 30 has (other than both are fc30), I don't have this problem there.
Hey, I got the exact same problem. Problem is, I didn't really open gnome software or indeed anything. I just log in, shutdown, and there it stucks every time. Don't really know what kind of information you'd need.
This happens to me with Fedora KDE spin. I update software from the plasma "Software Updates" notification, which kicks off packagekitd, and I often update just before I close my laptop, shutting it down instead if the kernel has updated. "PackageKit itself is a system activated daemon called packagekitd. Being system activated means that it's only being run when the user is using a text mode or graphical tool, and quits when it's no longer being used. This means we don't delay the boot sequence or session startup and don't consume memory when not being used." So it seems packagekitd should ordinarily not be running at system shutdown. FWIW, I just got a notification about a few new packages and performed a "Software Updates", and a few minutes later packagekitd is still running. strace shows it's polling fd 4, 5,and 10. About 5 minutes later packagekitd process exited. So maybe packagekitd just takes several minutes to exit on its after you've installed software, and systemd shutdown can't hurry it up. From the shutdown log attachment it seems systemd sends packagekitd stop-sigterm (not sure whether a DBus message or signal), the packagekit DBus interface continues to get or send additional PropertyChanged messages, then much later system shutdown gives up and "Killing process 1369 (packagekitd) with signal SIGKILL." There's an EOL'd Bug 1190915 "packagekitd does not respond to systemctl stop" that might be relevant but is short on details.
Shutdown and `systemctl stop packagekit` send SIGTERM to the process, then by default wait 90 seconds before sending SIGKILL. It doesn't look like PackageKit's pk-main.c responds to SIGTERM, but it does respond to Ctrl-C (SIGINT). However, the last time System Updates ran I tried sending SIGTERM and SIGINT to packagekitd after installation had apparently finished and neither seemed to make the process exit. If I manually start packagekit with `systemctl start packagekit` and send the packagekitd process SIGTERM it exits immediately, so maybe packagekitd is stuck in some state waiting for its DNF backend. It seemed that the command-line utility `pkcon quit` immediately terminates the packagekitd process, so a possible fix/workaround is the packagekit.service could define "ExecStop=/usr/bin/pkcon quit" though that would add a dependency on pkcon. I'm very much guessing, hope this helps.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
Is there any progress on this item, it is seriously irritating to have to wait for 90 seconds to shut down the workstation.
A local workaround is to severely reduce the shutdown time for packagekit.service. I do that for cockpit now (https://github.com/cockpit-project/bots/pull/495/files), as this annoying to waste 1.5 minutes on each reboot.
On reboot/shutdown should SIGTERM be issued to PackageKit? Is that happening or is it being ignored?
@Chris: it is sent but ignored. Crude reproducer: # pkcon get-updates & # systemctl stop packagekit # hangs # systemctl status packagekit ● packagekit.service - PackageKit Daemon Loaded: loaded (/usr/lib/systemd/system/packagekit.service; static; vendo> Active: deactivating (stop-sigterm) since Tue 2020-02-04 11:03:42 EST; 21> Main PID: 1020 (packagekitd) Tasks: 6 (limit: 1137) Memory: 68.5M CPU: 1.680s CGroup: /system.slice/packagekit.service ├─1020 /usr/libexec/packagekitd └─3512 gpg-agent --homedir /var/cache/PackageKit/31/metadata/upda> Feb 04 11:03:38 m1.cockpit.lan systemd[1]: Starting PackageKit Daemon... Feb 04 11:03:38 m1.cockpit.lan PackageKit[1020]: daemon start Feb 04 11:03:38 m1.cockpit.lan systemd[1]: Started PackageKit Daemon. Feb 04 11:03:42 m1.cockpit.lan systemd[1]: Stopping PackageKit Daemon...
Still not fixed in Fedora 33.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
(In reply to Sébastien Wilmet from comment #11) > Still not fixed in Fedora 33. Interesting. I hadn't experienced this problem with shutdown for months, my shutdowns with Fedora 32 were so fast that I barely see the console output after KDE exits, so I assumed something in Fedora 32 made it better in my case. (I did switch to command-line `sudo dnf --setopt=install_weak_deps=False update` to avoid PackageKit installing more packages than I want, but I'm pretty sure this was after I stopped having delayed shutdowns.) Martin Pitt's steps to reproduce in comment #10 don't reproduce for me on Fedora 33, I get: ● packagekit.service - PackageKit Daemon Loaded: loaded (/usr/lib/systemd/system/packagekit.service; static) Active: inactive (dead) ... Nov 03 14:47:09 fedlaptop PackageKit[64358]: get-updates transaction /6379_edbdcaaa from uid 1000 finished with suc> Nov 03 14:47:22 fedlaptop systemd[1]: Stopping PackageKit Daemon... Nov 03 14:47:22 fedlaptop systemd[1]: packagekit.service: Succeeded. Nov 03 14:47:22 fedlaptop systemd[1]: Stopped PackageKit Daemon. Nov 03 14:47:22 fedlaptop systemd[1]: packagekit.service: Consumed 3min 38.010s CPU time.
(In reply to Sébastien Wilmet from comment #11) > Still not fixed in Fedora 33. can confirm the bug appears in fedora 33.
Still not fixed on Fedora 34.
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I still see it on F34 and F35.
I have encountered this issue multiple time over the last few Fedora releases, most recently with Fedora Workstation 36 on a Lenovo T440p laptop. I was able to avoid the problem in my case by disabling automatic updates and update notifications in the control panel. I suspect these background updating activities were the reason why the PackageKit service was being started, as I had not run the gnome-software application.
This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Confirmed on F36 in comment #20
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '36'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.