On Wed, Dec 28, 2022 at 7:25 AM Frank Crawford <frank@xxxxxxxxxxxxxxxxxx> wrote: > > On Wed, 2022-12-28 at 13:00 +0100, Ralf Corsépius wrote: > > > > > > Am 28.12.22 um 11:49 schrieb Peter Boy: > > > > > > It is a good idea to make the timeout configurable. But the > > > default timeout for servers must remain unchanged. > > > > My problem is not "defined timeouts" it is systemd delaying shutdowns > > for no obvious reasons. > > > > And as you asked: On my (bare metal) servers, Im am occasionally > > experiencing delayed shutdowns in the order of several minutes. > > > > This is simply inacceptable! > > At one stage I timed this for an NFS failure and it took 30-40mins to > finally timeout and reboot. In some cases, especially related to > filesystems and umounts it will try a number of time, eventually give > up after 3 * 90s, and then come back to it again later, going through > the whole process again. Worse still it had already had issues with > stopping executable on that filesystem, as not everything is run in > parallel. > > However, given some of the arguments raised, it may be worth looking a > different values for workstations/laptops against real servers. If a > workstation or laptop doesn't reboot in a minute or so, they will > usually get hit with a force reset. Real server installations are very > different, they will almost always be left to reboot "eventually". > > I'd also note that this has always been configurable, it is just now > suggesting a different value from the default. I would also suggest that if you're shutting down/rebooting a server, then you really want that to be done sooner rather than later, so stuff getting killed as it shuts down if it doesn't do it normally after SIGTERM is probably fine, because they're likely hung. Waiting a half hour for a system to reboot is not acceptable. 15 or 30 seconds is probably fine, even for servers, because of the nature of how systemd processes this timeout. It's per service being shut down, rather than a global timeout. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
