Re: systemd replacement or standardization

[Alexander Vdolainen]

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

yep, but I found https://github.com/xinetd-org/xinetd looks like
abandoned (and xinetd.org was unable to load anything). However it's
still possible to add this feature, but is it xinetd still used?

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

Make sense, but check out a more extended reply to this below.

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

it's actually the same mechanics, and I've got your point. So let's me
describe my thoughts about init system itself.

Let's split init system:
 - (a) init (a POSIX PID 1)
 - (b) daemon 'starter'
 - (c) daemon 'watchdog'
 - (d) tools?

Regarding 'a': this guy should be kept a very small, stable and simple.
For 'b', 'c' and might be 'd' the best way is to create a shared library
with all necessary functions. That means b,c and d might works anywhere
and independently on 'a'.

The next step is to define a functional scope of init system, let's assume:
 - os state support (SySV runlevels as example)
 - FS mount
 - Orphaned process handling
 - Networking
 - Daemons startup/shutdown process
From my point of view PID 1 - 'a' works with:
 - OS states support
 - Orphaned process handling
Other functionality is going to the other parts are working
independently ('b', 'c' and 'd's), but still able to sync somehow
(without DBus).
To do so, a few abstractions are coming onto play:
 - daemon (yep - just an old good daemon)
 - service: a named set of some resources
 - sublevel: a sub runlevel
All this things are *not* require a DBus, binary logs, libshitd
incorporated into daemons etc ...

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

... could you provide some working example for this ?

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

IMO, if you need to adopt your daemon for some system initialization
process it's a sign of poorly designed init system - that's my opinion.

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

Again IMO, it's not a huge task, it's done pretty simple. All you need
is to know how /proc/%PID structured, a format for scanf() and that's
it. From my experience there are just a few minor differences between
reading info about tcp/udp and unix sockets.

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

yep, btw, who are ready to go deeper with new init ? :) I suppose I can
start, but it will be waste of my spare time if nobody is interested.

> 
> Franta
> 
> 

-- 
Alexander Vdolainen,
Evil contractor.

signature.asc
Description: OpenPGP digital signature