On 12/22/22 14:55, Chris Murphy wrote: > > > On Thu, Dec 22, 2022, at 1:29 PM, Adam Williamson wrote: >> On Thu, 2022-12-22 at 18:44 +0100, Tomasz Torcz wrote: >>> On Thu, Dec 22, 2022 at 12:35:54PM -0500, Ben Cotton wrote: >>>> https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer >>>> >>>> This document represents a proposed Change. As part of the Changes >>>> process, proposals are publicly announced in order to receive >>>> community feedback. This proposal will only be implemented if approved >>>> by the Fedora Engineering Steering Committee. >>>> >>>> == Summary == >>>> A downstream configuration change to reduce the systemd unit timeout >>>> from 2 minutes to 15 seconds. >>> >>> Great change, please do it! >>> Also, sometimes after reaching the timeout, systemd extends wait by >>> another 2 minutes (or 1m30). I wasn't able to find in the sources or >>> documentation why this happens, but this behaviour should be blocked. >>> Otherwise some services after 15s will get another 15, and then another… >> >> 15 seconds feels very aggressive to me. I can think of some cases, like >> libvirtd automatically suspending or cleanly shutting down running VMs, >> that might well take longer than that. Could we not go for 30 seconds? >> Going all the way from 90/120 down to 15 seems pretty radical. > > Yeah. I'm not opposed to the change, and I understand the main impetus behind it (PackageKitd), but it's the consequences of unknowns that I'm still left scratching my head trying to imagine worse case before we actually subject users to it. > > There really isn't a good kernel facility for something in between SIGTERM which is ignorable, and SIGKILL which isn't. And I'm not familiar with systemd's facilities for tracking service shutdown progress. i.e. I'm OK with SIGKILL for a process that isn't responding. But I'm also not sure if there's a facility for a process indicating either "I'm working on it" or "don't force kill me or it'll be bad". > > I also don't know if privileged services doing writes to the file system can inhibit either remount read-only or umount? And if so, do we just wait for all of that to complete? I think we'd have to. I'm pretty leery of rebooting forcibly even if we can't remount ro because some process is holding things up, doing the best it can to flush. Databases and VM's do come to mind, in particular because I routinely run VMs on my laptop with cache mode unsafe. If the VM is forcibly quit, it's fine. But if the host is forcibly rebooted before the VM's pending writes are completed by the host, that'd be bad (regardless of the file system choice). Why cache mode unsafe? How big a performance win is it? -- Sincerely, Demi Marie Obenour (she/her/hers) _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
