https://bugs.kde.org/show_bug.cgi?id=456713
--- Comment #4 from Patrick O'Callaghan <pocallag...@gmail.com> --- 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_nore...@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=456713 > > --- Comment #3 from Patrick O'Callaghan <pocallag...@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/us...@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. -- You are receiving this mail because: You are watching all bug changes.