Re: [systemd-devel] Antw: [EXT] emergency shutdown, don't wait for timeouts
Am 04.01.21 um 20:41 schrieb Phillip Susi: 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. i have seen often enough more than one user-manager instance and the total wait was way longer then the configured timeout - no matter why and if it comes to dependencies the 3 minutes get multiplied easily when more than one service is running into the tmeout and waitung for each other frankly, i had cases where i was tempted to plug the power becaus eof endless wait however, it simply makes sense to have a different timeout at emegergency shutdown and if it only ensures that important services even get the change to shutdown cleanly in their dependency chain before power goes away ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: [EXT] emergency shutdown, don't wait for timeouts
Am 04.01.21 um 20:06 schrieb Phillip Susi: Reindl Harald writes: 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" It is that point that really should be at least 3 minutes before power fails. As long as the battery lasts for at least 3 minutes, then the monitoring daemon should easily be able to begin the shutdown when 3 minutes remain. I'm not sure that forcibly killing services to quickly shut down is really much better than the sudden power loss you are trying to avoid i have seen "user manager" instances hanging for way too long and way more than 3 minutes over the last 10 years machines where a regulayr reboot normally takes 5 seconds until ping responds again after type "reboot" there is a large scale between "wait virtually forever" and "quickly shutdown everything without any sense" ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: [EXT] emergency shutdown, don't wait for timeouts
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
Re: [systemd-devel] Antw: [EXT] emergency shutdown, don't wait for timeouts
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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: [EXT] emergency shutdown, don't wait for timeouts
Reindl Harald writes: > 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" It is that point that really should be at least 3 minutes before power fails. As long as the battery lasts for at least 3 minutes, then the monitoring daemon should easily be able to begin the shutdown when 3 minutes remain. I'm not sure that forcibly killing services to quickly shut down is really much better than the sudden power loss you are trying to avoid. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: [EXT] emergency shutdown, don't wait for timeouts
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" ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Antw: [EXT] emergency shutdown, don't wait for timeouts
>>> 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). Somedatabases need several minutes to shut down cleanly. Despite of that you could prefix your shutdown command with a sync, keeping fingers crossed while watching how far it (the regular shutdown) gets... > > Thank you > > > ___ > 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
