HOME

WHY

SUPPORT

DOWNLOAD

SOURCE

WIKI

NEWS

LOGO

pozol.eu

Should I use runit or 66 or both?

We can easily tell you what to do based on a bias, and as a distribution we can even enforce choices, but the choice should be left for you to make. If you keep things simple enough it makes little difference, still, if it is a simple server where reliability matters, the choice is simple for those proficient in using both systems. You wouldn't be looking for an answer if that was the case, so we will offer the best we understand so you can make a wise choice.

Some history first. Look up daemontools, the parent of both systems and a few less well known systems, such as perp, or dinit. How did this daemontools revolutionize the init and service management part of the system? Simple, reliable, tolerating abuse, and by far superior to chainloading a bunch of scripts (sysvinit, BSDscripts, and even OpenRC). We will not bore you with technical details, but both runit earlier (20-21years) and s6 more recently, and since the question why is already awnsered properly by the author, we will just summarize that s6 is an evolution of both daemontools and runit. It is slightly bigger yet still 1/20 the size of systemd last we checked. On the other hand its reliability and robustness is centered as being ONE program as init and service supervisor, while runit is two (runit-init and runsv). How this affects the system is that as long as this is running the setup of services running are reborn, and the system only goes down when that initial program receives a very specific instruction to do so. In runit, it is possible for the service supervisor to crash, while the system stays up without providing any control or access to it. As far as I understand and know, other than a total powerfailure there is no record of s6 crashing.

S6 appears and is very complex in setting up services to be supervised. In runit you write a few lines of a scrit on how to start and stop a program and this script is trhown into the directory supervised. Anything linked runs, anything removed stops (being supervised). With s6 the environmental variables, the instructions and flags to run a program, when, before and after which, dependencies, groups of programs, are compiled into a minimal binary database file. S6 reads this database and suervises each piece under specific parameters. Those isolated mini environments are not affected by the general system environment, it is as a separate part of the system doing just what it is meant to do. This improves the speed of services going up and the responsiveness of the system as a whole. Runit runs at a slower pace, doing passes reading and executing bash scripts. With some kind of monitor (conky or htop) you will see how daemons stop and start at increments with runit. S6 gives you the feeling of interacting at real time with the kernel, which in a way it is pretty accurate.

In our setup we have made it possible to have both installed. Other than 4 scripts for the powerfunctions, poweroff, reboot, shutdown, halt, the two have nothing in common. This means they can coexist. Runit usually has a hard link of runit-init to /sbin/init, which we have removed. Instead in the boot loader's linux execution we add init=/usr/bin/runit-init. We have left the /sbin/init filename blank for 66 (specifically boot-66serv) so once s6 & 66 are added (through this jobo66 pkg) all you do is remove the init=/usr/bin/runit-init from the bootloader and s6/66 will boot. Without changing anything else on the system you can have consecutive reboots and collect comparative data between the two. If some modification or mistaken configuration of the one or the other takes place and booting seems hard it is simple to switch to the other.

Unlike systemd, no other software in the system is dependent or relate to runit or s6. Just the way it should have been, which makes a huge difference in the design of the entire system. You can try sinit (ready from Spark-Linux), minit, dinit, perp, sysvinit, OpenRC, no change on the rest of the system. This is why we and Obarun have had to built 100s of packages over to untangle the web of the virus like software called systemd/elogind. A huge difference by systemd-free make believe distributions leaving elogind in as a substitute to systemd so everything else works utilizing systemd subsystems.

It hasn't been easy, it is tons of extra work, but the end result can only be appreciated by those who care to understand systems a little deeper than some marketing hype.