systemd replacement or standardization

[František Kučera]

In <https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00322.html>
Svante Signell touched the topic of systemd. I think that it deserves
its own thread.

I like several features of systemd:

 - Socket activation: the service might inherit a file descriptor (FD)
with an open socket (TCP, UDP, unix domain socket, D-Bus) and not only
that: the service can be lazily-started when the first request comes to
the socket. It is similar to xinetd, but supports more socket types and
seems overall better.

 - Declarative configuration: a simple service can be described in a few
lines of config file. No procedural scripting or boilerplate code is
necessary.

 - User-defined services – not only system-wide (root) ones.

But I also seriously hate several features of systemd:

 - Complexity: circa 480 000 lines of code (and still growing).

 - Monolithic design: it is a single repository containing too much
features and tools. And if you like only certain features, there is no
easy way how to pick just them and enjoy less complexity.

 - Versioning: wrong versioning scheme (not semantic) and lack of stable
and standardized API.

Yes, we have GNU Shepherd and many other init systems and we can convert
users/distributions from systemd to other init system. But what about
doing – at the same time – some kind of „damage control“? Because we
already live in the world where systemd is widespread. Some ideas:

 - Have a stable and standardized API: e.g. if some service takes
advantage of the socket activation feature, it would be possible to
start such service from another init system without loosing this useful
feature and without the need of changing the source code. (note that it
is not as easy as it looks because the service might use several sockets
and you need an API to say, which FD is which socket e.g. one socket for
management and several sockets for accepting client connections or one
for encrypted and one for unencrypted communication, or one for IMAP4
and one for POP3) Or some watchdog API to check whether the service is
running properly or it is jammed.

 - Convert – or even load at runtime – the systemd declarative
configuration files. This also requires a stable standard.

 - Implement useful features of systemd in other init systems or
software: like implementing socket activation feature in another init
system or adding the unix domain socket support to xinetd[1]. It would
be a great „selling point“ if we can say: „we can provide same useful
features as systemd but with just a fraction of its complexity and in a
modular way (so you install only features, you need)“.

Franta

P.S. I might missed some news. It is some time since I studied various
init systems and compared them. So if something is already happening or
done, I would be happy to hear about it.

[1] yes, I know that it collides with the xinetd/inetd name which means
„internet daemon“ and AF_UNIX != AF_INET, but…