> On 20 Oct 2018, at 12:55, Steve Litt <slitt@???> wrote:
>
> 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
Hear hear!
How much work is involved in making this happen? I’m happy to lend a helping hand in a testing capacity, with my spare time and hardware.
—Tom
::
Re: [DNG] Stop the madness!
