On 10/15/19 12:12 AM, marinus.savorit...@tuta.io 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 a...@vapaa.xyz: > > > > 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
