Re: Can s6 be enough?: was s6-ps
When Debian acquires a properly working s6-rc package, the answer to my question degenerates to "why not?" But for now, for the Debian person who only installs via package, s6-rc is out of the question, so my question was, isn't s6 itself good enough? Then maybe you should ask Debian instead, "why aren't you packaging s6-rc?" It's literally a distribution's *job* to package software that may be useful to users. And instead, you are bending your mind to try and find justifications for users not to use some software, for the simple reason that it's not packaged by a distribution. That logic is 100% backwards. You want to help users? Package s6-rc for Debian. Also, call out Debian on their prejudice and disingenuous use of policies that prevent people from making correct execline and s6 packages. -- Laurent
Re: Can s6 be enough?: was s6-ps
On Sat, Jan 5, 2019 at 2:30 PM Steve Litt wrote: > So what do you all think? Is s6 a useful init system without s6-rc? > My 0.02 USD -- based on my experience of setting up a simple GNU/Linux distribution from the ground up using s6, s6-rc, and s6-linux-init... - s6-rc provides useful functionality: it is really handy, when defining the way that the system should start up, to have bundles and oneshots; it is also really handy to be able to start up or shut down groups of processes via bundles. - The cost of using s6-rc is negligible. As installed on my x86_64 system with documentation, it consumes around 576 *kilobytes* of storage space. It compiles and installs in substantially less than a minute. Learning how to craft s6-rc service definition directories is no more difficult than learning how to craft s6 servicedirs. - You don't lose any capability provided by s6 if you also use s6-rc. You can send whatever signals you want to the supervised processes by using s6-svc directly. So ... costs ~= 0, benefits > 0, to me the question of whether s6 is useful _without_ s6-rc is kind of pointless. I'm inclined to turn the question around: what leads you to want to avoid s6-rc? Is there some other system that provides more benefits at lower cost? Cheers! Brett -- Brett Neumeier (bneume...@gmail.com)
Re: Can s6 be enough?: was s6-ps
Eliminate dependency on udevd from oneshot startup scripts. One example among others: Kernel events are used to automatically load dynamic kernel modules. Say you need to mount a filesystem of a type that's not known in your core kernel, but you have a module for that. Either you manually modprobe everything in your initial oneshots (which is possible, but less flexible and more painful), or you just spawn udevd first and can then mount everything you need. The latter is clearly the intended use case - that's what automatic module loading is for. But you can only do that by making oneshots depend on the udevd longrun. Don't organize your system around the tools you have. You shouldn't have to jump through hoops to accommodate mediocre tools/architecture or distributor laziness; it's a losing game in the end, and the user is the one who loses. Instead, get the tools you need so your system works as painlessly as possible for the user. In some cases, you won't need a service manager; in most cases, you will. -- Laurent
Re: Can s6 be enough?: was s6-ps
Everybody appreciates the preceding two features, but personally, I don't think they're absolutely necessary. Runit has neither, yet it works just fine for most things. It really depends on what "most things" are. Small, server-only appliances? sure. Distributions where you can start all the oneshots first and all the longruns later? sure, but there aren't many of those. Typically udevd is a daemon you want to bring up very early, before some oneshots; so in the runit model, what do you do with udevd? Void Linux, which uses runit as its init system, has an answer to that: it doesn't supervise udevd. Don't you think that's ugly? Because I think that's ugly. So I'm thinking that although process ordering and intermixing are features we'd everyone likes, all but the most discerning among us could get along without them and therefore init with s6 alone. Well yes. You can even get along with no supervision at all. Most people got along with sysvinit and sysv-rc just fine. The question is, do you want to? What do you expect from your init system? what functionality do you want to have, what functionality do you want your distribution to provide? My opinion is one can boot just fine with s6 alone, as long as you're willing to forego startup ordering and intermixing of longruns and oneshots, which by definition a runit fan is. Yes, it can be done. As a matter of fact, it's completely trivial to take a Void Linux distribution and replace runit with s6. It works flawlessly. It just hasn't been done in the official Void distribution yet because the Void maintainers have other priorities, and runit works well enough for them. s6-rc and anopa exist for the people who are *not* willing to forego intermixing of longruns and oneshots. It all depends on what your priorities are, of what the aim of your distribution is. So what do you all think? Is s6 a useful init system without s6-rc? Terminology, please! s6 isn't an init system per se. It's a process supervision system; and s6-rc is a service manager, aka machine state manager. Those are _components_ of an init system. You can build a complete, full-featured init system with s6 and s6-rc. You can also build an init system with s6 alone (and some scripting as s6-linux-init does), but it won't include a service manager. It's your call, really: I provide the mechanisms, distributions provide the policy. When they don't utterly give up on their duties, obviously. If you haven't watched it yet, please take a look at this video: https://archive.fosdem.org/2017/schedule/event/s6_supervision/ It's only 15 minutes long and explains all the terminology. -- Laurent
Can s6 be enough?: was s6-ps
On Sat, 5 Jan 2019 10:46:29 + Jonathan de Boyne Pollard wrote: > s6 and s6-rc are actually ports/packages in FreeBSD and s6 is a > package in Debian. Alas, the Debian world has not yet caught up with > the other toolsets, and the third-party Debian packaging for > s6-linux-utils and the others has yet to make it into Debian's own > repository. This brings up a question I've had for a long time. Three years ago I constructed an init consisting of Suckless Init as PID1 and s6 as the supervisor, which was called at the end of a simple rc file forked by Suckless Init. It worked just fine, without s6-rc or any other s6 products. From discussions with Laurent I got the idea that the main added functionalities of s6-rc are: 1) Process ordering during boot 2) Ability to intermix longruns with oneshots Everybody appreciates the preceding two features, but personally, I don't think they're absolutely necessary. Runit has neither, yet it works just fine for most things. When I first switched to runit, with its indeterminate ordering, I figured that with the dependencies I built into the run scripts, boot would resemble a field of mousetraps throwing ping pong balls. But that wasn't the case: runit brought everything up quickly and without trouble. So I'm thinking that although process ordering and intermixing are features we'd everyone likes, all but the most discerning among us could get along without them and therefore init with s6 alone. This is more than theoretical. As you remember, Debian's runit package manager wrote to ask about a minor problem with too many .u files and was contemplating changing some code, but nobody knew the code intimately, and runit is pretty much unmaintained at this point. So I suggested s6, which apparently has a Debian package but not one for s6-rc. My opinion is one can boot just fine with s6 alone, as long as you're willing to forego startup ordering and intermixing of longruns and oneshots, which by definition a runit fan is. So what do you all think? Is s6 a useful init system without s6-rc? Thanks, SteveT Steve Litt January 2019 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust
