This is (yet another) init daemon, initially based on sinit.
rund merges the best of 2 init approaches. rund itself is an init daemon that only supervises services. The boot process is offloaded to an external bootscript. This bootscript or any other process can ask rund to run+supervise processes. The configuration of the boot process is reduced to shell script, or any other program of your choice. Yet, complex constructs for service selection remain possible.
Spawning services in parallel during boot is easily done with backgrounding parts of the script, a technique that existed for years.
sinit1 restricts itself to reaping children, and spawning an init & shutdown script. I liked the idea putting startup & shutdown in a simple shell script very much. By the way, it may be a binary as well.
The problem that rund tries to solve is that the init script may spawn services, like sshd, httpd, ..., but noone will restart the service if it fails.
How?
rund opens an anonymous unix datagram socket. Adding restartable services is done via the runcl companion tool.
Does restarting services belong to init's job?
System startup becomes simpler if I make it so. That's why.
Hum, why exactly?
The service supervisor is the trivial candidate for servicing the system watchdogs, if any (rund does support multiple watchdogs). If init is not the supervisor, then init is not covered by a watchdog. Is init moinitored then?
On systems without watchdog, the problem also exists, but does not require a solution...
How would the system react if init stalled, and everything else runs fine?
There is not universal good answer to the above questions, and that is the argument against a seperate supervisor. A system without the supervisor being init is one without a supervisor at all. Use sinit in that case.
Why is this better?
System startup is, as with sinit, offloaded to a script, and is thus not predefined inside the init program.
rund is not statically configured. The lack of config files imply that they should never be reloaded. Have you ever tried modifying the behaviour of init on a readonly rootfs? With rund, the operator is in charge, and may choose to remove a service, add another service, without the need for configuration written to the rootfs.
Dependancy based services require a big deal of knowledge, both from
the dependancy-based tool and from the administrator.
I found dependencies on service level of little use since
you must propagate dependencies properly to inside the service itself anyway.
Not doing so may cause unexpected results, and having a dependancy based
init system only postpones the discovery of such problem until an inconvenient
point in time.
Most services however will fail anyway when some required service
drops out, and will consequently drop out too.
In short, dependency based booting is nice as theory.
Special operations like service pre-exec, service post-exec, ... can better be accomplished by an wrapper program that deals with those cases. the pre-exec & post-exec concepts do not belong the init system since those belong inside the entity that we describe as service. This relieves the init daemon from handling zillion scenarios.
Parallelism, which is minimal during early startup, is achieved by running commands in the shells background. The early system startup, which is the most error-prone with almost no parallelism, becomes as easy as shell script.
Since rund doesn't do much standalone, and services can be added in runtime, minimal user protection is necessary to protect against malicious users. rund takes advantage of the uid/gid/pid checks that linux can do when using OOB data on unix sockets. This is really the simplest way. rund does not, as pid 1, do user or group lookups. This is by design, to not add enormous .so files into pid1. name-to-id translations are performed by the client, rund accepts only id's on its protocol.
Since rund must actively protect against user ids, it does deliver it's run service to regular (non-root) users too. It does however execute such services as the requesting users, i.e. regular users cannot ask rund to run services with a different uid.
This means that running a service becomes available to regular users. This implies less sudo abuse.
How is the system started then?
I add a bare version of my scripts in examples/
Is it fast?
The systems I migrated to rund did boot equally fast as busybox init (not using scripts, completely configured in /etc/inittab), and minimally faster than systemd (systemd fails on loading+reading configuration).