Created attachment 1151506 [details] KDE: screenshot of a stuck shutdown process Description of problem: The shutdown process on KDE takes ~2/3 minutes longer than usual, provided that at least two user accounts logged in before the shutdown. Version-Release number of selected component (if applicable): plasma-desktop-5.6.2-2.fc24.x86_64 plasma-workspace-5.6.2-1.fc24.x86_64 sddm-0.13.0-7.fc24.x86_64 How reproducible: Always Steps to Reproduce: 1.Boot a KDE system which has got two user accounts. 2.Log in with the first user account. 3.Log out. 4.Log in with the second user account. 5.Perform a shutdown or a reboot. Actual results: The shutdown process takes longer than usual. Expected results: Ideally, shutdown should proceed normally. Additional info: 1) I'm attaching a screenshoot which shows the exact moment where the shutdown process gets stuck. I'll attach a journal as soon as possible. 2) I'm testing with qemu-kvm 3) If only one session is started and never closed, the shutdown process doesn't take longer than usual.
Created attachment 1151509 [details] Output of 'journalctl -b -1 | tail -n 500'
Proposed as a Freeze Exception for 24-beta by Fedora user juliuxpigface using the blocker tracking app because: This might be a partial violation of the "2.6.6 Shutdown, reboot, logout" F24 Beta Criterion. However, the shutdown process works: it just takes longer on some cases. That's why I'm proposing this as FE and not as Blocker. "Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops." References: https://fedoraproject.org/wiki/Fedora_24_Beta_Release_Criteria#Shutdown.2C_reboot.2C_logout
Proposed as a Blocker for 24-final by Fedora user juliuxpigface using the blocker tracking app because: One of KDE's graphical tools, the one which should be responsible for setting and storing the screen's resolution, doesn't always work as expected. This might be a conditional violation of the "2.4.6 Default application functionality" F24 Final Criterion. "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test. " References: https://fedoraproject.org/wiki/Fedora_24_Final_Release_Criteria#Default_application_functionality
I hit the same / similar problem with F24 KDE x86_64 in VM (F23). The F24 is up to date. I can reproduce it even with just one login session: 1.Boot KDE. 2.Log in with the user account. 3.Shutdown or a reboot. 4.Wait for: A stop job is running for session 1 user <me> (1:30min) 5.Then the system shuts down correctly. Could you please recommend how to find the cause or how to create more meaningful log?
note we already have an enormous rambling bug for 'a stop job is running' cases: https://bugzilla.redhat.com/show_bug.cgi?id=1088619 however that's basically a lost cause at this point, so if this is a clear specific case reproducer, we definitely shouldn't dupe it. We could certainly use systemd debugging info: https://freedesktop.org/wiki/Software/systemd/Debugging/ I think I don't wanna vote on this till we have a bit more info and some idea of what the fix might be.
Been tracking similar symptoms upstream @ https://bugs.kde.org/show_bug.cgi?id=348123 for a couple of releases. (there's a bug downstream tracking it too, I'll dig more later). That said, this in no way violates the criteria as mentioned in my humble opinion, -1 blocker
Created attachment 1152056 [details] shutdown-log.txt #1 shutdown-log.txt created per https://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1 The waiting seems to happen at: [ 404.210518] systemd-journald[661]: Successfully sent stream file descriptor to service manager. [ 425.451686] systemd[1]: systemd-logind.service: Got notification message from PID 880 (WATCHDOG=1) [ 483.448927] systemd-journald[661]: Sent WATCHDOG=1 notification. [ 483.449093] systemd[1]: systemd-journald.service: Got notification message from PID 661 (WATCHDOG=1) [ 485.448721] systemd[1]: session-1.scope: Stopping timed out. Killing. [ 485.449108] systemd[1]: session-1.scope changed stop-sigterm -> stop-sigkill
Created attachment 1152058 [details] shutdown-log.txt #2 The waiting seems to happen at: [ 298.315497] systemd[1]: Got message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1/agent interface=org.freedesktop.systemd1.Agent member=Released cookie=1 reply_cookie=0 error=n/a [ 298.315663] systemd[1]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1/agent interface=org.freedesktop.systemd1.Agent member=Released cookie=1 reply_cookie=0 error=n/a [ 298.315746] systemd[1]: Got disconnect on private connection. [ 379.208048] systemd-journald[660]: Sent WATCHDOG=1 notification. [ 379.208391] systemd[1]: systemd-journald.service: Got notification message from PID 660 (WATCHDOG=1) [ 383.958182] systemd[1]: session-1.scope: Stopping timed out. Killing. [ 383.958543] systemd[1]: session-1.scope changed stop-sigterm -> stop-sigkill
Created attachment 1152061 [details] shutdown-log.txt #3 The waiting seems to happen at: [ 395.422470] systemd-journald[659]: Successfully sent stream file descriptor to service manager. [ 395.423118] systemd[1]: systemd-journald.service: Got notification message from PID 659 (FDSTORE=1) [ 395.423145] systemd[1]: systemd-journald.service: Added fd to fd store. [ 418.397805] systemd[1]: systemd-logind.service: Got notification message from PID 882 (WATCHDOG=1) [ 478.396682] systemd[1]: session-1.scope: Stopping timed out. Killing. [ 478.398718] systemd-journald[659]: Sent WATCHDOG=1 notification. [ 478.398906] systemd[1]: session-1.scope changed stop-sigterm -> stop-sigkill
Discussed at the 2016-05-02 blocker review meeting: Rejected as a beta blocker as this could involve many core components and it seems the real cause is yet unknown and no-one has any idea what the fix will look like, we cannot approve a freeze exception at this time. It can be re-proposed with more info on the cause and/or a fix.
Discussed again at the 2016-05-02 blocker review meeting: This is definitely an annoyance but a delay in sh7utdown isn't severe enough to violate the release criteria, especially as it can be fixed with an update for installed systems.
I'm pretty sure the cause is some processes not ending (on their own) at the end of the session, and logind timeout waiting for them is hit. One workaround is to enable KillUserProcesses=yes in /etc/systemd/logind.conf (which has side effects, of course, in case you ever *want* processes to persist after session end, you need to do more work).
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 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 '24'. 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 24 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.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.