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. 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel