> Am 17.01.2023 um 22:30 schrieb Chris Murphy :
>
>
>
> On Tue, Jan 17, 2023, at 11:51 AM, Peter Boy wrote:
>>> Am 16.01.2023 um 13:23 schrieb Lennart Poettering :
>>>
>>> Just to say this cleary btw: when we introduced the time-out initially
>>> we were coming from sysvinit where no such
On Tue, Jan 17, 2023, at 11:51 AM, Peter Boy wrote:
>> Am 16.01.2023 um 13:23 schrieb Lennart Poettering :
>>
>> Just to say this cleary btw: when we introduced the time-out initially
>> we were coming from sysvinit where no such time-out existed at
>> all. Hence we picked a conservative (i.e.
On Thu, Jan 12, 2023 at 09:36:39AM -0500, Colin Walters wrote:
> Ideally, we'd have a mechanism to define timeouts like this somehow
> relative to system speed (throughput) not simple wall clock time.
That's a nice idea. Meson has '-t' that is a multiplier for test
timeouts and it's quite useful.
> Am 16.01.2023 um 13:23 schrieb Lennart Poettering :
>
> Just to say this cleary btw: when we introduced the time-out initially
> we were coming from sysvinit where no such time-out existed at
> all. Hence we picked a conservative (i.e. overly long) value to not
> upset things too badly. And
On Mi, 11.01.23 16:35, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> We have thousands of systemd services in Fedora. To "just add timeouts
> to things that take too long" would mean updating them individually.
> (Or maybe only some, but we don't really know which ones.)
> This is
On Thu, Jan 12 2023 at 08:31:33 PM +, Jonathan Wakely
wrote:
IIUC the difficulty is finding out which ones are being slow, but that
could be solved by changing the signal to SIGABRT, right?
Well we still have to end with SIGKILL because SIGABRT is ignorable, so
the new proposed behavior
On Wed, 11 Jan 2023 at 16:36, Zbigniew Jędrzejewski-Szmek wrote:
>
> On Tue, Jan 10, 2023 at 06:16:07PM -0800, Kevin Fenzi wrote:
> > Ok, but it seems safer to just add timeouts to things that take too long
> > and can safely be killed off rather than lowering the timeout for
> > everything and
On Thu, Dec 22, 2022, at 12:35 PM, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer
>
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will
On Wed, Jan 11, 2023 at 5:36 PM Zbigniew Jędrzejewski-Szmek
wrote:
> Instead, the idea is to attack the problem from the other end: reduce
> the timeout for everyone. Once this happens, we should start getting
> feedback about what services where this doesn't work.
Sound's terrible to me.
Could
On Wed, Jan 11 2023 at 11:48:27 AM -0800, Kevin Fenzi
wrote:
I do appreciate the change to do an abort on these units. Will that
get
reported via abrt?
It should, yes, the same as any other crash.
___
devel mailing list --
On Wed, Jan 11, 2023 at 04:35:33PM +, Zbigniew Jędrzejewski-Szmek wrote:
>
> We have thousands of systemd services in Fedora. To "just add timeouts
> to things that take too long" would mean updating them individually.
> (Or maybe only some, but we don't really know which ones.)
Sure,
On Tue, Jan 10, 2023 at 06:16:07PM -0800, Kevin Fenzi wrote:
> On Tue, Jan 10, 2023 at 06:00:59PM -0600, Michael Catanzaro wrote:
> > On Tue, Jan 10 2023 at 03:19:10 PM -0800, Kevin Fenzi
> > wrote:
> > > Is there something wrong with that approach that I am not understanding?
> >
> > No, I
On Tue, Jan 10 2023 at 06:00:59 PM -0600, Michael Catanzaro
wrote:
I'm going to amend this proposal to specify
TimeoutStopFailureMode=abort as well, so we can get crash dumps and
bug reports when programs fail to quit properly.
By the way, the goal with this is to surface bugs and dodge any
On Tue, Jan 10, 2023 at 06:00:59PM -0600, Michael Catanzaro wrote:
> On Tue, Jan 10 2023 at 03:19:10 PM -0800, Kevin Fenzi
> wrote:
> > Is there something wrong with that approach that I am not understanding?
>
> No, I don't think you're missing anything. That should work fine for
> PackageKit.
On Tue, Jan 10 2023 at 03:19:10 PM -0800, Kevin Fenzi
wrote:
Is there something wrong with that approach that I am not
understanding?
No, I don't think you're missing anything. That should work fine for
PackageKit. But of course it won't do a thing to help with for other
services that are
On Mon, Jan 09, 2023 at 08:45:43PM +, Zbigniew Jędrzejewski-Szmek wrote:
>
> The current default is mostly arbitrary. It was just selected as a nice round
> value, in the spirit of "let's pick something large enough to be larger than
> any
> realistic process will ever need".
>
> I think
On Mon, Jan 9 2023 at 11:04:11 AM +0100, Lennart Poettering
wrote:
That said: dumping core is potentially extremely expensive (web
browsers have gigabytes of virtual memory that we might end up
processing and compressing). Quite often the stuff that is slow when
exiting is also the stuff that
On Sat, Jan 07, 2023 at 12:59:26AM +0100, Peter Boy wrote:
>
> > Am 06.01.2023 um 18:06 schrieb Michael Catanzaro :
> >
> > ...
> >
> > I think most of the feedback on this change can be summarized as:
> >
> > (a) Specific services want longer timeouts.
> >
> > This can already be configured
On Mon, Jan 09, 2023 at 11:04:11AM +0100, Lennart Poettering wrote:
> On Fr, 06.01.23 11:06, Michael Catanzaro (mcatanz...@redhat.com) wrote:
>
> > Maybe instead of SIGKILL, we should send SIGQUIT instead. That way abrt
> > should complain next time you boot and users will have an opportunity to
On Sat, Jan 7, 2023 at 9:31 AM Giuseppe Scrivano
wrote:
>
> I've just opened a PR upstream for Podman to kill -9 all the remaining
> exec sessions when the container process terminates, so both --pid=host
> and --pid=private behaves in the same way. It would solve the issue we
> are seeing.
>
>
On Fr, 06.01.23 11:06, Michael Catanzaro (mcatanz...@redhat.com) wrote:
> Maybe instead of SIGKILL, we should send SIGQUIT instead. That way abrt
> should complain next time you boot and users will have an opportunity to
> report bugs to the package maintainer, instead of the problem being
> Am 06.01.2023 um 18:06 schrieb Michael Catanzaro :
>
> ...
>
> I think most of the feedback on this change can be summarized as:
>
> (a) Specific services want longer timeouts.
>
> This can already be configured via existing configuration mechanisms, so I
> think it's safe enough to ignore
On Fri, Jan 6 2023 at 11:06:26 AM -0600, Michael Catanzaro
wrote:
(a) Specific services want longer timeouts.
This can already be configured via existing configuration mechanisms,
so I think it's safe enough to ignore this problem. E.g. if a quick
shutdown will brick your Pinephone modem or
On Fri, Jan 6 2023 at 09:47:29 AM -0500, Matthias Clasen
wrote:
On my Silverblue system, the main offender for this is podman.
As soon as I have a toolbox running, conmon holds up the reboot for a
very long time because it refuses to shutdown properly.
Maybe instead of SIGKILL, we should
Am 30.12.22 um 10:42 schrieb Peter Boy:
Am 30.12.2022 um 06:59 schrieb Nico Kadel-Garcia :
Am 28.12.22 um 11:49 schrieb Peter Boy:
It is a good idea to make the timeout configurable. But the default timeout
for servers must remain unchanged.
My problem is not "defined timeouts" it
On my Silverblue system, the main offender for this is podman.
As soon as I have a toolbox running, conmon holds up the reboot for a very
long time because it refuses to shutdown properly.
___
devel mailing list -- devel@lists.fedoraproject.org
To
On Thu, Dec 22, 2022 at 12:35:54PM -0500, Ben Cotton wrote:
> The most common service to cause this issue is PackageKit, but there
> are others.
NFSv4 unmounts too. I think there's some ordering issue. I use NFS
everywhere and this delay is frustrating, so a shorter delay would be
welcome.
> Am 30.12.2022 um 19:45 schrieb Nico Kadel-Garcia :
>
> We need to be cautious about
> not being able to personally picture why someone would use an existing
> default and overriding it casually, and inflicting our new logic on
> the unsuspecting existing userbase.
+1!
--
Peter Boy
On Fri, Dec 30, 2022 at 12:02 PM Tomasz Torcz wrote:
>
> On Fri, Dec 30, 2022 at 12:59:19AM -0500, Nico Kadel-Garcia wrote:
> > On Wed, Dec 28, 2022 at 7:01 AM Ralf Corsépius wrote:
> > >
> > > Am 28.12.22 um 11:49 schrieb Peter Boy:
> > > >
> > > > It is a good idea to make the timeout
On Fri, Dec 30, 2022 at 12:59:19AM -0500, Nico Kadel-Garcia wrote:
> On Wed, Dec 28, 2022 at 7:01 AM Ralf Corsépius wrote:
> >
> > Am 28.12.22 um 11:49 schrieb Peter Boy:
> > >
> > > It is a good idea to make the timeout configurable. But the default
> > > timeout for servers must remain
On Fri, Dec 30 2022 at 10:42:29 AM +0100, Peter Boy
wrote:
But the **default* values must provide the most safe operation
possible and not require any intervention from the system
administrator to achieve that.
I think we need to find some way for Workstation to have different
defaults than
On 12/30/22 06:59, Nico Kadel-Garcia wrote:
You've apparently not encountered the corruption of a database under
heavy load where the cache where swapspace has not yet been propagated
to disk. Imagine a server running a lot of virtual machines for an
image of what an overly aggressive shutdown
> Am 30.12.2022 um 06:59 schrieb Nico Kadel-Garcia :
>
>> Am 28.12.22 um 11:49 schrieb Peter Boy:
>>>
>>> It is a good idea to make the timeout configurable. But the default
>>> timeout for servers must remain unchanged.
>>
>> My problem is not "defined timeouts" it is systemd delaying
On Fri, 2022-12-30 at 00:59 -0500, Nico Kadel-Garcia wrote:
> On Wed, Dec 28, 2022 at 7:01 AM Ralf Corsépius
> wrote:
> >
> > Am 28.12.22 um 11:49 schrieb Peter Boy:
> > >
> > > It is a good idea to make the timeout configurable. But the
> > > default timeout for servers must remain unchanged.
On Wed, Dec 28, 2022 at 7:01 AM Ralf Corsépius wrote:
>
> Am 28.12.22 um 11:49 schrieb Peter Boy:
> >
> > It is a good idea to make the timeout configurable. But the default
> > timeout for servers must remain unchanged.
>
> My problem is not "defined timeouts" it is systemd delaying shutdowns
Fabio Valentini wrote:
> Even if systemd prints nice diagnostic messages, they're useless if
> nobody is going to see them.
> And I doubt that many people know that pressing the Esc key makes
> plymouth go away.
Quite. Troubleshooting information as an Easter egg! Seriously people,
is there some
On Wed, 28 Dec 2022 at 08:45, Peter Boy wrote:
>
>
> > Am 28.12.2022 um 13:00 schrieb Ralf Corsépius :
> >
> >
> >
> > Am 28.12.22 um 11:49 schrieb Peter Boy:
> >> It is a good idea to make the timeout configurable. But the default
> timeout for servers must remain unchanged.
> >
> > My problem
> Am 28.12.2022 um 15:23 schrieb Neal Gompa :
>
> On Wed, Dec 28, 2022 at 9:13 AM Peter Boy wrote:
>>
>>
>>
>>> Am 28.12.2022 um 13:34 schrieb Neal Gompa :
>>>
>>> On Wed, Dec 28, 2022 at 7:25 AM Frank Crawford
>>> wrote:
...
I'd also note that this has always been
On Wed, Dec 28, 2022 at 9:13 AM Peter Boy wrote:
>
>
>
> > Am 28.12.2022 um 13:34 schrieb Neal Gompa :
> >
> > On Wed, Dec 28, 2022 at 7:25 AM Frank Crawford
> > wrote:
> >>
> >> ...
> >>
> >> I'd also note that this has always been configurable, it is just now
> >> suggesting a different value
> Am 28.12.2022 um 13:34 schrieb Neal Gompa :
>
> On Wed, Dec 28, 2022 at 7:25 AM Frank Crawford
> wrote:
>>
>> ...
>>
>> I'd also note that this has always been configurable, it is just now
>> suggesting a different value from the default.
>
> I would also suggest that if you're shutting
On Wed, Dec 28, 2022 at 8:45 AM Peter Boy wrote:
>
>
>
> > Am 28.12.2022 um 13:00 schrieb Ralf Corsépius :
> >
> >
> >
> > Am 28.12.22 um 11:49 schrieb Peter Boy:
> >> It is a good idea to make the timeout configurable. But the default
> >> timeout for servers must remain unchanged.
> >
> > My
> Am 28.12.2022 um 13:00 schrieb Ralf Corsépius :
>
>
>
> Am 28.12.22 um 11:49 schrieb Peter Boy:
>> It is a good idea to make the timeout configurable. But the default timeout
>> for servers must remain unchanged.
>
> My problem is not "defined timeouts" it is systemd delaying shutdowns
On Sat, Dec 24, 2022 at 4:38 AM Steve Grubb wrote:
>
> On Friday, December 23, 2022 1:34:48 PM EST Alexander Ploumistos wrote:
> > On Fri, Dec 23, 2022 at 7:21 PM Steve Grubb wrote:
> > > This is nice, but all I ever seen is a black screen and a spinning
> > > circle. No text of any kind. If
On Wed, Dec 28, 2022 at 7:25 AM Frank Crawford wrote:
>
> On Wed, 2022-12-28 at 13:00 +0100, Ralf Corsépius wrote:
> >
> >
> > Am 28.12.22 um 11:49 schrieb Peter Boy:
> > >
> > > It is a good idea to make the timeout configurable. But the
> > > default timeout for servers must remain unchanged.
On Wed, 2022-12-28 at 13:00 +0100, Ralf Corsépius wrote:
>
>
> Am 28.12.22 um 11:49 schrieb Peter Boy:
> >
> > It is a good idea to make the timeout configurable. But the
> > default timeout for servers must remain unchanged.
>
> My problem is not "defined timeouts" it is systemd delaying
Am 28.12.22 um 11:49 schrieb Peter Boy:
It is a good idea to make the timeout configurable. But the default timeout
for servers must remain unchanged.
My problem is not "defined timeouts" it is systemd delaying shutdowns
for no obvious reasons.
And as you asked: On my (bare metal)
> Am 22.12.2022 um 19:29 schrieb Adam Williamson :
>
> On Thu, 2022-12-22 at 18:44 +0100, Tomasz Torcz wrote:
>> On Thu, Dec 22, 2022 at 12:35:54PM -0500, Ben Cotton wrote:
>>> https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer
>>>
>>> This document represents a proposed Change. As
On Friday, December 23, 2022 1:34:48 PM EST Alexander Ploumistos wrote:
> On Fri, Dec 23, 2022 at 7:21 PM Steve Grubb wrote:
> > This is nice, but all I ever seen is a black screen and a spinning
> > circle. No text of any kind. If something were written to the console,
> > how do you see it?
>
On Fri, Dec 23, 2022 at 7:21 PM Steve Grubb wrote:
>
> This is nice, but all I ever seen is a black screen and a spinning circle. No
> text of any kind. If something were written to the console, how do you see
> it?
Have you tried hitting "Esc" when that happens?
Hello,
On Friday, December 23, 2022 9:48:22 AM EST Zbigniew Jędrzejewski-Szmek
wrote:
> On Fri, Dec 23, 2022 at 08:09:56AM +0100, Tomasz Torcz wrote:
> > On Thu, Dec 22, 2022 at 05:22:09PM -0500, Steve Grubb wrote:
> > > On Thursday, December 22, 2022 1:29:29 PM EST Adam Williamson wrote:
> > >
On Fri, Dec 23, 2022, at 12:56 AM, Demi Marie Obenour wrote:
> Why cache mode unsafe? How big a performance win is it?
Huge. In effect fsync is ignored. So if the host dies, write order is not
guaranteed and can toast the guest file system.
The guest dying shouldn't pose a problem because
Hello,
On Friday, December 23, 2022 6:52:02 AM EST Tom Hughes via devel wrote:
> On 23/12/2022 11:45, Naheem Zaffar wrote:
> > On Fri, 23 Dec 2022 at 08:26, Vitaly Zaitsev via devel
> > mailto:devel@lists.fedoraproject.org>>
> > wrote:
> > On 23/12/2022 09:20, Mattia Verga via devel wrote:
if you have persistent Journaling enabled, you'll find them in your last
boot log
On Fri, Dec 23, 2022, 08:55 Mattia Verga via devel <
devel@lists.fedoraproject.org> wrote:
> Il 23/12/22 15:48, Zbigniew Jędrzejewski-Szmek ha scritto:
> >
> > Yeah. We added printing of a lot of information in
> >
Il 23/12/22 15:48, Zbigniew Jędrzejewski-Szmek ha scritto:
>
> Yeah. We added printing of a lot of information in
> https://github.com/systemd/systemd/commit/3889fc6fc347f0e12070f7b873d065508c8df816:
>
> Example output:
>
> Stopping user@1000.service...
> [ OK ] Stopped
On Thu, Dec 22, 2022 at 12:35:54PM -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer
>
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal
On Fri, Dec 23, 2022 at 08:09:56AM +0100, Tomasz Torcz wrote:
> On Thu, Dec 22, 2022 at 05:22:09PM -0500, Steve Grubb wrote:
> > On Thursday, December 22, 2022 1:29:29 PM EST Adam Williamson wrote:
> > > 15 seconds feels very aggressive to me. I can think of some cases, like
> > > libvirtd
On Thu, Dec 22, 2022 at 10:40:23PM +0100, allan2016--- via devel wrote:
> På Thu, 22 Dec 2022 10:29:29 -0800
> Adam Williamson skrev:
> > On Thu, 2022-12-22 at 18:44 +0100, Tomasz Torcz wrote:
> > > On Thu, Dec 22, 2022 at 12:35:54PM -0500, Ben Cotton wrote:
> > > >
On 23/12/2022 11:45, Naheem Zaffar wrote:
On Fri, 23 Dec 2022 at 08:26, Vitaly Zaitsev via devel
mailto:devel@lists.fedoraproject.org>>
wrote:
On 23/12/2022 09:20, Mattia Verga via devel wrote:
> I know this is way harder, but the right approach would be having
a way
> to
On Fri, 23 Dec 2022 at 08:26, Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:
> On 23/12/2022 09:20, Mattia Verga via devel wrote:
> > I know this is way harder, but the right approach would be having a way
> > to tell systemd what processes can be killed and what other processes
On 23/12/2022 09:20, Mattia Verga via devel wrote:
I know this is way harder, but the right approach would be having a way
to tell systemd what processes can be killed and what other processes
must not be forced off in any case, then display a user friendly message
which inform the user that the
Il 22/12/22 18:35, Ben Cotton ha scritto:
> https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer
>
I think this is not the right approach to solve the problem. Basically,
we're saying "I don't know what's going on, just pull the plug, I don't
care about data corruption", which is going to
On 22/12/2022 18:35, Ben Cotton wrote:
A downstream configuration change to reduce the systemd unit timeout
from 2 minutes to 15 seconds.
+1 for this change. I've already reduced this timeout both on my desktop
and laptop to even 10 seconds.
--
Sincerely,
Vitaly Zaitsev
On Thu, Dec 22, 2022 at 05:22:09PM -0500, Steve Grubb wrote:
> On Thursday, December 22, 2022 1:29:29 PM EST Adam Williamson wrote:
> > 15 seconds feels very aggressive to me. I can think of some cases, like
> > libvirtd automatically suspending or cleanly shutting down running VMs,
> > that might
On 12/22/22 14:55, Chris Murphy wrote:
>
>
> On Thu, Dec 22, 2022, at 1:29 PM, Adam Williamson wrote:
>> On Thu, 2022-12-22 at 18:44 +0100, Tomasz Torcz wrote:
>>> On Thu, Dec 22, 2022 at 12:35:54PM -0500, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer
On Thu, Dec 22, 2022, at 5:22 PM, Steve Grubb wrote:
> On Thursday, December 22, 2022 1:29:29 PM EST Adam Williamson wrote:
>> On Thu, 2022-12-22 at 18:44 +0100, Tomasz Torcz wrote:
>>
>> > On Thu, Dec 22, 2022 at 12:35:54PM -0500, Ben Cotton wrote:
>> >
>> > >
On Thursday, December 22, 2022 1:29:29 PM EST Adam Williamson wrote:
> On Thu, 2022-12-22 at 18:44 +0100, Tomasz Torcz wrote:
>
> > On Thu, Dec 22, 2022 at 12:35:54PM -0500, Ben Cotton wrote:
> >
> > > https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer
> > >
> > > This document
På Thu, 22 Dec 2022 10:29:29 -0800
Adam Williamson skrev:
> On Thu, 2022-12-22 at 18:44 +0100, Tomasz Torcz wrote:
> > On Thu, Dec 22, 2022 at 12:35:54PM -0500, Ben Cotton wrote:
> > > https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer
> > >
> > > This document represents a proposed
On Thu, Dec 22, 2022 at 8:55 PM Chris Murphy wrote:
>
> Also I wonder if there's a way for desktops to opt into this behavior? Or a
> way for servers, iot, cloud, and rpm-ostree based systems to opt out?
Do you mean like setting the "DefaultTimeoutStopSec" variable in
/etc/systemd/system.conf?
On Thu, Dec 22, 2022, at 1:29 PM, Adam Williamson wrote:
> On Thu, 2022-12-22 at 18:44 +0100, Tomasz Torcz wrote:
>> On Thu, Dec 22, 2022 at 12:35:54PM -0500, Ben Cotton wrote:
>> > https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer
>> >
>> > This document represents a proposed
On 22/12/2022 19:18, Michael Catanzaro wrote:
On Thu, Dec 22 2022 at 10:29:29 AM -0800, Adam Williamson
wrote:
Could we not go for 30 seconds?
Personally I think 30 seconds is way too long for desktop users. But
it's a lot better than 2 minutes, so if that's what we settle on, I
won't
On Thu, Dec 22 2022 at 10:29:29 AM -0800, Adam Williamson
wrote:
Could we not go for 30 seconds?
Personally I think 30 seconds is way too long for desktop users. But
it's a lot better than 2 minutes, so if that's what we settle on, I
won't complain.
libvirtd should probably take an
On Thu, 2022-12-22 at 18:44 +0100, Tomasz Torcz wrote:
> On Thu, Dec 22, 2022 at 12:35:54PM -0500, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer
> >
> > This document represents a proposed Change. As part of the Changes
> > process, proposals are publicly
https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering
On Thu, Dec 22, 2022 at 12:35:54PM -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer
>
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal
https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering
75 matches
Mail list logo
