| Summary: | plasma-kded.service hangs for around a minute or more on system shutdown | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kded | Reporter: | Patrick O'Callaghan <pocallaghan> |
| Component: | general | Assignee: | David Faure <faure> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | cdennett, kdelibs-bugs, lst_manage, postix, rm, thenerdiestguy |
| Priority: | NOR | ||
| Version: | 5.96.0 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=445449 | ||
| Latest Commit: | Version Fixed In: | ||
| Attachments: | attachment-17138-0.html | ||
|
Description
Patrick O'Callaghan
2022-07-14 12:57: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? 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. *** |