Re: [systemd-devel] Antw: Re: Antw: [EXT] emergency shutdown, don't wait for timeouts
Am 07.01.21 um 09:15 schrieb Ulrich Windl: Chris Murphy schrieb am 06.01.2021 um 03:02 in Nachricht : On Mon, Jan 4, 2021 at 12:43 PM Phillip Susi wrote: 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? where is the problem? my machines shutdown within a few seconds as lonmg there is no systemd-unit hanging around for minutes without a good reason everytime in the past 10 years when shutown took more than 5 seconds it was some systemd-unit doing meditation happens regulary when i reboot our HP microserver on CentOS7 with RAID10 and LUKS on top of it - manually unlocked and mounted with a login script to enter the password and no that never finishes, it always runs in a timeout, no matter how long the timeout is while my shutdown alias is closing LUKS and unmounting the filesystem *before* issue "reboot" or "poweroff" [root@nfs:~]$ which reboot alias reboot='/usr/bin/bash /usr/local/bin/storage-services.sh stop; /usr/bin/systemctl reboot' 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. yes, and in case the stuff with the bugs is delaying important services which takes longer at it's own to even begin to stop you havbe a problem for a unit which takes time for good reasons you can configure that in the unit itself, no reason that everything waits for minutes 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. if the battery goes empty you will lose data for sure often the calculation how long the UPS can hold power isn't true when batteries get older and at the point a emergency shutdown is needed you have less time than expected ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: [EXT] emergency shutdown, don't wait for timeouts
Am 04.01.21 um 16:04 schrieb Ulrich Windl: Reindl Harald schrieb am 04.01.2021 um 14:53 in Nachricht <49b8413f-3131-658f-e21a-a1ee448a0...@thelounge.net>: Am 04.01.21 um 13:42 schrieb Ulrich Windl: Germano Massullo schrieb am 27.12.2020 um 14:26 in Nachricht : Good day, I recently joined apcupsd (APC UPS Power Control Daemon) package maintainers on Fedora/CentOS/RHEL. After a power failure, apcupsd shuts down the system with a command almost identical to shutdown ‑h ‑H now Usually when you normally shutdown your system, you may notice certain services taking too much time to terminate and triggering a timeout value before systemd forces them to terminate. I would like to ask if there is a way to force the system to shutdown without waiting for these timeouts in case an emergency like a power failure. Basically if the UPS cannot provide power for at least 3 minutes, it's simply the wrong UPS (IMHO) topic missed - it makes no difference if it can hold the power 3 minutes, 3 hours or even 3 days at the point where it decides "i need to shutdown everything because the battery goes empty" Harald, I did not say anything against shutting down everything. Maybe re-read but the topic is when it's at the point that a shutdown is necessary and the shutdown hangs for no good reason "if the UPS cannot provide power for at least 3 minutes" is simply off-topic the topic is that the shutdown needs to be finished before the UPS is empty even if it provided UPS power over hours before there is nothing like "the right UPS" when the damned machine hangs 15 minutes waiting to finish user-manager units as one well known example over years ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Antw: Re: Antw: [EXT] emergency shutdown, don't wait for timeouts
>>> Chris Murphy schrieb am 06.01.2021 um 03:02 in Nachricht : > 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. 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‑de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd‑devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Antw: Re: Antw: [EXT] emergency shutdown, don't wait for timeouts
>>> Reindl Harald schrieb am 04.01.2021 um 14:53 in Nachricht <49b8413f-3131-658f-e21a-a1ee448a0...@thelounge.net>: > > Am 04.01.21 um 13:42 schrieb Ulrich Windl: > Germano Massullo schrieb am 27.12.2020 um >> 14:26 in >> Nachricht : >>> Good day, I recently joined apcupsd (APC UPS Power Control Daemon) >>> package maintainers on Fedora/CentOS/RHEL. >>> After a power failure, apcupsd shuts down the system with a command >>> almost identical to >>> shutdown ‑h ‑H now >>> Usually when you normally shutdown your system, you may notice certain >>> services taking too much time to terminate and triggering a timeout >>> value before systemd forces them to terminate. I would like to ask if >>> there is a way to force the system to shutdown without waiting for these >>> timeouts in case an emergency like a power failure. >> >> Basically if the UPS cannot provide power for at least 3 minutes, it's > simply >> the wrong UPS (IMHO) > > topic missed - it makes no difference if it can hold the power 3 > minutes, 3 hours or even 3 days at the point where it decides "i need to > shutdown everything because the battery goes empty" Harald, I did not say anything against shutting down everything. Maybe re-read. Ulrich ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
