X sessions with s6

Example: urxvtd

My terminal emulator is called rxvt-unicode. Typically and preferably every terminal is its own processes, but if you use lots of terminals and create/discard them on the fly all the time (as I do), there is some speed and memory benefit in using urxvtd, the rxvt-unicode daemon.

Its default mode of operation is as a regular foreground process, which makes it really easy to supervise. First create a directory for it, called its service directory (yes, the term is inappropriate given my note about services above, but that’s s6 terminology, so we’ll go with it):

mkdir urxvtd

(One-time reminder: all paths are relative to ~/run.) Now create a file named urxvtd/run containing the following shell script:

#! /usr/bin/env sh
cd
exec urxvtd

Now make that file executable:

chmod 755 urxvtd/run

That’s it. The run script will be used by s6 as the process to supervise. Let me repeat that: from the viewpoint of s6 for all intents and purposes this script is the program it should supervise, which is the reason why we exec into the daemon at the end after some minor setup. The cd command just switches into your home directory before executing urxvtd, because s6 starts processes in the service directory, and you probably don’t want all your shells to start there.

First test run

Now let’s fire up this baby and see how well it works. To invoke s6 on a scan directory start the scanner called s6-svscan on it:

s6-svscan .

You will immediately notice that this too is a foreground process, so you need an extra shell to continue from here (resist the temptation to send s6-svscan to the background for now). Remember to cd ~/run in the new shell. The second thing you will notice is that you get a bunch of new running processes as a side effect, and among them you will indeed find urxvtd. Great!

The other two processes are s6-svscan, the one you just started, and s6-supervise, the actual supervisor for individual processes. Don’t worry about the number of processes, as the s6 processes are designed to be extremely small. They do their job and nothing else.

You can control the supervisors of individual processes through s6-svc. For example you can temporarily disable urxvtd by setting its state to down:

s6-svc -d urxvtd

The argument urxvtd is actually the path to the service directory. If your current working directory weren’t ~/run, you would have to write something like:

s6-svc -d ~/run/urxvtd

This command communicates with s6-supervise and in this case requests to terminate the process (and not restart it). S6-supervise will immediately kill the process, and you will find that urxvtd is no longer running. You can bring it back up by setting its state to up again:

s6-svc -u urxvtd

Note that s6 always starts from a clean state. That means that the process state is not preserved across runs of s6-svscan. There is a way to disable a process permanently without deleting it, but more on that later. Another interesting thing to note is that if you kill the urxvtd process by yourself using e.g. kill, or if it crashes for some reason, its state will still be up. S6-supervise notices when the process dies unexpectedly and restarts it after a delay of one second.

There is a separate command called s6-svscanctl to control the scanner itself, the root of your process tree. For the most part you will only need this command in two situations: either to stop the scanner, which will amount to terminating your X session, or to rescan the scan directory for new processes. Run the following command now to terminate the scanner:

s6-svscanctl -q .

This command communicates with the s6-svscan instance running in the given directory and tells it to exit, and you can watch your s6-svscan finish and return to your shell. However, it will also print a bunch of worrying messages before it exits:

s6-svscan: warning: unable to exec finish script .s6-svscan/finish: No such file or directory
s6-svscan: warning: executing into .s6-svscan/crash
s6-svscan: fatal: unable to exec .s6-svscan/crash: No such file or directory

The problem here is that s6-svscan normally refuses to exit by itself. Remember that it was designed as a process that runs as PID 1, a.k.a. the init process, which must never exit. An exiting init process causes a kernel panic. Therefore the normal way to shut it down is to exec into something else, for example a script that handles rebooting the system or powering it off.

However, we’re not using it as an init process, so we actually want it to exit. The easiest way to do that is to make it exec into something trivial that does nothing, for example an empty shell script. The first warning indicates that s6-svscan execs into .s6-svscan/finish when it is told to exit. The .s6-svscan directory should already exist now, because it is created by s6-svscan. Run the following commands:

echo '#! /usr/bin/env sh' > .s6-svscan/finish
chmod 755 .s6-svscan/finish

If you want you can put some gimmicks into that script to make it print something at the end of your session. We will do that just to see that it works:

echo 'echo "Good bye."' >> .s6-svscan/finish

Now start s6-svscan again:

s6-svscan .

And from the other shell tell it to exit again:

s6-svscanctl -q .

And indeed instead of warnings it exits cleanly with the message Good bye. that we put into our finish script. Alright, let’s start it again:

s6-svscan .

Just leave it running from here.

Example: MPD

With the Music Player Daemon (MPD), it’s pretty much the same story, but with a catch: MPD operates in daemon mode by default, which is undesirable. Fortunately it does offer a foreground mode that you can enable through the --no-daemon command line option. Again create a service directory for it:

mkdir mpd

Create the script mpd/run as you did with urxvtd before, but pass the --no-daemon option to MPD, and also don’t make it executable just yet:

#! /usr/bin/env sh

cd
exec mpd --no-daemon

If your version of s6 is older than 2.3, then you will notice that as soon as you have created the directory, s6-svscan will periodically produce warnings that it can’t execute your run script. This is because it used to rescan the scan directory periodically by default, but since version 2.3 it no longer does. Using s6-svscanctl you can tell it to rescan when you add new supervised processes (-a) or to kill supervised processes of service directories that you have deleted (-n):

s6-svscanctl -an .

At least since running that command you should see the warnings now:

s6-supervise mpd: warning: unable to spawn ./run - waiting 10 seconds
s6-supervise (child): fatal: unable to exec run: Permission denied

They will be printed periodically until you make the script executable:

chmod 755 mpd/run

After that command the supervisor will (hopefully) succeed to start MPD. And as with urxvtd you can manage the process through s6-svc.

Ok, we’re done with the supervisor tutorial. In the next major section we will learn how to add your window manager to the mix and manage your entire X session using s6. For now just shut down s6-svscan again:

s6-svscanctl -q .

Disabling processes

As explained earlier all state changes made through s6-svc are ephemeral. If you want to disable a process permanently without deleting its service directory, all you need to do is to create the file down there. For example to disable MPD, you would use the sporty command sequence:

touch mpd/down
s6-svc -d mpd

The second command is needed, because the supervisor does not shut it down automatically, if it’s currently running. It only uses the existence of the down file to decide the initial state of the process. In order to enable it again, just delete that file:

rm mpd/down
s6-svc -u mpd

Emacs server

Unfortunately some programs resist being supervised that easily. The (GNU) Emacs server is a well known example of that, because it insists on forking, if you use the --daemon command line option. I don’t have a good answer on how to supervise those.

One solution I have found online is not to use --daemon at all, but start a regular Emacs instance in a Screen session, then invoke the Elisp function (server-start). Screen is a foreground process that doesn’t require a terminal on stdin/stdout, so it can be supervised easily.

The real solution is to fix those daemons.