On Mon, 2022-08-15 at 16:00 +0200, francis.montag...@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.
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.
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
On Mon, 2022-08-15 at 15:21 +0200, francis.montag...@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
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
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
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 s
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
On Mon, 18 Jul 2022 14:34:13 +0100
Patrick O'Callaghan 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 th
On Mon, 2022-07-18 at 06:08 -0700, stan via users wrote:
> On Sun, 17 Jul 2022 19:14:09 +0200
> francis.montag...@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
> > system
On Sun, 17 Jul 2022 19:14:09 +0200
francis.montag...@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 30
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.montag...@inria.fr wrote:
Hi.
On Sun, 17 Jul 2022 17:39:35 +0100 Patrick O'Callaghan wrote:
Actually, according to systemd-syst
On Sun, 17 Jul 2022 20:48:59 -0400
R. G. Newbury wrote:
> And also reminds me why Linux can be considered a cult, as there are
> arcane and unknown rules controlling how things work.
I always say "Without google, linux itself would be impossible."
___
On 2022-07-17 15:17, francis.montag...@inria.fr wrote
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.
Pr
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.montag...@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 p
On 18/7/22 04:41, Patrick O'Callaghan wrote:
On Sun, 2022-07-17 at 19:14 +0200, francis.montag...@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
On Sun, 2022-07-17 at 19:14 +0200, francis.montag...@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.co
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 be
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
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 configur
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: "DefaultTimeou
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
On Sun, 17 Jul 2022 10:27:52 -0400
Tom Horsley 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 stan
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
___
users mailing list --
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, a
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
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
27 matches
Mail list logo
