Re: systemd replacement or standardization

[Alexander Vdolainen]

Hi,

On 10/14/19 2:22 PM, František Kučera wrote:
> 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.

That's for sure!

> 
> 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.

It looks like a xinetd new feature, but - do we really need a dbus?

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

But not in a way systemd implemented it.

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

Is it about a set of user processes running during the login process ?
If so, I suppose it's out of scope the init system, it's some kind of
extra feature.

> 
> But I also seriously hate several features of systemd:

I don't like systemd at all, but it's offtopic.

> 
>  - 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:

GNU Shepherd is a nice thing however.

> 
>  - 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.

I suppose to not follow the systemd story to be so invasive. It should
be quite optional.

> 
>  - 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)“.

I can start with that, because by a strange coincidence I have had a
problem starting a set of daemons properly. Well, in my case there are a
few daemons depends on other daemon and/or other service (service is a
udp/tcp/unix socket(s)). Another problem was a requirement to start
those daemons as soon as possible. Finally - I do *not* want to modify
code of the well working daemons (and this is a bad way to get it
works). So, I have decided to write another daemon runs them in a right
order, waits for the sockets, solve dependencies etc ...
Some code pieces might be located on sf.net, but I don't expect someone
else might have a real interest with that.
(but I need to point here - it works on linux only (relies on /proc and
inotify() I guess))

I'm not sure is it interesting or not, however if somebody will join
with that - I can spend some of my spare time with that.

Going back to the systemd replacing - it might be done and, personally I
want to replace it, but needless to say it's a huge effort for one man.
BTW I suppose the following things should be taken onto account:
 - this new init should be a set of optional things like tools and daemons
 - new init shouldn't looks like a systemd-mess
 - sw architecture should be proposed first
 - features should be determined firstly

> 
> 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.

systemd is defective by design, but widely used - and it might be a
reason other init-systems hasn't advance yet.

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

-- 
Alexander Vdolainen,
Evil contractor.

signature.asc
Description: OpenPGP digital signature