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