On Tue, 01 Sep 2020 10:00:22 +0000 "Laurent Bercot" <ska-supervis...@skarnet.org> wrote:
> s6 as a supervision suite? okay, people will use it; but it's > already perceived as a bit complex, because there are a lot of > binaries. It's on the high end of the acceptable difficulty range. I've only used s6 as a supervisor a few times, but my memory tells me it had pretty much the same binaries (named differently) as runit, and was no more complicated than runit. I use runit every day. > s6 as an init system? "what is this s6-linux-init thing? why do I > need this? runit is simpler, I'll stick to runit." Even though runit > has problems, has less functionality, and is barely maintained. There > are, for instance, several people in Void Linux who are interested in > switching to s6, but despite s6 being an almost drop-in replacement > for runit, the switch has not been made, because it requires learning > s6 and s6-linux-init, and most Void people do not feel the effort is > worth it. Perhaps a baby step would be to use sysvinit ONLY to act as PID1, which if I understand things sysvinit is pretty good at, and have /etc/inittab or whatever it's called simply respawn the s6 supervisor. Given that most current distros that aren't blissfully wed to systemd have an option for sysvinit, this would work. I think the same thing could be done with OpenRC, but it would be a little more complicated. Obviously, there would need to be something that temporarily shuts off sysvinit's daemon runner so that they can install the whole sysvinit package and not have double-daemons. I recommend a kludge for that: Do the kludge when installing s6 supervisor, undo the kludge when uninstalling s6 supervisor. I'm aware that the preceding baby step doesn't get us to the point of s6 as PID1, but if it gets us to the point where lots of people are using the supervisor and those people get used to it, they'll demand s6 as PID1. I think I'm going to, very slowly, little by little, move my daemons on my Void Linux Daily Driver Desktop (DDD) to s6. As I move each, I'll put a down file in the runit directory (or just unlink it). I'll report back to you in a month. > > s6-rc? "waah I don't like the source directory format, I want text > files, and why is it so different from 'service foo start'? And why > doesn't it come with integrated policy like OpenRC or systemd?" What is "integrated policy?" [snip] > > So, I think my software design needs to be rebalanced, and > complexity needs to be spread more evenly. I'm certainly not going to > write monoprocess behemoths, that's not what I do, but I need to stop > yolo adding small binaries to address some functionality and say > "there you go, here's the mechanism, how to use it is left as an > exercise to the reader." Which is exactly what would happen with > s6-rc-eventd. > > So, option 2 is to take a step back and say: a service manager is > one (complex) functionality, and if I want a full-fledged service > manager, I need to design it as such from the beginning, instead of > having a static service manager with a program to handle dynamic > stuff added next to it as an afterthought and the complexity needing > to be managed by users or by s6-frontend. > And that means a s6-rc redesign. > > I haven't made a decision yet: I'm in the process of *exploring* > what a s6-rc redesign would look like. But so far, this is what I > think a full service manager should do: > > - Be similar in concept to Upstart. The Upstart implementation is > bad, but the fundational ideas are actually quite good. [snip a lot of complicated stuff] If you get as complicated as you wrote, runit will forever eclipse s6 because of the huge contrast in complexity. It doesn't have to be that way. If I correctly understand your previous writings, the ideal init would be to have PID1 be a mini-supervisor that supervises only the real s6 supervisor. I think you had that complete years ago. Then you needed to, upon bootup, start daemons in a specific order, hence the first need for s6-rc. However, this could easily be handled on a numerical sort order basis with a file in the daemon directory called order1234 or order1235 or order9999 (no doubt for the equivalent of rc.local). Daemon directories with no order file could default to order5000. I've never had a problem with the fact that runit has no bootup ordering and is indeterminate, and the couple times I constructed systems experimentally with suckless-init as PID1 and s6 supervisor, same thing: Everything worked despite the indeterminance. So defaulting the majority or even all to order5000 almost certainly won't cause problems. Numerical sorting is much easier for everyone, but if dependency based sorting is needed, it can be done with a provides/requires system. Given that tests can be done within a run script I think this is unnecessary, and adds to complexity, but it's doable. Later, a need to randomly mix supervised and run-once processes was expressed. In my opinion, this is a grievous omission from daemontools, and I'm glad it's being done (I think via s6-rc). But wouldn't it be easier just to have either a runonce or run program in the daemon directory, depending on whether it should be a one-shot or supervised? I'm pretty sure this would be easy to implement. I'd imagine runonce just forks, leaves a marker file to show it's been done, and forgets. The marker files are deleted on initial startup. If I'm understanding today's email correctly, and I'm not sure I am, is that you want s6 or some components thereof to react to requests from programs like networkmanager and events like plugging in a USB. For the usb plugins and plugouts, and network ups and down, dmesg -WT -- on Linux and its equivalent on BSD does the job (requires an #ifdef). As far as NetworkManager, either NetworkManager needs to notify the proper daemon, (not likely from the FreeDesktop/Redhat/Poettering coalition), or s6 needs a daemon to play each Freedesktop inspired program's game, probably by listening in on dbus. I hope to hell such a daemon will be completely separated from the other s6 components, because it will doubtlessly need to change as FreeDesktop gets "new and better" ideas, because dbus adds huge complexity to anything, and because many people may not wish to deploy dbus-connected software. To summarize, I think everything desired can be added, modularly, with little increase in complexity, and I think it can be part of a package manager package. SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive
