Re: systemd replacement or standardization

[Alexander Vdolainen]

On 10/15/19 12:12 AM, address@hidden wrote:
> Hi,
> 
> Pardon for my ignorance but why not GNU Shepherd which is already
> developed to be the GNU init system and process supervisor? It is
> already used by GUIX.

The problem with it are follow:
 - there are no clear specification to work with
 - I'd love to use scheme language (GNU Guile), but it's not always
possible (embedded as example)
 - according to the last events I need to accept some political views I
wouldn't to

btw, init system used in guix is very nice from my point of view.

> 
> Fannys
> 
> 
> Oct 14, 2019, 23:03 by address@hidden:
> 
> 
> 
>     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.
> 
> 

-- 
Alexander Vdolainen,
Evil contractor.

signature.asc
Description: OpenPGP digital signature