I reported this on the Fedora KDE list a while back. Briefly, the kded daemon should die when the user session terminates, but actually waits around for up to 90 seconds before timing out. This blocks the system from shutting down, or from logging in the same user while the process is still running. This is happening despite KillUserProcesses being set to "yes" in /etc/systemd/logind.conf.
The KDE list thread: https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org/th...
My KDE BZ report: https://bugs.kde.org/show_bug.cgi?id=456713
However I have come across a report from years ago that tells of a similar problem with GDM: https://bugzilla.redhat.com/show_bug.cgi?id=1341837
So it doesn't appear to be specifically related to KDE, or even kded as such.
Is anyone else seeing this?
poc
On Sat, 16 Jul 2022 23:27:21 +0100 Patrick O'Callaghan wrote:
Is anyone else seeing this?
Possibly not precisely the same, but I found that systemd "user demons" were continuing to run forever even when the user logged out, and on shutdown it would wait a long time on them before being willing to shutdown or reboot.
Since I'm not running anything like a database server that needs to shut down cleanly, I just changed the systemd timeout from (I think) 90 seconds to 5 seconds.
On Sat, 2022-07-16 at 18:55 -0400, Tom Horsley wrote:
On Sat, 16 Jul 2022 23:27:21 +0100 Patrick O'Callaghan wrote:
Is anyone else seeing this?
Possibly not precisely the same, but I found that systemd "user demons" were continuing to run forever even when the user logged out, and on shutdown it would wait a long time on them before being willing to shutdown or reboot.
Since I'm not running anything like a database server that needs to shut down cleanly, I just changed the systemd timeout from (I think) 90 seconds to 5 seconds.
OK. Where is that configured (too lazy to look it up :-)?
poc
On Sun, 17 Jul 2022 10:27:52 -0400 Tom Horsley horsley1953@gmail.com wrote:
I made this chage: "DefaultTimeoutStopSec=5s" in both /etc/systemd/system.conf and /etc/systemd/user.conf
Thank you. I tried to make this change, but I must not have found the right variable or location because it didn't take. Long standing pebble in shoe for me, gone. Whew.
On Sun, 2022-07-17 at 10:27 -0400, Tom Horsley wrote:
On Sun, 17 Jul 2022 15:17:56 +0100 Patrick O'Callaghan wrote:
OK. Where is that configured (too lazy to look it up :-)?
I made this chage: "DefaultTimeoutStopSec=5s" in both /etc/systemd/system.conf and /etc/systemd/user.conf
Thanks, though one is obliged to wonder why this variable is set in two places.
poc
On Sun, 2022-07-17 at 17:03 +0100, Patrick O'Callaghan wrote:
On Sun, 2022-07-17 at 10:27 -0400, Tom Horsley wrote:
On Sun, 17 Jul 2022 15:17:56 +0100 Patrick O'Callaghan wrote:
OK. Where is that configured (too lazy to look it up :-)?
I made this chage: "DefaultTimeoutStopSec=5s" in both /etc/systemd/system.conf and /etc/systemd/user.conf
Thanks, though one is obliged to wonder why this variable is set in two places.
Actually, according to systemd-system.conf(5), it looks like the proper place to do this is with a file under /usr/lib/systemd/system.conf.d, similar to the old rc.d init files. Presumably that will avoid the setting being overwritten by a new install.
poc
On Sun, 2022-07-17 at 17:13 +0100, Patrick O'Callaghan wrote:
On Sun, 2022-07-17 at 17:03 +0100, Patrick O'Callaghan wrote:
On Sun, 2022-07-17 at 10:27 -0400, Tom Horsley wrote:
On Sun, 17 Jul 2022 15:17:56 +0100 Patrick O'Callaghan wrote:
OK. Where is that configured (too lazy to look it up :-)?
I made this chage: "DefaultTimeoutStopSec=5s" in both /etc/systemd/system.conf and /etc/systemd/user.conf
Thanks, though one is obliged to wonder why this variable is set in two places.
Actually, according to systemd-system.conf(5), it looks like the proper place to do this is with a file under /usr/lib/systemd/system.conf.d, similar to the old rc.d init files. Presumably that will avoid the setting being overwritten by a new install.
Well, that was a bust. Turns out that you do have to edit the standard file(s) to have any effect. Another example of the systemd docs being understandable only to a lawyer (or there's an actual bug).
Anyway, it appears to work now. Thanks again to Tom.
poc
On Sun, 17 Jul 2022 17:39:35 +0100 Patrick O'Callaghan wrote:
Turns out that you do have to edit the standard file(s) to have any effect.
That has been true for so many things, I don't even bother to try out the "correct" way any longer. I just use my big hammer to fix things after every dnf update:
Hi.
On Sun, 17 Jul 2022 17:39:35 +0100 Patrick O'Callaghan wrote:
Actually, according to systemd-system.conf(5), it looks like the proper place to do this is with a file under /usr/lib/systemd/system.conf.d, similar to the old rc.d init files. Presumably that will avoid the setting being overwritten by a new install.
Well, that was a bust. Turns out that you do have to edit the standard file(s) to have any effect.
It works for me.
Did you specified the [Manager] tag in the drop-in file ?
Example:
## Weird: systemd seems to uses internally a ...USec name for that systemctl show --property=DefaultTimeoutStopUSec DefaultTimeoutStopUSec=1min 30s
mkdir /usr/lib/systemd/system.conf.d echo -e '[Manager]\nDefaultTimeoutStopSec=5s' > /usr/lib/systemd/system.conf.d/99-stop-fast.conf
systemctl daemon-reload
systemctl show --property=DefaultTimeoutStopUSec DefaultTimeoutStopUSec=5s
On Sun, 2022-07-17 at 19:14 +0200, Francis.Montagnac@inria.fr wrote:
Hi.
On Sun, 17 Jul 2022 17:39:35 +0100 Patrick O'Callaghan wrote:
Actually, according to systemd-system.conf(5), it looks like the proper place to do this is with a file under /usr/lib/systemd/system.conf.d, similar to the old rc.d init files. Presumably that will avoid the setting being overwritten by a new install.
Well, that was a bust. Turns out that you do have to edit the standard file(s) to have any effect.
It works for me.
Did you specified the [Manager] tag in the drop-in file ?
Of course not. That would mean I had actually understood the manual.
Example:
## Weird: systemd seems to uses internally a ...USec name for that systemctl show --property=DefaultTimeoutStopUSec DefaultTimeoutStopUSec=1min 30s
mkdir /usr/lib/systemd/system.conf.d echo -e '[Manager]\nDefaultTimeoutStopSec=5s' > /usr/lib/systemd/system.conf.d/99-stop-fast.conf
systemctl daemon-reload
systemctl show --property=DefaultTimeoutStopUSec DefaultTimeoutStopUSec=5s
I'll try it that, thanks.
poc
On 18/7/22 04:41, Patrick O'Callaghan wrote:
On Sun, 2022-07-17 at 19:14 +0200, Francis.Montagnac@inria.fr wrote:
Hi.
On Sun, 17 Jul 2022 17:39:35 +0100 Patrick O'Callaghan wrote:
Actually, according to systemd-system.conf(5), it looks like the proper place to do this is with a file under /usr/lib/systemd/system.conf.d, similar to the old rc.d init files. Presumably that will avoid the setting being overwritten by a new install.
Well, that was a bust. Turns out that you do have to edit the standard file(s) to have any effect.
It works for me.
Did you specified the [Manager] tag in the drop-in file ?
Of course not. That would mean I had actually understood the manual.
Example:
## Weird: systemd seems to uses internally a ...USec name for that systemctl show --property=DefaultTimeoutStopUSec DefaultTimeoutStopUSec=1min 30s
mkdir /usr/lib/systemd/system.conf.d echo -e '[Manager]\nDefaultTimeoutStopSec=5s' > /usr/lib/systemd/system.conf.d/99-stop-fast.conf
systemctl daemon-reload
systemctl show --property=DefaultTimeoutStopUSec DefaultTimeoutStopUSec=5s
I'll try it that, thanks.
Just a silly question on this, what shows this issue? I'm running KDE and the config files in /etc listed in a prior thread have the same settings for the timeout as listed, albeit every setting in those files are prefixed with a "#", does this mean they are all commented out or is the "#" required syntax, but I am not seeing the issue, or at least not like it randomly used to be.
regards, Steve
poc _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 7/17/22 16:26, Stephen Morris wrote:
On 18/7/22 04:41, Patrick O'Callaghan wrote:
On Sun, 2022-07-17 at 19:14 +0200, Francis.Montagnac@inria.fr wrote:
Hi.
On Sun, 17 Jul 2022 17:39:35 +0100 Patrick O'Callaghan wrote:
Actually, according to systemd-system.conf(5), it looks like the proper place to do this is with a file under /usr/lib/systemd/system.conf.d, similar to the old rc.d init files. Presumably that will avoid the setting being overwritten by a new install.
Well, that was a bust. Turns out that you do have to edit the standard file(s) to have any effect.
It works for me.
Did you specified the [Manager] tag in the drop-in file ?
Of course not. That would mean I had actually understood the manual.
Example:
## Weird: systemd seems to uses internally a ...USec name for that systemctl show --property=DefaultTimeoutStopUSec DefaultTimeoutStopUSec=1min 30s
mkdir /usr/lib/systemd/system.conf.d echo -e '[Manager]\nDefaultTimeoutStopSec=5s' > /usr/lib/systemd/system.conf.d/99-stop-fast.conf
systemctl daemon-reload
systemctl show --property=DefaultTimeoutStopUSec DefaultTimeoutStopUSec=5s
I'll try it that, thanks.
Just a silly question on this, what shows this issue? I'm running KDE and the config files in /etc listed in a prior thread have the same settings for the timeout as listed, albeit every setting in those files are prefixed with a "#", does this mean they are all commented out or is the "#" required syntax, but I am not seeing the issue, or at least not like it randomly used to be.
Typically that means these are the default values. Uncomment and change the value to customize it.
On 18/7/22 10:18, Mike Wright wrote:
On 7/17/22 16:26, Stephen Morris wrote:
On 18/7/22 04:41, Patrick O'Callaghan wrote:
On Sun, 2022-07-17 at 19:14 +0200, Francis.Montagnac@inria.fr wrote:
Hi.
On Sun, 17 Jul 2022 17:39:35 +0100 Patrick O'Callaghan wrote:
Actually, according to systemd-system.conf(5), it looks like the proper place to do this is with a file under /usr/lib/systemd/system.conf.d, similar to the old rc.d init files. Presumably that will avoid the setting being overwritten by a new install.
Well, that was a bust. Turns out that you do have to edit the standard file(s) to have any effect.
It works for me.
Did you specified the [Manager] tag in the drop-in file ?
Of course not. That would mean I had actually understood the manual.
Example:
## Weird: systemd seems to uses internally a ...USec name for that systemctl show --property=DefaultTimeoutStopUSec DefaultTimeoutStopUSec=1min 30s
mkdir /usr/lib/systemd/system.conf.d echo -e '[Manager]\nDefaultTimeoutStopSec=5s' > /usr/lib/systemd/system.conf.d/99-stop-fast.conf
systemctl daemon-reload
systemctl show --property=DefaultTimeoutStopUSec DefaultTimeoutStopUSec=5s
I'll try it that, thanks.
Just a silly question on this, what shows this issue? I'm running KDE and the config files in /etc listed in a prior thread have the same settings for the timeout as listed, albeit every setting in those files are prefixed with a "#", does this mean they are all commented out or is the "#" required syntax, but I am not seeing the issue, or at least not like it randomly used to be.
Typically that means these are the default values. Uncomment and change the value to customize it.
Thankyou, I wasn't sure if this used the reverse logic I've seen in other config files where if you removed the "#" the statement got ignored.
regards, Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Sun, 17 Jul 2022 19:14:09 +0200 Francis.Montagnac@inria.fr wrote:
Did you specified the [Manager] tag in the drop-in file ?
Example:
## Weird: systemd seems to uses internally a ...USec name for that systemctl show --property=DefaultTimeoutStopUSec DefaultTimeoutStopUSec=1min 30s
mkdir /usr/lib/systemd/system.conf.d echo -e '[Manager]\nDefaultTimeoutStopSec=5s' > /usr/lib/systemd/system.conf.d/99-stop-fast.conf
systemctl daemon-reload
systemctl show --property=DefaultTimeoutStopUSec DefaultTimeoutStopUSec=5s
I can confirm that this also works. I copied /etc/systemd/system.conf to the newly created directory, /usr/lib/systemd/system.conf.d with a new name starting with 99, fixed the permissions and selinux context, uncommented the appropriate entry, changed its value, and it is working as if I changed it in /etc/systemd/system.conf and /etc/systemd/user.conf.
On Mon, 2022-07-18 at 06:08 -0700, stan via users wrote:
On Sun, 17 Jul 2022 19:14:09 +0200 Francis.Montagnac@inria.fr wrote:
Did you specified the [Manager] tag in the drop-in file ?
Example:
## Weird: systemd seems to uses internally a ...USec name for that systemctl show --property=DefaultTimeoutStopUSec DefaultTimeoutStopUSec=1min 30s
mkdir /usr/lib/systemd/system.conf.d echo -e '[Manager]\nDefaultTimeoutStopSec=5s' > /usr/lib/systemd/system.conf.d/99-stop-fast.conf
systemctl daemon-reload
systemctl show --property=DefaultTimeoutStopUSec DefaultTimeoutStopUSec=5s
I can confirm that this also works. I copied /etc/systemd/system.conf to the newly created directory, /usr/lib/systemd/system.conf.d with a new name starting with 99, fixed the permissions and selinux context, uncommented the appropriate entry, changed its value, and it is working as if I changed it in /etc/systemd/system.conf and /etc/systemd/user.conf.
I just created a new file in the system.conf.d directory. Didn't have to touch the SElinux context.
poc
On Mon, 18 Jul 2022 14:34:13 +0100 Patrick O'Callaghan pocallaghan@gmail.com wrote:
I just created a new file in the system.conf.d directory. Didn't have to touch the SElinux context.
I guess that makes sense, since the file doesn't exist on the system, so there isn't any selinux rule for it. I was just being thorough, have been bitten by copying a file and losing the context before.
On Sun, 2022-07-17 at 10:27 -0400, Tom Horsley wrote:
On Sun, 17 Jul 2022 15:17:56 +0100 Patrick O'Callaghan wrote:
OK. Where is that configured (too lazy to look it up :-)?
I made this chage: "DefaultTimeoutStopSec=5s" in both /etc/systemd/system.conf and /etc/systemd/user.conf
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.
poc
On Mon, 15 Aug 2022 12:19:20 +0100 Patrick O'Callaghan wrote:
On Sun, 2022-07-17 at 10:27 -0400, Tom Horsley wrote:
On Sun, 17 Jul 2022 15:17:56 +0100 I made this chage: "DefaultTimeoutStopSec=5s" in both /etc/systemd/system.conf and /etc/systemd/user.conf
This solution has simply stopped working.
This did work for a time, but now makes no difference. I've changed nothing apart from system updates.
Those updates may have changed some TimeoutStopSec= under /usr/lib/systemd/user
I once again have to manually kill the offending process (kded) to avoid a 90-second delay on shutdown/reboot/re-login.
You can try to override the plasma-kded.service itself as follows:
mkdir -p ~/.config/systemd/user/plasma-kded.service.d cat > ~/.config/systemd/user/plasma-kded.service.d/stop.conf <<EOF [Service] TimeoutStopSec=5s EOF systemctl --user daemon-reload
There is also the TimeoutAbortSec= (and DefaultTimeoutAbortSec=) parameter, but plasma-kded.service do not declare Type=notify and thus this should not apply.
Probably not helpful info, but I had dhcpd simply refuse to pay attention to the signal that was intended to make it cleanly shut down on a system at work several months ago. I even did enough debugging to verify the signal was in fact being delivered to the signal handler in the dhcpd process, but it simply didn't exit. Maybe kded has contracted a similar virus :-).
On Mon, 15 Aug 2022 12:19:20 +0100 Patrick O'Callaghan wrote:
This solution has simply stopped working. The default timeout is indeed set as described:
$ systemctl show --property=DefaultTimeoutStopUSec DefaultTimeoutStopUSec=5s
Have you checked also for systemctl --user ?
(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)
I have seen that and though as you that it was not documented, but it is.
Go first in man systemd.directives, then search for it:
TimeoutStopUSec org.freedesktop.systemd1(5)
then search for it in the man of org.freedesktop.systemd1: around the line number 1956 ... :-)
This reflects that fact that internally the service manager deals in microsecond units only
On Mon, 2022-08-15 at 15:21 +0200, Francis.Montagnac@inria.fr wrote:
On Mon, 15 Aug 2022 12:19:20 +0100 Patrick O'Callaghan wrote:
This solution has simply stopped working. The default timeout is indeed set as described:
$ systemctl show --property=DefaultTimeoutStopUSec DefaultTimeoutStopUSec=5s
Have you checked also for systemctl --user ?
$ systemctl --user show --property=DefaultTimeoutStopUSec DefaultTimeoutStopUSec=1min 30s
Aha! Now where do I change that?
(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)
I have seen that and though as you that it was not documented, but it is.
Go first in man systemd.directives, then search for it:
TimeoutStopUSec org.freedesktop.systemd1(5)
then search for it in the man of org.freedesktop.systemd1: around the line number 1956 ... :-)
This reflects that fact that internally the service manager deals in microsecond units only
I see. However it doesn't really explain why I get:
$ systemctl show --property=DefaultTimeoutStopSec $
i.e. no output. IOW the parameter I explicitly set in the config file is listed as not being set, and there's no indication that the other parameter is the one I should be looking at. Had I not seen your earlier post on this, I would simply think that there was something wrong with how I was setting it (discounting the '--user' issue).
This is unbelievably obscure.
poc
On Mon, 15 Aug 2022 14:44:43 +0100 Patrick O'Callaghan wrote:
Aha! Now where do I change that?
There is a user.conf file right next to the system.conf file in the /etc/systemd directory. It has almost all the same parameters, and I always change both files when changing something to make sure I get both system and user settings.
On Mon, 15 Aug 2022 14:44:43 +0100 Patrick O'Callaghan wrote:
Have you checked also for systemctl --user ?
$ systemctl --user show --property=DefaultTimeoutStopUSec DefaultTimeoutStopUSec=1min 30s
Aha! Now where do I change that?
Either in:
/usr/lib/systemd/user.conf.d/99-stop-fast.conf /etc/systemd/user.conf.d/99-stop-fast.conf
With content:
[Manager] DefaultTimeoutStopSec=5s
Better IMO than changing /etc/systemd/user.conf
This reflects that fact that internally the service manager deals in microsecond units only
I see. However it doesn't really explain why I get:
$ systemctl show --property=DefaultTimeoutStopSec $
i.e. no output. IOW the parameter I explicitly set in the config file is listed as not being set, and there's no indication that the other parameter is the one I should be looking at. Had I not seen your earlier post on this, I would simply think that there was something wrong with how I was setting it (discounting the '--user' issue).
This is unbelievably obscure.
I agree.
On Mon, 2022-08-15 at 16:00 +0200, Francis.Montagnac@inria.fr wrote:
$ systemctl --user show --property=DefaultTimeoutStopUSec DefaultTimeoutStopUSec=1min 30s
Aha! Now where do I change that?
Either in:
/usr/lib/systemd/user.conf.d/99-stop-fast.conf /etc/systemd/user.conf.d/99-stop-fast.conf With content:
[Manager] DefaultTimeoutStopSec=5s
Better IMO than changing /etc/systemd/user.conf
Agreed. That (finally) seems to do the trick. Fingers crossed nothing else breaks.
Thanks again.
poc
-
Francis.Montagnac＠inria.fr -
Mike Wright -
Patrick O'Callaghan -
stan -
Stephen Morris -
Tom Horsley