Re: systemd replacement or standardization

[marinus.savoritias]

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