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