Introduction to 66suite – s6 made easy – thanks to Obarun

S6 appears as the init system that few distributions have chosen as their default init and service management/supervision (obarun and possibly Adélie once stable is released).  There are quite a few commercial servers running on this system.  For general personal use s6 seems complex, but complex is not always a bad thing.  It would be unfair to compare it with older systems such as SysV-init.  Sysvinit is the system that the overwhelming majority of enterprise system administrators had learned on and relied on for decades (yes it is more than one).  Upstart seems extinct by now, and OpenRC is getting old as well, and didn’t necessarily deviate much from the path of sysvinit.  But then there is Runit.  Void and Artix appear the first two we think right away that use it. S6 is a step further into the future of unix-like systems.

Runit is great, it is fast, and it is simple.  It boots fast, it reads its scripts fast, and starts and monitors services, daemons, and logs their lives.  As a young sys-admin it is hard to resist choosing it for the confidence it inspires, due to its simplicity.  It has a weakness that s6 doesn’t have, and in rare conditions runit can go down instantly allowing very little trace of the condition that caused it.  But this gets too theoretical and scientific.  (read articles 1,2 in reference section below)  The practical difference is that runit is too simplistic.  It is a classic system designed and controlled by the sys-admin that users have to work on.  A set system by the boundaries set by someone else.  A user, without root rights, can not start, stop, pause, utilize more or less services and daemons.  S6 excels in this area.

Don’t underestimate this feature, of user controlled processes as a single system admin and user (most of us hobby admins) because there are times, and it seems it is becoming more in demand these days, that you may need to isolate parts of the system from one another.  Containers, cgroups, virtual machines, are all similar efforts that address similar needs.  Sometimes it is for security reasons, sometimes due to the complexity of modern systems a crash on one procedure should not affect the health of another, both running on the same machine.  S6 can do this very well.

But what is it that 66 can do more than s6?

S6opts (Obarun’s previous service management tool set) was a set of scripts that let the admin, and users, start, supervise, log, and stop services and daemons.  There were two problems, as far as I can understand, that the database of services, status, history, was too complex to handle and required too much terminal time to modify.  The s6opts program itself had become bulky and as a set of scripts itself it was sometimes slow.  It became slower as the system became more complex.  So last year the main developer of Obarun devoted the majority of his developing time in creating a whole new suite of service managing tools.  He wrote the entire thing in C, compiled it under the arch x64 glibc based system, and delivered.  The service scripts for each program now have become very simple, it is trivial for even non-coders to learn to create their own, but Obarun has covered most common bases already.  All 66 tools use -h for a quick help section that simplifies their use.  This “marvel” has been released for beta testing for some months now and some of us tortured it to extremes to see if everything works as it should.  It was refined a few times, not a single bug was really discovered by us users, it was just refined for simplicity of use and efficiency.  The goal: To take the magic of the system and put it under the control of the user. – Achieved!

Using 66 as a novice in init and service management helps make sense of all other init systems and service management.  What you end up asking is “why is everyone else making things so complicated to control?” or “why doesn’t the other system allow me the user to choose what I want running in the background and what not?”.  In summary both root and user can bundle services into what has been called trees.  For certain situations, specific work, specific setups, networking, hardware control, you need 2 or 3 or more services to be running.  Other times you don’t need this combination but a different one to do something else.  You set what you need into a “tree” of services, you initiate the tree, do your work, put the tree to sleep and free up resources for something else.  There is a boot tree (classic file-checking and mounting filesystems) and then after this tree has run what is done during boot, the root tree is activated and brings the system to a terminal (tty or display manager running as service).  You could have networking service run as root, dbus, consolekit, etc. or simplify it and have nothing other than a tty1.  Then create other trees either as root or user depending on what you want to be doing.  It is so simple and quick you will be amazed, no matter how much you love your current system.  If you want to learn Linux, this may very well be the right place to start.  If you want to manage a network of servers with hundreds of users depending on you, this may very well be the place to be.

Once you become proficient with 66 tools you can use those commands that enable and disable trees of services and create your own mini-scripts with those command.  For example, if you want to scan, print, down/up-load bluetooth files, you can make a tree called imgprint.  Then make a script enabling that tree, starting the software you will be using for such a job, once they are closed, the tree is disabled again, and your system is free to do something else.  Do you really need cups-daemon running all day every day, for being able to print your electric bill once a month, taking resources while playing a game, or browsing?   Do you have to worry about networking, ssh server, being active when you want to do something that is best done while you are offline?

S6 and 66 will quickly make a true system administrator out of any user.  This has been the greatest failure of systemd.  Not only has it not helped younger users (not in age but unix/linux experience) but has confused them even more to not even try and mess with such things.  Systemd has such a complex structure and uses such odd names for things that are commonly understood with other terms, that people are afraid to modify the original distro setup or the system collapses.  Everything is interdependent with such fragile relationships that the only thing you learn is not to mess with what systemd does.   It is like ms-windows, once it is locked you better reinstall.

Do you really know what systemd does? It starts everything and makes everything available at all times.  It does so in such a complex dynamic way that one little mistake of stopping one thing starts a domino effect of a system crash.  And let’s say there is an upgrade of a buggy piece of software that came in and systemd is starting.  The service crashes, locks, freezes, whatever.  Systemd logs it, kills it, and restarts it, again and again, and again, creating huge useless logs of the same instance, and leaving you clueless on what may have caused this.  The inexperienced desktop user may not even know something like this is going on.  Not since that last upgrade.  A suspicious user will inquire why so many resources are taken up when nothing the user wanted to run is running.  A booted desktop idling with 700GB of Ram already being used.  You open htop or any tasks management program, you see things jumping up and down, starting, stopping, restarting, so fast you can’t even tell which is doing what, no matter how you order them.  A maze only understood by the people who developed systemd itself.  They call that reliable and stable.  It is a turd in drag!

You don’t want to take a chance and use this little known system as your work system.  Why not download one of the isos, read the 66 documentation, and play around with the system in a virtual machine.  The live images have 8GB of space to download software, create trees, enable them, modify them, kill them, read their logs, decide what you want logged and what not, and tell us what you think when you are done playing.  Use the to read what the first users faced with 66, see what problems they had, and how solutions were explained.  Personally I’ve never developed such a feeling of control over my machine that I have acquired with 66.  I remember liking runit for a while, both Void’s and Artix’s variety, but now it seems as using pliers on precision machine allen bolts.  I wouldn’t be surprised if this s6/66 brings a new revolution in open-source and free-software that 5-10 years from now we will be talking of all those other init systems as antiques.

Note:  An important detail about 66, and I believe s6 as well, is that it is all written in C and that makes it portable to any unix-like system.  This means that it runs just as well build against glibc as with musl.  In fact the S6 developer’s server is running on musl, while arch is glibc only.  Systemd will never be compiled with musl, it can’t as far as I know.  If you think musl is the future and glibc is bound for deprecation this is an important detail to remember.



1  Steve Litt,

2  Davin McCall (author of Dinit)

s6 and s6-rc documentation from skarnet

4  66-tools documentation

5  OBARUN_x86_64-2019-04-2.iso (minimal)

Obarun-JWM_x86_64-2019-04-2.iso (JWM desktop)

or visit

further interest and references suggested by mobinmob in a comment below:

[1] slew
[2] void-s6-rc

7 thoughts on “Introduction to 66suite – s6 made easy – thanks to Obarun

  1. 66 is a well designed collection of tools around s6/s6-rc. It allows both handwritten and generated run scripts and combinations of the two. Slew is another approach with the similar goals.[1] They are both a testament to their respective authors abilities and also the validity of the underlying platforms design. The most slim layer on top of the s6/s6-rc that I know is void-s6-rc.[2].
    All the above desperately need user-level documentation. That is not a critique of the projects, as they have terse and correct basic documentation. It is a way interested parties can help – I hope I can find some time to invest in this.



  2. A day or two after the discussion was initiated about s6 in void, and Eric had proposed that installing 66 in void should be relatively easy, as 66 was designed to be portable, the forum went down and the discussion ended.
    The idea survived and with my limited skills I was able to get a clone of my glibc/void installation to boot and run with s6 and utilize the 66 suite. I’ve kept it alive and learned from it and except from dependency conflicts between xbps and pacman and trying to keep both happily cohabitating, I’ve never had any booting or configuring issues. It runs like a swiss clock. If I could replicate this in musl I’d be even happier.

    Thanks for your comment and your work, I believe there is a benefit of communication between parties working on same particular goals, and I hope to facilitate this communication as much as I can. I also think I can contribute in the documentation part, as soon as I will feel a bit more comfortable with its functionality.


  3. Well, you don ‘t have to do much to install 66 anymore in void. There are packages now for all supported archs. I made the initial PR, improved it with invaluable help from the void devs and the upstream dev. Integrating 66-boot and getting it to do everything that void-runit does will take some work…


If your comment is considered off-topic a new topic will be created with your comment to continue a different discussion. This community is based on open and free communication, meaning we must all respect all in minimizing the exercise of freedom to disrupt such communication. Feel free to post what you think but keep in mind the subject matter discussed. It is just as easy to start a new topic as it is to dilute the content of an existing discussion.

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.