NO TO SYSVINIT - or initscripts, rather!

Cgroups were created to aggregate groups of processes for control/ management purposes. It's not particularly brilliant when something which is intentionally not portable beyond Linux uses them for this exact purpose, especially considering that there were even technical precedents in userspace: The lxc version I originally used in 2010 was 0.7.3 and it had been in development for some years at that time already. There's also an intentional design choice here: Cgroups are used to solve the problem of controlling misbehaving or intentionally hostile other processes, ie, programs written such that they cannot be managed with traditional UNIX facilities built around the notion of cooperating processes. I doubt this was ever a design objective for daemontools. It's certainly not a problem I have encountered in practice so far (my efforts in this respect being strictly restricted to providing process management facilities I demonstrably need).

Socket activation with the intent to reduce system boot time and provide better overall system performance saw the light of the day with the 4.3BSD inetd.

Fully asynchronous, that is, event-driven servers have also existed for a long time. Dan Kegel's original C10K paper mentioned the concept. The (older) racoon IKEv1 daemon also works in this way. This is again a design choice: Manage more than one process with the same process management process and accomodate buggy or intentionally hostile "other software". One could argue that buggy other software should rather be fixed and that one shouldn't be using intentionally hostile one.

The sysvinit program actually supports (some very limited form) of process management: It's possible to define per-runlevel commands which will be started automatically whenever a runlevel is entered and restarted if they ever terminate. Traditionally, this is unused except for gettys (to support user logins on all kinds of text terminals, virtual, physical, serial console etc). But the initscripts/ runlevel management system is completely independent of that: All init knows about this is that it's supposed to execute the command /etc/init.d/rc with the runlevel number as argument (both configurable). This means it's possible to use the sysinit program (or any other kind of "init init" which restricts itself to this role) together with any other process management program/ tool. Eg, the one I'm using is just a command which is executed during service start. Basically, it will execute another command with certain arguments in a subprocess. Should this other command terminate, it will be respawned. Further, the command creates an AF_UNIX stream socket for external process control. This can be used to query the status of the managed command, to initiate a stop or restart and to send abitrary signals to it.

If the process serving as init ever terminates, the kernel will panic. But ordinarily, death of a parent process doesn't affect its children. They'll be inherited by the init process which will eventually collect their exit status to prevent them from turning into zombies. Otherwise, backgrounding a program by forking and terminating the parent process wouldn't be possible.

"The problem here is that SysV (and its ilk) doesn't really have a parent that can be used to manage its children. For this to work you need a specialized persistent process that stays up at all time, because if it dies all of its children will also be killed."

I'll put forth that sysvinit *is* the parent that manages its children. It simply has never been used that way. Instead, the old method of using RC scripts (did this come fom Berzerkely?) was used (or continued). The very useful part of sysvinit (most of what's in inittab) was relegated to the status of a curious-looking red-headed stepchild useful only for running getty.

If sysvinit was extended to, say, 128 run levels to handle dependencies, actually used as intended, and possibly extended to facilitate enabling/disabling/activating/deactivating daemons without needing to edit inittab, sysvinit would do everything a lot of people need without a lot of complexity.

To avoid using cgroups! This has two major benefits. First, if I want to save resources, I can run on a kernel without cgroups. Second, and more importantly, it would let me use systemd without using systemd as a cgroup controller, which would mean that I could arrange other cgroup policies that have nothing to do with systemd.

> You conveniently neglected to quote an important part of my sentence, namely

[...]

I've ignored that on purpose because while I'm somewhat interested in discussing the technology, I have zero interest to engage in a discussion of the surrounding politics and other social mechanics as that's bound to degrade into an entirely pointless flamewar of a very familiar shape quickly.

$ size /usr/lib/systemd/systemd
   text	   data	    bss	    dec	    hex	filename
1238373	 259368	    416	1498157	 16dc2d	/usr/lib/systemd/systemd