The goal of this user guide is to get people started with the bare basics of s6, without the use of suite66 (Eric Vidal / 66 · GitLab). This is not a systemd bashing thread. We can make a separate thread for init wars and service supervision wars, but this thread is not for that. Here we just discuss s6 and how to use it.
Mindless ramble about s6, click this text to read more if you want to know some not-so-quick rundowns about s6, otherwise, continue after this.
Most of you reading this should be familiar with s6. If not, s6 is a suite of software tools that take care of anything from init, to process (a.k.a. service) supervision, to logging.
s6 = skarnet.org’s small and secure supervision software suite.
You can find more about s6, its design choices and comparisons to other inits and service supervisions on its official website (here, here and here). Think of s6 as a replacement for systemd (albeit that is not entirely correct, as systemd does a lot of stuff and s6 only replaces a small portion, although probably the most important portion of a system).
ITT I may make use of the names “services,” “processes” and “daemons” interchangeably, however, that may not be correct in terms of nomenclature, but I do so for historical reasons (just like s6 does in its documentation). Keep in mind s6 can manage both longruns (daemons / services) and oneshots (“run once” programs / “services”). Then there is also the concept of bundles, which are basically a bunch of services or services + other bundles put together in a group.
s6-rc is a service management tool (more on that here). I highly recommend reading all the links I provided, because they all have some great insights on how s6-rc works and why it is such an amazing software, like:
A significantly time-consuming part of a service manager is the analysis of a set of services and computation of a dependency graph for that set. At the time of writing this document, s6-rc is the only service manager that performs that work offline, eliminating the dependency analysis overhead from boot time, shutdown time, or any other time where the machine state changes.
s6-rc is the equivalent of sysv-rc, BSD init’s /etc/rc, OpenRC, Upstart, launchd and systemd. s6-rc is called a machine state manager and it uses a database containing services. s6-svc is a program used to send signals (SIGHUP, SIGKILL etc.) to running s6-supervise processes. You will use s6-rc more often, but s6-svc is nice to know. s6-rc is similar to “systemctl enable / disable,” but because s6-supervise changes states on the go (like runit when you symlink a service), it works more like “enable / disable --now.” It manages both longruns, oneshots and bundles. s6-svc is like using kill (since most of you will be familiar with it, but there are other signals too) without knowing the PID of the daemon, s6 takes care of it. Then, there is s6-svstat to check the status of your services.
Current limitations on this user guide
There are some commands I didn’t manage to get into it, like s6-rc-compile and s6-rc-update, so I don’t currently know how exactly s6 works, so I cannot explain that. Like always, contribution is appreciated.
With the above cruft out of the way, here are a few examples that I have used when trying out Artix-s6:
enable and start a daemon (up)
s6-rc -u change food
disable and stop a daemon (down)
s6-rc -d change food
check a daemon status
s6-svstat /run/service/food[-srv]
or
s6-svstat /run/s6-rc/servicedirs/food[-srv]
Note: some daemons may have the -srv extension at the end. To check the status of the logger, (if it exists and it should, but for example, elogind didn’t have one) use:
s6-svstat /run/service/food-log
list all active services
s6-rc -a list
Note: not sure about this, I will get into it when talking about s6-rc-db
list services related to daemon food
s6-rc list food
(for example, it should return food-srv and food-log - in s6, the daemon and the logger are two different processes, so even if the daemon dies or is shut down, you never lose logs, the logger will only go down after you tell s6 to stop the daemon and it will always come up before the daemon is started)
#I’m not sure what this one does, I believe it shows all processes that are related to food
s6-rc listall food
For example, for dhcpcd, it will show dhcpcd, s6rc-oneshot-runner, udevd, kmod-static-nodes, mount-cgroups, mount-devfs, mount-procfs, tmpfiles-dev. And for elogind, it will show elogind, s6rc-fdholder and dbus. For nginx, it shows s6rc-fdholder, nginx-srv and nginx-log.
add a daemon to default bundle
s6-rc-bundle-update add default food
remove a demon from default bundle
s6-rc-bundle-update delete default food
create a new bundle
s6-rc-bundle create bundle1 food bard
delete entire bundle
s6-rc-bundle delete bundle1
Once we get past those, it gets a little tricky, but if you made it to here and are reading this, you should be fine. More info if you click this text.
I mentioned that s6-rc uses a database. In the documentation, it is called compiled service database, abreviated “compiled.” To compile a service db, all you have to do is run s6-rc-compile. Artix-s6 has a specific custom way to take care of it through the package manager (pacman), by installing the package followed by your init of choice.
So if you install “nginx-s6,” you are basically grabbing a s6 service file and adding it to the s6-rc DB and running s6-rc-compile to make the db. When you uninstall it, the service gets removed and the database gets recompiled.
This meant I was protected by pacman / artix team from getting too deep into s6, so I may need to change to a distro that doesn’t have s6 by default (Alpine, Devuan, Void) and change the init and service manager to s6-linux-init and s6-rc myself (there is work to bring s6 on Void, but using 66suite unfortunately - I wanted to get deeper on how s6 works; helper scripts, unit files and interpreters aren’t exactly my cup of tea).
To read from a compiled database, you use s6-rc-db tool. An s6 service (oneshot, longrun, bundle) has to be writen in the s6-rc source format. Then s6-rc-compile takes all the service definitions in the service directory you point to and creates a new db. It should be automatically created with the name “compiled-unixtimestamp.” If I’m correct, once you compile it, you (the administrator) have to change the symlink “compiled” (usually found in /etc/s6/rc/compiled) to link to the latest “compiled-unixtimestamp” directory (in the same folder). To live update the current service database, all you have to do is run s6-rc-update.
To debug s6-rc-compile, you can use the verbose option. It’s cool that s6 is POSIX compliant and instead of using -vvv for very very verbose, you give it a number argument: -v 0 is just like not using -v at all, -v 1 is the classic -v, -v 2 is -vv and -v 3 is -vvv. I haven’t yet created an s6 service, I will probably attempt haproxy-srv and haproxy-log, because I haven’t seen them in artix-s6.
list the services in a specific s6-rc-db
s6-rc-db list all|services|oneshots|longruns|bundles
No idea how to use s6-rc-compile or s6-rc-update. The first one is to compile a new s6-rc database for the next boot or for a later reload, the second is to update the s6-rc db on the fly (live).