> On 20 Oct 2018, at 12:55, Steve Litt <sl...@troubleshooters.com> 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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
