Peter Duffy said on Fri, 19 Nov 2021 11:29:32 +0000

>I've recently been asked to recommend an upgrade route for a number of
>linux servers, and I proposed going to devuan. In response, I've had a
>concern raised which took me by surprise. It was suggested that in the
>future, it may not be possible to find staff who have the skills to
>administer and manage servers running non-systemd or pre-systemd
>distros/releases.

<rant>I'm now extremely angry</rant>

<advice>
Sounds like a documentation problem to me. A fairly short document on
how to use runit, how to install a new daemon using runit, and sample
runit run scripts for various daemons, many of which can be found at
http://smarden.org/runit/runscripts.html .

Because runit is so dead bang simple, it might be easier for a systemd
trained admin than systemd itself. I recommend you put together a short
dog-and-pony show demonstration of adding and controlling daemons via
runit. Include a 10 minute Python program, that doesn't background
itself, used as a runit-supervised daemon. Even though systemd can do
this too, they won't know that, and they'll oooh and ahhh about runit.

I'd stick to runit. All the things Lennart said about Sysvinit are
true: Its only plus is that it's still better than systemd. OpenRC
takes too much expertise. Although once upon a time s6 and runit were
very close cousins, to go after the systemd market the, s6 has been
grandly complexified. I mean, if one REALLY needs the features of
systemd, s6 is a great init system. But in your case simplicity is a
necessity: This points to runit.

GATEWAY DRUGS:
Sysvinit can be a gateway drug to runit. You use PID1 from Sysvinit,
respawn runit's runsvdir from /etc/inittab, add a few of the early
Sysvinit init scripts to get udev running and various devices and
filesystems recognizeable, and you're off to the races. Later on you can
implement the PID1 and early boot parts of runit.

Runit can be used as a gateway drug to s6. The supervision parts of the
two are almost identical in function, although they use different
command names. They're like Italian and Spanish: If you know one you
can understand the other. If you really need ordered daemon startup, or
"socket activation", or the daemon phoning home saying it's up (which
can be done quite easily in runit with simple tests), s6 is the
Cadillac of the industry.

Another variable is how gnarly these servers are. If they just offer a
few servers, runit's trivial. If they run 40 servers/daemons, or if
they have lots of complicated VM guests or containers needing quick
bootup, I'm not sure.

Also, obviously, if the customer insists on Gnome or other software
that checks for a systemd PID1 before working, well, they're idiots but
you can't address the situation with runit.

One more thing: You could write a run script creator that would query
the admin for facts about the daemon, and then write the run script.
Something like this:

Command to start the daemon in foreground with correct functionality=>

Directory containing the daemon=>

Environment variables necessary for the daemon=>

Does the daemon require logging (N/y)=>

Command to test for process dependency functionality=>

Command to test for process dependency functionality=>

Command to test for process dependency functionality=>

=====

You'll need one or more test for each process dependency: Keep querying
until the admin says "end of dependencies". Most run scripts will have
no dependencies. So most of your big, bad run scripts can be created in
5 minutes. Including run scripts for in-house daemons.
</advice>


SteveT

Steve Litt
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques