What events? Can you link? Fannys
Oct 14, 2019, 23:32 by a...@vapaa.xyz: > > > 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. >
