[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: systemd replacement or standardization
From: |
marinus.savoritias |
Subject: |
Re: systemd replacement or standardization |
Date: |
Tue, 15 Oct 2019 20:42:12 +0200 (CEST) |
Sorry about that. DIdn't notice it is corrected now.
Okay. Sounds fair for the Systemd position.
Fannys
Oct 15, 2019, 20:01 by address@hidden:
> 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.
>
- Re: systemd replacement or standardization, (continued)
- Re: systemd replacement or standardization, marinus.savoritias, 2019/10/14
- Re: systemd replacement or standardization, Alexander Vdolainen, 2019/10/14
- Re: systemd replacement or standardization, marinus.savoritias, 2019/10/14
- Re: systemd replacement or standardization, Alexander Vdolainen, 2019/10/15
- (html emails) Re: systemd replacement or standardization, Jean Louis, 2019/10/15
- Re: (html emails) Re: systemd replacement or standardization, Alfred M. Szmidt, 2019/10/15
- Re: (html emails) Re: systemd replacement or standardization, Jean Louis, 2019/10/16
- Re: (html emails) Re: systemd replacement or standardization, Alfred M. Szmidt, 2019/10/16
- Re: (html emails) Re: systemd replacement or standardization, Jean Louis, 2019/10/16
- Re: (html emails) Re: systemd replacement or standardization, Jean Louis, 2019/10/16
- Re: systemd replacement or standardization,
marinus.savoritias <=
Re: systemd replacement or standardization, marinus.savoritias, 2019/10/14
- Re: systemd replacement or standardization, Alexander Vdolainen, 2019/10/14
- Re: systemd replacement or standardization, Ricardo Wurmus, 2019/10/15
- Re: systemd replacement or standardization, marinus.savoritias, 2019/10/15
- Re: systemd replacement or standardization, Jean Louis, 2019/10/15
- Re: systemd replacement or standardization, marinus.savoritias, 2019/10/15
- Re: systemd replacement or standardization, Jean Louis, 2019/10/15
- Re: systemd replacement or standardization, marinus.savoritias, 2019/10/15
- Re: systemd replacement or standardization, Richard Stallman, 2019/10/21
- Re: systemd replacement or standardization, Richard Stallman, 2019/10/21