Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

[Simon Richter <sjr@debian.org>]

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