SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. Use a KDE session with Plasma 2. Shutdown or restart the system (with or without logging out) 3. OBSERVED RESULT Delay with spinner for around 60-90 seconds before system begins reboot sequence EXPECTED RESULT Very brief delay of at most than 5-10 seconds before rebooting. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.25.3 KDE Frameworks Version: 5.96.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION This is KDE under X11. I don't currently use Wayland. This issue has been going on for several months now, including with previous versions of Plasma and KF5. It appears to be caused by plasma-kded.service, as seen in this snippet from the journal ('journalctl -b -1 -r'): ... Jul 14 13:40:21 Bree systemd[1368]: Stopped target basic.target - Basic System. Jul 14 13:40:21 Bree systemd[1368]: plasma-kded.service: Consumed 1.874s CPU time. Jul 14 13:40:21 Bree systemd[1368]: Stopped plasma-kded.service - KDE Daemon. Jul 14 13:40:21 Bree systemd[1368]: plasma-kded.service: Failed with result 'timeout'. Jul 14 13:40:21 Bree systemd[1368]: plasma-kded.service: Main process exited, code=killed, status=9/KILL Jul 14 13:40:21 Bree systemd[1368]: plasma-kded.service: Killing process 2029 (ProfilesWatcher) with signal SIGKILL. Jul 14 13:40:21 Bree systemd[1368]: plasma-kded.service: Killing process 1956 (kded5) with signal SIGKILL. Jul 14 13:40:21 Bree systemd[1368]: plasma-kded.service: State 'stop-sigterm' timed out. Killing. <-----------------------**** Jul 14 13:38:52 Bree systemd[1]: Unmounted run-user-0.mount - /run/user/0. ...
Further information: 1) I tried logging out and manually killing the kded5 process from another console (using -9 as it ignored the standard kill). I then rebooted and saw no delay. 2) New session: logged out and killed kded5 as before, then tried logging in again. The login screen (SDDM) hung until I manually killed the kded5 process from another console (I didn't wait for it to time out), at which point the SDDM login continued. 3) Clearly the kded5 process should die when I log out. I have "KillUserProcesses=yes" in /etc/systemd/logind.conf, so why isn't this happening automatically? Is kded5 not a user process?
Following discussion on the Fedora Users list, I implemented a workaround which solves the immediate problem. See: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/thread/4UY53SXJSQTGA264SQ4B5V22WYUQQEWG/ This works, but it would be much better to know exactly why kded is hanging. Specifically, what is it waiting for? This is difficult to discover as there isn't enough logging detail in the journal. All I can tell is that it's ignoring SIGTERM for some reason, presumably because one or more of its built-in daemons is still active.
(In reply to Patrick O'Callaghan from comment #2) > Following discussion on the Fedora Users list, I implemented a workaround > which solves the immediate problem. See: > > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/ > thread/4UY53SXJSQTGA264SQ4B5V22WYUQQEWG/ > > This works, but it would be much better to know exactly why kded is hanging. > Specifically, what is it waiting for? This is difficult to discover as there > isn't enough logging detail in the journal. All I can tell is that it's > ignoring SIGTERM for some reason, presumably because one or more of its > built-in daemons is still active. This solution has simply stopped working. The default timeout is indeed set as described: $ systemctl show --property=DefaultTimeoutStopUSec DefaultTimeoutStopUSec=5s (note the strange and undocumented "USec" rather than "Sec", which you have to use to get the value despite "Sec" being used in setting the property) This did work for a time, but now makes no difference. I've changed nothing apart from system updates. I once again have to manually kill the offending process (kded) to avoid a 90-second delay on shutdown/reboot/re-login.
Created attachment 151347 [details] attachment-17138-0.html Finally realised (after discussion on the Fedora Users list) that this should be set under "user" rather than "system", for example: $ cat /etc/systemd/user.conf.d/99-stop-fast.conf [Manager] DefaultTimeoutStopSec=5s On Mon, 15 Aug 2022 at 12:20, Patrick O'Callaghan <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=456713 > > --- Comment #3 from Patrick O'Callaghan <pocallaghan@gmail.com> --- > (In reply to Patrick O'Callaghan from comment #2) > > Following discussion on the Fedora Users list, I implemented a workaround > > which solves the immediate problem. See: > > > > > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/ > > thread/4UY53SXJSQTGA264SQ4B5V22WYUQQEWG/ > > > > This works, but it would be much better to know exactly why kded is > hanging. > > Specifically, what is it waiting for? This is difficult to discover as > there > > isn't enough logging detail in the journal. All I can tell is that it's > > ignoring SIGTERM for some reason, presumably because one or more of its > > built-in daemons is still active. > > This solution has simply stopped working. The default timeout is indeed > set as > described: > > $ systemctl show --property=DefaultTimeoutStopUSec > DefaultTimeoutStopUSec=5s > > (note the strange and undocumented "USec" rather than "Sec", which you > have to > use to get the value despite "Sec" being used in setting the property) > > This did work for a time, but now makes no difference. I've changed nothing > apart from system updates. > > I once again have to manually kill the offending process (kded) to avoid a > 90-second delay on shutdown/reboot/re-login. > > -- > You are receiving this mail because: > You reported the bug.
*** Bug 456611 has been marked as a duplicate of this bug. ***