Bug 456713 - plasma-kded.service hangs for around a minute or more on system shutdown
Summary: plasma-kded.service hangs for around a minute or more on system shutdown
Status: REPORTED
Alias: None
Product: frameworks-kded
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.96.0
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
: 456611 (view as bug list)
Depends on:
Blocks:
 
Reported: 2022-07-14 12:57 UTC by Patrick O'Callaghan
Modified: 2023-02-19 05:26 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
attachment-17138-0.html (5.70 KB, text/html)
2022-08-15 21:34 UTC, Patrick O'Callaghan
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick O'Callaghan 2022-07-14 12:57:13 UTC
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.
...
Comment 1 Patrick O'Callaghan 2022-07-16 10:55:13 UTC
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?
Comment 2 Patrick O'Callaghan 2022-07-18 10:51:08 UTC
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.
Comment 3 Patrick O'Callaghan 2022-08-15 11:20:55 UTC
(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.
Comment 4 Patrick O'Callaghan 2022-08-15 21:34:22 UTC
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.
Comment 5 postix 2022-11-04 16:41:26 UTC
*** Bug 456611 has been marked as a duplicate of this bug. ***