gnu-system-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: systemd replacement or standardization


From: František Kučera
Subject: Re: systemd replacement or standardization
Date: Mon, 14 Oct 2019 21:57:32 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

Dne 14. 10. 19 v 19:54 Alexander Vdolainen napsal(a):
> It looks like a xinetd new feature, but - do we really need a dbus?

I wrote only one D-Bus service and quite simple, so I do not feel
capable to say how much useful is socket activation in this case. D-Bus
might be an optional feature.

However, I am sure that socket inheritance and activation for unix
domain sockets is useful and needed. Improvement of xinetd (or other
superserver) would be great. But I rather prefer this feature in the
init system. This feature is generic enough and directly linked to
process/service execution, so IMHO it is a task for an init system.

> But not in a way systemd implemented it.

What is bad with them? We can always imagine a better format, but I do
not think that systemd unit files are somehow terribly wrong.

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

In the user session you might be dealing with same tasks as in the
system session – e.g. service dependencies (run them in the correct
order) or that socket activation. And if you implement it in the
system-wide init system, it would be nice to be able to run another
instance of the same daemon in the user-session and enjoy same features
there – i.e. same tools or same format of config files. And it would be
independent from the desktop environment / window manager, so you can
run same services in KDE, Gnome, Xfce, Window maker atc.

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

The API might be just a set of standardized environment variables. It do
not have to require even a single header file. One variable might
contain comma separated list of inherited FDs and then you will check
e.g. INHERITED_FD_5_TYPE and see that this should be IMAP socket, so you
will respond to IMAP requests on it. Then check INHERITED_FD_6_TYPE and
see that this socket should be POP3.

This is not invasive, you can use any language and you do not have to
depend on any library or header file. Such standard would be very simple
and anyone would be able to implement it.

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

I am quite interested in unix domain sockets. Recently, I played with
them in Java <https://blog.frantovo.cz/c/372/> which officially does not
support them but is able to inherit an FD – so I was able to make e.g.
Jetty or Tomcat HTTP servers listen on an inherited unix domain socket.
It was quite fun. I did also a proof-of-concept of full unix domain
socket support for Java <http://frantovo.cz/disk/openjdk-uds-08/> and
offered it to OpenJDK, but they have not accepted it yet
<https://mail.openjdk.java.net/pipermail/net-dev/2019-July/012908.html>
(it seems that they would rather implement it themselves – but at least
someone from OpenJDK is working on it now).

> 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

Definitely. The core of the init system must be separated from various
daemons/services that must be optional. Things like DNS or HTTP server
are not part of an init system and should be distributed as an optional
module.

Franta


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]