Re: systemd replacement or standardization

[Alexander Vdolainen]

Hi,

firstly I kindly ask you to send a plain text emails without html.

On 10/15/19 12:36 AM, address@hidden wrote:
> What events? Can you link?

I'm speaking about well known petition to remove RMS from FSF and GNU. I
wouldn't like to repeat my position about that.
But I do *not* want to work with those people(1) and I do *not* want to
accept theirs views in order to be accepted(2). GNU should be neutral
w/o any political shit.

btw, there are another technical points you can find on my previous
message.

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

-- 
Alexander Vdolainen,
Evil contractor.

signature.asc
Description: OpenPGP digital signature