Ron / BCLUG via talk said on Fri, 1 Nov 2024 03:47:11 -0700
Sarcasm aside, services management *IS* a complex task.
No it's not. I could teach anybody to do services management, using runit, in two hours. This includes process dependencies, start, stop, restart, temporarily disable, permanently disable, status, etc. Runit doesn't have stuff like systemd-analyze because stuff seldom takes a long time to come up, and runit has a complete logging system if something takes way too long and it isn't obvious which something. Just like systemd, runit has parallel instantiation so that if something takes a long time it simply becomes the last thing to come up. This myth that services management is complex comes from the services management part of sysvinit, which I don't like at all. Sysvinit is a big whopping kludge, right down to those stupid comments that determine the order things come up, and the layers of long and arcane shellscripts it used. And all for something that couldn't supervise foreground processes and couldn't do parallel instantiation (except for the inittab part, which nobody ever used). Because sysvinit was so darn hard to learn, people came up with the expectation that service management was complex, and therefore accepted rediculousities like Upstart and OpenRC and the insanity called systemd. Runit has some disadvantages: * All one-shot processes must precede the auto-restart processes. * Process start order is indeterminate. * Each process' supervise directory's various file attributes make troubleshooting difficult. The preceding disadvantages aren't the end of the world because: ONE SHOT VS AUTO-RESTART: In practice this usually isn't a problem. If it is, you can init with s6 plus s6-rc, which enables you to mix one-shot with auto-restart. Be aware that I also made a system, called LITTKIT, to allow such intermixing: https://troubleshooters.com/linux/diy/suckless_init_on_plop.htm INDETERMINATE PROCESS START ORDER: I would have predicted this would be a showstopper. I mean really, it's like a skating rink floor filled with mousetraps that heave golf balls. Fact is, though, in the ten years I've used runit, it's never given me problems. And if it did, I could easily put maybe five lines of process dependency code into a run script. And if I *really* had to have determinate startup, I could use s6 with s6-rc or LITTKIT. But for me, there's no need. THE SUPERVISE DIRECTORY'S ATTRIBUTES: Every time a startup fails, remove the entirety of the supervise directory before trying again. Also, before troubleshooting runit, you should first make sure that the run script itself runs the daemon in the foreground. Once that works, follow the following procedure (as user root), assuming the daemon is sshd on Runit: sv stop sshd rm /var/service/sshd rm -rf /etc/sv/sshd/supervise ln -s /etc/sv/sshd /var/service/sshd svstatus sshd The preceding assumes you keep your run directories below /etc/sv. The svstatus line just checks whether the daemon is running. Sounds like a pain, right? Not a pain at all, just make it into a shellscript. You might want to put 1 second sleeps between each command. In practice, the main time you need to do this is when you've created your own daemon and are creating supervision for it. Everything in this section is also true for s6. SteveT Steve Litt http://444domains.com