altoid via Dng said on Sun, 24 Aug 2025 11:44:53 -0300

>Hello:
>
>On 23 Aug 2025 at 12:46, disparage.solvency678@??? wrote:
>
>> ... switch an existing daedalus system from sysvinit to runit ...
>Please excuse my ignorance in this specific matter ie: init software
>but I have a question:
>
>Why?
>
>Meaning: what convenience/s | advantage/s does [runit] offer your
>system (which you do not specify as a desktop or server) with respect
>to [sysvinit]?

As a guy who used sysvinit 1998-2015 and runit 2015-present, I'm
probably the ideal person to answer this question.

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 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:

===========================================================
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.

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.

The following URL contains my 2014-2015 contemporaneous writings in my
search for a non-systemd, non-sysvinit init system:

https://troubleshooters.com/linux/init/manjaro_experiments.htm

HTH,

SteveT

Steve Litt

http://444domains.com