Some folks are asking for automatic sysvinit init script generation, or
else unit file to sysvinit init script converters. Some are asking
Devuan's developers to prioritize their scarce programmer resources to
modifying sysvinit, which is over 30 years old. Yet others think we
should reimplement all the systemd functions in the Unix paradigm.

Stop the madness!

Systemd units are config files, like Win98 had, with one level of
groups designated by square brackets, and a lower level of key value
pairs with equal signs between key and value. In other words, a
collection of pushbuttons and dials that you can choose from, and a
rather large collection because, with the config file, you can no
longer go offroad and do something special with a shellscript.

Think config files are simple? Well, look at the large collection of
potentially conflicting and/or ambiguous systemd pushbuttons and dials:

https://www.digitalocean.com/community/tutorials/understanding-systemd-units-and-unit-files

And, of course, pushbuttons and dials by their very nature are
limiting, so there will be more and more in the future to cover corner
cases. Or the redhat funded project will eventually add a few places
where you can put very restricted scripts to go where the dials and
buttons can't.

Some Devuaners will say "but wait, bad as that is, it's still better
than modern init scripts." Those who say that have drunk Lennart's
flavored drink and embraced the sysvinit/systemd false choice.

Runit uses shellscripts, embraces them heartily, and yet
hardly a runit run script exceeds ten lines. Take a good look at this
collection of runit run scripts, straight from runit's developer:

http://smarden.org/runit/runscripts.htm

Runit run scripts can do anything unit files can do, and more. Usually
in under 10 lines. A couple months ago a snotty systemd fanboy chided
me that runit couldn't start several processes at once. Oh yeah?

http://smarden.org/runit/faq.html#depends

And if you want the stopping of one service to stop others, that
can be done too, via the finish script, which has knowledge of its
supervised daemon's exit code.

I recently upgraded my unbound run script to start a shellscript to
pre-load common domains into its cache:

=======================================================
#!/bin/sh
if ping -4 -c1 8.8.8.8 > /dev/null; then
        (/etc/unbound/primecache.sh &) 
        exec unbound -dp
else
        sleep 1
fi
=======================================================

Let's review the preceding. A functioning network is required, hence
the ping command. If the network is functioning, the primecache.sh
program is run in the background, and then immediately this
shellscript's process becomes the unbound executable. The primecache.sh
program starts with a 2 second sleep, so there's no reasonable
possiblity of a race condition where cache starts priming before
unbound is run, unless there's something unusually wrong with unbound.

If no network, it sleeps a second and tries again. It would take only a
few more lines of code to count to 10 tries and then sending a message
and preventing further tries, but I personally think this would be
overkill.

Lennart pats himself on the back for his parallel instantiation. Notice
how I allowed primecache.sh to run, in the background, while other boot
activities were done. But wait, there's more. Runit goes around in a
circle, creating 1 daemon supervisors, without stopping to wait if
those 1 daemon supervisors succeed. In parallel, those 1 daemon
supervisors each start their daemon, whether it takes 0.1 seconds or 30
seconds.

IN OTHER WORDS...

If you're happy with sysvinit, that's fine. But if sysvinit no longer
suits your use case, or you're afraid it will no longer work with
systemd apps and daemons, then don't try to massively bring up to date
the 30 year old jalopy from the days of Devo and Pat Banatar and
distributors and carburetors, instead switch to something that already
accommodates your needs: Runit (or s6).

And don't forget, until Devuan Devs get around to making the runit
package a genuine PID1, you can, right now, today, run runit on top of
sysvinit, and one by one switch services from /etc/rc.d/init.d scripts
to runit run scripts, by shutting off the service on the sysvinit end,
and downloading or making a runit run script and then making one
symlink.

A lot of run scripts are available at
http://smarden.org/runit/runscripts.htm . I will be curating a
collection of more runit run scripts in the near future.

In other words, unless you view sysvinit as an antique to be kept
around for sentimental value, don't put any work into it. Drive it
while it fits your needs, then call the tow truck to tow it away and
get your brand new runit supervisor.

SteveT

Steve Litt
September 2018 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz