On Mon, Jan 4, 2021 at 12:43 PM Phillip Susi 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.
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.
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
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.
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.
--
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
