Hi, On Thu, Aug 08, 2019 at 08:15:29PM +0200, Vincent Bernat wrote:
> inetd performance is very low because it needs to spawn one instance for > each connection. systemd socket activation has absolutely 0 overhead > except on the first connection (where systemd needs to start the > service). If you specify "wait" instead of "nowait" for a TCP service, your service is handed the listening socket, and can continue to accept more connections on that socket. This feature went unused not because noone thought of it, but because there is no real world use case that benefits from it. Either the service is used regularly, then it makes sense to keep the daemon in memory, or it isn't, then the reduced complexity for one-shot services (to the point where you can use a shell script as a service) is the benefit. In the same way, we could have had automatic restart of services through sysvinit easily: an include mechanism that allows additional inittab lines to be pulled from /etc/inittab.d/* would be trivial to implement. That it hasn't been done is not because no one has thought about it in the last thirty years, but because its use is rather limited. SystemV init does not define service monitoring, because "the process still exists" is a useless metric, and proper monitoring tests service availability instead. There is no point in automatically restarting a crashed service either -- a crash has a reason that needs to be investigated. There is no service that is at the same time so important that it must not go down under any circumstances, and at the same time so unimportant that problems with it do not warrant human attention. The most useful thing systemd provides to server operators is a shorthand form for specifying some items in the process environment. Where an init script needs to set up the environment in the right order (e.g. go into the chroot before dropping permissions), having a descriptive language there takes care of some of the complexity -- but that is functionally equivalent to passing these values as arguments to start-stop-daemon. All of these things have been proposed multiple times over the last thirty years. They look useful on the outset, but the real-world use is limited. Simon