Created attachment 1740776 [details] screenshot of ESC console during reboot hang Description of problem: A stop job is running for User Manager for UID 1000 (1min 37s /2 min) Version-Release number of selected component (if applicable): systemd-247.2-1.fc34.x86_64 dbus-broker-24-1.fc34.x86_64 How reproducible: Always Steps to Reproduce: 1. Default clean install (to qemu-kvm, uefi) Fedora-Workstation-Live-x86_64-Rawhide-20201215.n.0.iso and reboot. Run initial setup. Reboot. 2. Multiple login to GNOME and reboot. Actual results: Each reboot takes 2 minutes waiting on: A stop job is running for User Manager for UID 1000 (1min 37s /2 min) Expected results: Reboot should happen faster. Additional info: linux ($root)/vmlinuz-5.10.0-98.fc33.x86_64 root=UUID=a80e06b2-0bda-4b9f-a36c-\ 5012f11a5605 ro rootflags=subvol=root mitigations=off systemd.log_level=debug \ systemd.log_target=console console=ttyS0,38400 console=tty1 This looks suspicious that it had to resort to -9 to kill these off: Child 1370 ((sd-pam)) died (code=killed, status=9/KILL) user-1000.slice: Child 1370 belongs to user-1000.slice. Child 3241 (dbus-broker-lau) died (code=killed, status=9/KILL)
Created attachment 1740777 [details] systemd debug directed to console
Created attachment 1740778 [details] systemctl list-jobs 1 captured from early debug shell on tty9 screenshot 1 of 2
Created attachment 1740779 [details] systemctl list-jobs 2 captured from early debug shell on tty9 screenshot 2 of 2, some overlap with 1
This doesn't happen when doing pk offline update. Unsurprising, no user session. But it is not a per se problem with systemd, but something holding things up in the user environment.
Ugh, I suppose we did not yet update gnome-session, so that is expected. i.e. https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/55
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.
Proposed as a Freeze Exception for 34-beta by Fedora user chrismurphy using the blocker tracking app because: I'm unable to find a criterion that applies, but it's a bad user experience so we should discuss a freeze exception if a fix doesn't land before then. (I'm still experiencing it with gnome-session-3.38.0-3.fc34.x86_64 and systemd-247.3-3.fc34.x86_64.)
(In reply to Benjamin Berg from comment #5) > Ugh, I suppose we did not yet update gnome-session, so that is expected. > > i.e. https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/55 Hi Benjamin, looks like there is still no gnome-session 40.beta release...?
Discussed during the 2021-02-22 blocker review meeting: [0] The decision to classify this bug as an "AcceptedFreezeException (Beta)" was made as this affects live images, and is rather annoying. [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2021-02-22/f34-blocker-review.2021-02-22-17.07.txt
Yeah, seems like nobody felt responsible to pushed out an upstream gnome-session 40.beta release. I just uploaded a 40.beta release which should fix this issue (possibly apart from one race that is likely rare).
FEDORA-2021-19cbc87c03 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-19cbc87c03
FEDORA-2021-19cbc87c03 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-19cbc87c03` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-19cbc87c03 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-19cbc87c03 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
*** Bug 1904445 has been marked as a duplicate of this bug. ***