context : Runit

init systems 🔼

sysvinit
daemontools @ by D.J.Bernstein (1998)
first to offer flexible process supervision
openrc @
runit @
sinit @
s6 @,slides@
shepherd @
dinit
systemd (not in devuan !!)

Laurent Bercot in his 2017 s6 presentation keeps the 'init' as terminology but broaden it's semantics . So he sais that an init system has four elements :

/sbin/init
pid 1
process supervision
service management

And then he categorizes sysvinit,openrc,Epoch,systemd in that context. So sysvinit has /sbin/init , pid1 , primitive supervision and not included service management that is implemented with third party scripts. Alse he think that most daemontools based systems dont offer all 4 elements of a 'proper' init system.

runlevels 🔼

s6's programmer ehnances the sysvinit runlevel semantics in a way that i find usefull . It says :

The machine state (in s6) is the tuple of all the service states. (eth0 is up or down, sshd is up or down, etc.) The machine state is an extension of runlevels. Runlevels are predefined tuples and you have very few; you should have as many predefined tuples as you like.

Service management semantics 🔼

semantics / my notes 🔼

I'll try to offer a more general view of what i believe are the core semantics of programs like sysvinit,runit,s6 etc. The currently circulating presentations (see links) i think are tied to technical details of past implemantations. Instead i havent study their code , and my views i think has some novel elements disattached of any current system.

It's natural to want to control and coordinate other processes in order to perform wanted work. So for me the most general conceptualization is that of coordinating other processes or coordinating a workflow (that needs more than one processes). Again i dont see a fundamental difference in root doing that or a user doing that.

When we boot a Devuan system dont we expect the kernel to be there always ? The kernel offer constant services to the userspace since userspace by definition cant talk to the hardware. So what is the difference between the kernel and a classic deamon (www server)? We could say that WE supevise the kernel since it starts when we power on our system and end when we power it off.

So in that aspect what matter is the work we want done. Not automatically restarting a deamon.

semantics / workflow-init-systems 🔼

I find 'init system' a word that ties the semantics to a system administration level workflows. What happens when we boot - start - bring up a system from the zerostate (NO process running). But what happens in a multiuser system ? When a user login ? Isnt her/his .bashrc a short of a user-init system . And strangely here we found ourselves to a semantically strange land...

Linux wanted to be a Unix for PCs. On top of that PC-Unix desktops were build (Gnome.KDE etc). Now various parties want our PC to become just a portal to cloud services.

Stranded in this Kitsch computing land where interesect :

oldtime unix mainframe usage
tty era
desktop ibm pc era semantics
modern cloudlords context

ONE Human using her/his machine see layers of workflow coordination at :

system boot (pid 1)
tty user login (.login .bash) ,
desktop sessions (session conf)
accessing comp resources on the internet
by that i highlight the distributed computing semantics

So i hope you see that my wf-init-system aim semantically at least to bring a sane discussion context.

Laurent Bercot started his 2017 s6 presentation by a reference to how init wars happended because no one had a clear vision of the semantics. I claim the when we understand the semantics of a workflow-init-system we could stop , if not wars , at least the ensuing semantics chaos when trying to organize our computational workflows and help us avoid fragmentation of various overlapped init systems.

We could keep it and speak also about a workflow-init system. Which i found a cool addition of mine :-) A wf-init-system is indifferent as concepts to how uses it and when. A typical init-system as sysvinit,runit,s6 etc are wf-init-systems. But an display server (Xlibre) 's session

semantics / process supervisor 🔼

That term (i found it in a couple of presentations) ,'-part of the more general case of a service manager-', that controls only one process and thus doesnt bother with depedencies and complexity that emerges when we have to control a service comprised of many processes.

(from The s6 ecosystem by Laurent Bercot)

A long-lived process (daemon) is supervised when it's spawned by another long-lived process, its supervisor, that outlives it.The supervisor is always the direct parent of the daemon. It can report its death to other processes, respawn it, send it signals, and more.

Well in that context we could says that the kernel is supervised by us (longer lived process!).

I think the linearity of a hierarchical process tree is a poor supervised system.

When a user e.g transfers text from a web browser to his/her text editor s(he) acts as a human supervisor of a certain workflow. S(he) starts the two processes and THEN transfer data. You see the sync part of her/his job ? We do that all the time.

So in the context it's getting more obvious what init,process supervisor etc do. They are efforts to automate parts of a workflow. The wish to sustain that part by resurrection of dead processes seems to me more of a wish that a reality in general. It supposes a digital enviroment where our supervisor has knowledge to handle various errors. So the more complex it gets the better will respond to various cases. But ressurection is not a remedy for all illenesses.

semantics / service management 🔼

A service can contain various processes.

So a service manager : - at boot time starts services - at shutdown terminates services - can handle process depedencies (since a service can contaion many processes)

semantics / service 🔼

- We could say that a 'service' is a 'concept' more narrow than that of a process. - A service is composed of various processes with various interdependences. - So a Service manager is a process that supervise that process group.

IPC 🔼

For a process (manager-coordinator) to manage other processes it must be able to communicate with them. So InterProcessCommunication @ is an essential aspect of ServiceManagement.

Unix Signals,wkp@
Files
Semaphores
Pipes , wkp
Shared Memory
Sockets, wkp@
RPCs, wkp@
Message oriented
D-Bus , wkp@

Unix services (daemons) 🔼

wkp/List of Unix daemons: @

sshd
inetd, wkp@
crond
httpd
lpd
getty
udevd
syslogd

tasks 🔼

start services at system startup. terminate gracefully (respecting each running services semantics)

links 🔼

(2017)The s6 supervision suite. Presentation by Laurent Bercot (skarnet)@
(26/10/2018)On the vagaries of init systems by the programmer of init : @
(2023)A discussion i started in DNG trying ot make emacs a service. As i recall the issue of wanting to have emacs as a servive open up the semantic space of the service management from the classical view of a task to be performed by the sysadmin of a computer system to that of task that maybe a user would want to do. A user could want to setup user services as the emacs in my case. A service that maybe not constantly running by listening to possible requests of other user programs