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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
