Hi Steve,

Nice write-up, thanks!

A couple of observations about sysvinit from me - I never paid it much
attention in the past and have been using runit similiarly since early
Devuan - however it may be interesting to note how things are faring
now with sysvinit:

On Sun, Aug 24, 2025 at 07:34:06PM -0400, Steve Litt wrote:
> First thing first: sysvinit is *much* better than systemd, so as I
> proceed to enumerate problems with sysvinit, please keep that in mind.
>
> Sysvinit has huge init scripts that a mere mortal, or even a "power
> user" can't deal with. Like 50-250 lines, each of which incorporates by
> inclusion a shellscript with hundreds of lines. Meanwhile, runit uses a
> "run script" for the same purpose, and run scripts are usually less
> than 10 lines and are easy to understand. Sometimes runit also has a
> "finish script" when certain things must happen when the service is
> shut down.

sysvinit scripts not only started out large, they grew every time a
maintainer tweaked anything and never got pruned back!

With init-d-script(5) you can take an initscript discarded by a Debian
maintainer, condense it into 5 environment variable definitions and
shove it back again!

It's cheating of course (calling into helper functions, or in this case
an inverted version of the same) but if more people knew it could be
done much more simply then perhaps we wouldn't face such a struggle to
stop them being thrown out!

> Sysvinit run scripts use difficult to understand "meaningful comments"
> to determine some elements of run order and dependency. Get these
> "meaningful comments" wrong and stuff goes really wrong. Meaningful
> comments are a kludge, whether for sysvinit, FreePascal, or uv config
> files. Runit has no "meaningful comments".
>
> Sysvinit's main method of dependency handling is to demand that the
> process being instantiated be in the foreground while setting itself
> up, and then background itself (doublefork) when the process is
> considered (by the author of the process) to be up and ready to handle
> things. M I C, K E Y, M O U S E . So sysvinit must depend on PID files,
> which can get ugly. Plus, making your own daemon requires adding
> doubleforking, not for the faint of heart. Meanwhile, runit supervises
> processes it runs in the foreground. Runit handles its dependency
> handling by running a test to see if the daemon actually does what it's
> supposed to do. For instance:

start-stop-daemon(8) can sort out daemonising and PID file handling. It
can even support systemd-style NOTIFY synchronisation (which I think is
a good feature).

> ===========================================================
> if ping 8.8.8.8; then
> exec my_network_application
> else
> exit 1
> ===========================================================
>
> I might have gotten the above a little wrong, but you get the picture.
> Runit keeps trying to run my_network_application every few seconds
> until the network comes up.
>
> Minor benefit of runit: Parallel instantiation. Under certain
> circumstances this can make boot happen a little faster.
>
> Minor benefit of sysvinit: Lacking parallel instantiation, sysvinit is
> more certain to run daemons in a specific order. However, in my 10
> years of using runit, runits indeterminate run order has never created
> a problem as long as I put dependency checking in run scripts. I was
> surprised at first that runits indeterminate run order didn't cause
> intermittent problems, but in real life, it just doesn't.

I think sysvinit does parallel booting on Debian now, if I've understood
correctly. I think I've even noticed the resultant indeterminism,
altough it's not been a problem.

However, I have seen concrete problems with runit's indeterminancy -
it's been the cause of some bugs in Debian. Mind you, these tend to boil
down to inadequately expressed dependency/polling. So with more users
we'd shake these out quicker.

> NOTE: If you don't want parallel instantiation but don't want messy
> sysvinit init scripts, you can init with Epoch, which in my experiments
> from 2014 inits pretty darn fast.
>
> One more note: You can use sysvinit's PID1 with runit's superior
> process supervisor by running runsvdir from /etc/inittab. This is an
> excellent way to get all the runit benefits without the hassle of
> switching your PID1 and your grub config.

Agreed. I do this on my main sysvinit desktop. You can install the
'runit-run' package and it will set itself up. I've also done similarly
for DIY personal user services, even under systemd (why? because it
makes me happier).