Antw: Re: Antw: [EXT] emergency shutdown, don't wait for timeouts

["Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>]

>>> Chris Murphy <lists@xxxxxxxxxxxxxxxxx> schrieb am 06.01.2021 um 03:02 in
Nachricht
<CAJCQCtTu23a3W56tfDDy061mZvBiXRUaAhuue=W0A6CSwM44Yw@xxxxxxxxxxxxxx>:
> On Mon, Jan 4, 2021 at 12:43 PM Phillip Susi <phill@xxxxxxxxxxxx> wrote:
>>
>>
>> Reindl Harald writes:
>>
>> > i have seen "user manager" instances hanging for way too long and way
>> > more than 3 minutes over the last 10 years
>>
>> The default timeout is 3 minutes iirc, so at that point it should be
>> forcibly killed.
> 
> Hi,
> 
> This is too long for a desktop or laptop use case. It should be around
> 15‑20 seconds. It's completely reasonable for users to reach for the
> power button and force it off by 30 seconds.

Have you ever tried shutting down multiple virtual machines having disks on a
slow medium?

> 
> Fedora Workstation Working Group is tracking an issue expressly to get
> to around 20 seconds (or better).
> https://pagure.io/fedora‑workstation/issue/163 
> 
> It is a given there will be some kind of state or data loss by just
> forcing a shutdown. I think what we need is the console, revealed by
> ESC, needs to contain sufficient information on what and why the
> reboot/shutdown is being held back. So that we can figure out why
> those processes aren't terminating fast enough and get them fixed.

There may be bugs, and there may be processes that simply take time.

> 
> A journaled file system should just do log replay at the next mount
> and the file system itself will be fine. Fine means consistent. But

That's nonsense: I'd prefer to wait and NOT lose data.

> for overwriting file systems, files could be left in an in‑between
> state. It just depends on what's being written to and when and how. A
> COW file system can better survive an abrupt poweroff since nothing is
> being overwritten. But I'm skeptical just virtually pulling the power
> cord is such a great idea to depend on. And for offline updates, we'd
> want to inhibit the aggressive reboot/shutdown, to ensure updating is
> complete and all writes are on stable media.

I wonder how robust an LVM thin pool is when you shut off the power while
multiple LVs allocate blocks from it (just for an example).

> 
> But for the aggressive shutdown case, some way of forcing remount ro?
> Or possibly FIFREEZE/FITHAW?
> 
> Some boot/bootloader folks have asked fs devs for an atomic
> freeze+thaw ioctl, i.e. one that is guaranteed to return to thaw. But
> this has been rebuffed so far. While thaw seems superfluous for the
> use case under discussion, it's possible poweroff command will be
> blocked by the freeze. And the thaw itself can be blocked by the
> freeze, when sysroot is the file system being frozen.

Where would freeze actually help?

> 
> 
> ‑‑ 
> Chris Murphy
> _______________________________________________
> systemd‑devel mailing list
> systemd‑devel@xxxxxxxxxxxxxxxxxxxxx 
> https://lists.freedesktop.org/mailman/listinfo/systemd‑devel 



_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel