Fedora 38 Change Approved To Mandate Quicker Reboots/Shutdowns

[caligula]

Note this is raw disk speed. Actual speed can be lower (due to seeks (on mechanical drives), filesystem overhead, or the bottleneck not being the disk) or higher (with fast but effective compression).

Right, but I think 100 MB/s is a bit modest estimate. Mainly servers and outdated legacy hardware use spinning disks. Servers often use RAID arrays which multiplies the performance by a factor. For example I think my ZFS backup system from 2010 could do writes at 500 MB/s.

[RahulSundaram]

This default three seconds is dictated by upstream sysvinit since version 2.92. Check out the release notes to see when this came about:

https://lists.nongnu.org/archive/htm.../msg00003.html

It does tend to have an upstream. It used to be savannah but now that page points to GitHub (which always looks naff). .

To undescore my point there, the upstream source you are pointing to isn't the one Debian is directing using in their packages. A quick diff shows that they are likely patching that out. Refer to https://sources.debian.org/src/sysvi...-2/src/init.c/ which doesn't have the timeout.

But indeed, typical with Linux making it hard to find defacto documentation. But in all fairness; the whole point of distros is that they do diverge from upstream for different use-cases. Is this not exactly what Fedora is doing with their 45 second timeout change? So systemd is really no different. Possibly once it has the same kind of legacy baggage as sysvinit; it too will be all over the place when it comes to different distros.

FWIW, Fedora guidelines (which I wrote ages back) generally recommend to avoiding patching upstream and I don't consider divergence the whole point of distros but more importantly, systemd makes this readily configurable via a ini style setting in a config file so the patch amounts to just tweaking that config setting and uses cgroups so that it is actually enforced better, so the situation even with changes isn't the same.

[kpedersen]

To undescore my point there, the upstream source you are pointing to isn't the one Debian is directing using in their packages. A quick diff shows that they are likely patching that out. Refer to https://sources.debian.org/src/sysvi...-2/src/init.c/ which doesn't have the timeout.

The 3 sec timeout is there. It is in the .h file; you were looking at the .c file:

https://sources.debian.org/src/sysvi...rc/init.h/#L43

But yes; I do see what you are saying, different distros are free to munge up whatever software they pull in and with sysvinit this was especially true. However I would say that this doesn't change what is the standard set by upstream. It also isn't something that systemd inherently prevents.

I would say the closest evidence of that is Red Hat's focus on NetworkManager rather than systemd-networkd. They do tweak a few things here compared to many other distros.

I could of course fork Debian with the sole intention of screwing around with systemd's default kill timeouts. I could call it KillAfter5SecondsOS. Nice ring to it