s6 init
Hi,
I just have found the information abou s6 init system, it looks rather cool, like improved `runit`. Why does not void uses it by default? Is there any migration guide or further plans to switch to it? Did anybody tried it (may be outside of void), and how it is?
wbr, basiliscos
Best
Open comment sort options
Best
Top
New
Controversial
Old
Q&A
Comments Section
Switching to just s6 doesn't provide many benefits.
Switching to s6-rc is somewhat complicated, its really not user friendly and a lot more complicated to setup/maintain without knowing the internals, its basically building blocks and everyone has to come up with their own setup which kinda hinders it from being used imho.
https://skarnet.com/projects/service-manager.html
YES. Took me months to build my S6 & S6-rc boot system/scripts. Documentation wasn’t great. Plus, long run scripts had to be written in execline, not bash/sh. I could not convert the LFS bootscript for setting up network interfaces based on config files in
/etc/sysconfig… I had to ask someone who knew execline well to convert it for meIt was painful. System boots up then hangs. No way to check why. Just trial and error until I got all the issues fixed.
I had to check Obarun Linux to see how to start designing the scripts. I still haven’t created scripts to modify the “compiled” boot database without recompiling it… every time I need to add or remove a service from boot.
I loved runit for its simplicity but for some reason I could never develop my own bootscripts for runit so that all stage 1 commands run in parallel.
At this point, if people still believe they have to write their s6 or s6-rc scripts in execline, I suspect that no explanation, documentation or personalized help is going to satisfy them.
Tip: it has never been the case, ever, from the day s6 was published.
That said, I agree with your assessment that s6-rc is not user-friendly, and am working on it. Ironically, Void Linux has a reputation for not being exactly user-friendly either, so you'd think software like s6-rc would be right in its ballpark.
You really don't need to heavily write stuff in execline to get s6-rc working. While it is true that the entry point to a oneshot needs to be written in execline the very first line can be any program on your system which includes shell scripts.
Could you please contribute your experiences?
"Switching to just s6 doesn't provide many benefits", you mean, apart from the software being maintained and actively developed, with zero longstanding bugs and more hooks for advanced daemon management? :-P
No, the real answer is that nobody so far has wanted to do the effort of properly integrating it into Void (despite s6 being a lot more flexible than runit on policy). There are plenty of people who have successfully switched to s6 on a Void installation, and who are happy with the results, but who do not feel it a good use of their time to polish the steps and industrialize it for Void, because of limitations in the Void way of doing things.
So... I'm perfectly aware of s6's shortcomings and am working on it. It would be nice if distributions (and I'm not only talking about Void here) also did a little bit of introspection and effort.
I like to have service dependencies, without dirty hack in runit like "wait with timeout for other service up" .
imo it would be nice to have that as an extension of runit, for example in a file in the service dir called "dependencies" or something, and where runit would run each service name present in the file before the service itself. it shouldn't be too hard to add in theory, but i'm not knowledgeable about runit's internals, so i might be wrong, but that's how i would personally make it
You can use s6 and s6-rc through 66 right now in voidlinux.
It is not something official (probably it will never become official), but it is an ongoing effort for more than two and a half years. Much has been accomplished, more will be.
Original anouncement.
PR in void-packages.
Git repo with templates where integration work happens.
Git repo with service frontend files and documentation
A small guide for those that want to try.
There is an update coming this weekend :)
Please do not bother void members for issues or information about this. It is completelly unofficial. I will gladly answer any questions you may have in public or private. My email is in my templates in void-packages.
Since you offered to answer questions:
Has there been any feedback whether void might consider switching to s6-rc at some point in the future? I'm asking because I know at least Alpine Linux was considering it at some point (though I don't know if thats still an ongoing process).
How compatible is it with upstream once everything is set up, for example how do you deal with package updates that feature services?
Considering it still seems to be mostly work in progress, are these updates usually easy to install (via xbps?), or more involved (and/or you need to know what your're doing)?
https://skarnet.com/projects/service-manager.html from the article I got an impression, that s6 is still not yet ready for end-users... ok, let's wait for some time.
A few years ago, there was a project that had started that wanted to work with the Void team to bring Void to s6 and help maintain that as an alternative. I guess nothing ever became of that.
Has anyone here used dinit? Seems to address the dependency issue that runit doesn’t. I haven’t had time to try it yet, and have no idea how to do it with Void. I was thinking of learning it by using Artix with runit and then later dinit. But of course, using it on Void would be the point - I don’t want to switch to Artix….
do read, https://skarnet.com/projects/service-manager.html
Thank you nice article.
This looks new. I don’t recall ever seeing this page when I first started to develop a boot system with s6.
Outside of Void, this is one of the official init systems in Artix.
I like to use void. Artix looks too nerdish.
Lol, what do you mean by saying "nerdish"?
BTW s6 is IMO an interesting and promising init system, but it's somewhat raw ATM. I've tried to use it in Artix, but gave up because it's rather complicated and poorly documented at the same time. It is developen by a tongue-tied genius, who just doesn't know how to write texts properly. s6 documentation consists mostly of his rants on how an ideal init system should look like and why systemd is so bad, and there is plenty of stuff about s6 internals, whereas I just wanna know how to use it.
You're talking about switching init implementations and you think one distro is too "nerdish"? That is some solid irony.
Tip of the iceberg here...
Posters also seem to forget the "free" ISC software license rather than GPL or MIT license, never heard of this license myself.
Runit uses a BSD like license.
Also, the s6 software seems intended for Unix.
Runit is intended for both UNIX/Linux, and is already packaged for many distributions.
... but who cares? This ship is not sinkable, Full Ahead!
The ISC license is the original of what is known as the 0BSD license. It is defined as a free software license by the OSI. It is one of the freest possible ones - as close as it gets to public domain, without the legal fog that surrounds public domain.
Linux is a type of Unix, and s6 obviously runs on Linux, as well as a number of other Unix-like platforms. I suspect s6 builds out of the box on significantly more operating systems than runit does.
s6 is packaged for more distributions than runit.
I don't think I want to know what the submerged part of your iceberg is.
The reason Why I've never heard of the ISC license, I've only run or written code in Linux operating systems, with very few trials of FreeBSD or other operating systems. Even in 2015, Wikipedia (FreeBSD/ISC) seems to indicate ISC migrated to other licenses.
When I see an iceberg, I tend to go around it.
All apparently valid arguments.
Sounds like you're the author of s6. I've programmed a few things in my time, and most users seemingly have exquisite tastes when using software; users tend to want everything at once, rather than one thing at a time. Shrugs, if you programmed it well, why worry is my thought.
In this case you see s6 as "improved" some others might see it as "more complex". I like runit for the reason it is super simple and just works. s6 is more complex, has sometimes given me problems, and has been slower in my tests.
I'd like to see your tests, because I very much doubt the "s6 is slower" claim is accurate.
It is difficult to define speed, let alone measure it, for heavily IO-bound software such as runit or s6. It is a meaningless metric for most of the programs in the suite, because at no point is the user waiting.
What you could measure, and that could qualify as speed, is the amount of system calls made by a process to accomplish a given functionality. The fewer, the better. And I'm pretty confident that s6 uses close to the theoretical minimum. There are two exceptions to this:
chpstwill inherently be faster than the s6 way of changing process states, because it performs several operations in a single binary whereas s6 has to exec into another chainloading tool after each operation. This is a UI design choice and both approaches are valid; having separate tools for separate jobs was just my preference.s6-superviseobviously performs more system calls thanrunsv... because it is a lot more featureful. Unfortunately, there isn't a lot I can do about this. Correctness and needed functionality come before speed, always, and especially in software like this whose CPU usage is unnoticeable.