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.

Reply via email to