Re: possible s6-rc redesign (was: [request for review] Port of s6 documentation to mdoc(7))
On Tue, 01 Sep 2020 10:00:22 + "Laurent Bercot" 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 order (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
possible s6-rc redesign (was: [request for review] Port of s6 documentation to mdoc(7))
I have only seen one new feature committed to the Git repository so far. Is it too early to ask what are you planning to change? The new feature is orthogonal - or, rather, it will be used if I end up *not* redesigning s6-rc. The trend with distributions is to make service managers reactive to external events: typically NetworkManager and systemd-networkd because the network is the primary source of dynamic events, but even local events such as the ones produced by a device manager, or basically anything sent by the kernel on the netlink, are getting integrated into that model. s6-rc is, by essence, static: the set of services is known in advance, and there is no reacting to external events - there is only the admin starting and stopping services. This has advantages - a compile-time analysis is possible, with early cycle detection, etc.; but the model doesn't integrate well with modern distro needs. So, I've been thinking about ways to add dynamic event management to s6-rc; and I've found two options. Option 1 is to add dynamic event management *on top of* s6-rc. That is my natural instinct; that is what I've always done with software, that's what keeps the various parts of my software as clean and simple as possible. Here, it would mean: - having a classic s6-rc database for "static" services - having an additional "dynamic" database for services that can be triggered by external events. (The database is static in essence, but I call it "dynamic" because it would host the services that can be started dynamically.) - having a s6-rc-eventd daemon listening to events and executing s6-rc commands on the dynamic database depending on the events it receives. Paired with a s6-rc-event program that sends events to s6-rc-eventd, meant to be invoked in situations such as udevd/mdevd rules, a netlink listener, etc. This model works in my head, the s6-rc-event[d] programs would be quite simple to write, it would solve the problem in a modular way just like the skarnet.org usual, so it seems like a no-brainer. Except for one thing: I don't think anybody would use this. Only me, you, and the other 6 hardcore people in the world who actually like this kind of design. If there's one thing that has been made painfully obvious to me these past few years, it is that most people, and especially most *distro* people - which are the ones I would like to reach -, perceive the s6 stack as very complex. They're intimidated by it; they find the abundance of moving parts off-putting and difficult to get into. With very few exceptions, the people who actually take the plunge and make the time and energy investment necessary to understand the model, what the various parts do and how they fit together, those people all love it, and are very enthusiastic about it, and they're what keeps me going. But the initial barrier of potential, the ultra-steep learning curve, is indisputably the limiting factor in the spread of the s6 ecosystem. 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. 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. 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?" People understand the benefit in separating mechanism from policy, in theory, but in practice nobody wants to write policy. (Can't blame them: I find it super boring, too.) Having the tool is not enough; it needs to be gift-wrapped as well, it needs to be nice to use. If I add a s6-rc-event family of binaries to s6-rc, the fact that it is yet another layer of functionality, that you now need *two* databases, etc., will make a whole additional category of people just give up. The outreach will be, mark my words, *zero*. If not negative. The fact is that a full-featured init system *is* a complex beast, and the s6 stack does nothing more than is strictly needed, but it exposes all the tools, all the entrails, all the workings of the system, and that is a lot for non-specialists to handle. Integrated init systems, such as systemd, are significantly *more* complex than the s6 stack, but they do a better job of *hiding* the complexity, and presenting a relatively simple interface. That is why, despite being technically inferior (on numerous metrics: bugs, length of code paths, resource consumption, actual
