Command Line – runit

On Unix-like systems like Linux, init is the first process to run during bootup, and the one that controls all other processes. For years, most distributions have used SysVinit, an init inspired by the one used in Unix System V. However, in 2012-15, the majority of distributions switched to systemd, which not only provides init services, but an administrative overlay of the entire operating system. Since then, a variety of simpler inits have been written by those who find systemd needlessly complicated. One of the best-known of these alternative inits is Gerrit Pape's runit [1], a collection of utilities designed to be a minimal and easy-to-use init system.

Runit boots and shuts down a system in three stages. Like SysVinit, runit uses runlevels, but, by default, it only uses two: default, which runs all the services linked in /var/service, and single, which is used for rescue and recovery. Other runlevels can be added if desired [2].

Runit's structure offers several advantages:

• Navigation is easy, because components are organized by directories. For example, /var/service contains links to all active services, while /etc/sv contains active services, and /etc/runit/runsvdir contains all available runlevels.
• Each service is assigned a unique directory name, which has a symbolic link to /var/service. Each directory has a single file called run, which has a symbolic link to /var/service. For instance, Listing 1 shows the run file for sshd (borrowed from the runit website [3]). Notice that it is nothing more than a shell script for running the service. Running as a child of the runsv utility, each defined process is assumed to be always running, and, by default, it is restarted automatically if necessary. This arrangement makes services easy to locate and eliminates the need for commands like killall and pidof.

01 #!/bin/sh
02 ssh-keygen -A >/dev/null 2>&1 # Will generate host keys if they don't already exist
03 [ -r conf ] && . ./conf
04 exec /usr/sbin/sshd -De $OPTS 2>&1

• Each service is started with a clean process. The service always has the same environment, resource limits, open file descriptors, and controlling terminals.
• Using runsv, runit can be configured to produce a reliable log.
• Running in parallel, runit boots and shuts down quickly.
• Preconfigured for Debian and BSD systems, runit is easy to port to other Unix-like systems.
• Runit's stage 1 and 3 are governed by shell scripts, making them easy to customize for different distributions.
• A small code size reduces the likelihood of errors and makes runit fast. Runit's utilities vary between 300-500 lines in length.

As a relatively new project, runit is not widely used, although it is carried by many major distributions. You cannot replace systemd with runit, but the online help gives detailed instructions about how to replace SysVinit and gives dozens of sample scripts for starting common services, from simple ones like atd to complex ones like Apache2. If you are simply curious about runit, you can run Void Linux [4] in a virtual machine or from a Live CD to explore it. Void is the only Linux distribution that uses runit by default; it is interesting in itself, because it is written largely from scratch for speed and efficiency. Runit is only one of its unusual features.

runit in Action

Runit is actually a collection of half a dozen utilities that work together [5]. The first process that the kernel starts is runit-inited. Once the operating system is ready for use, runit-init replaces itself with runit-inited. You can use the command init 0 to shutdown the system and init 6 to reboot the system.

Probably, the most important utility is sv. sv follows the classic Unix nomenclature:

sv up /etc/sv/SERVICE

starts a service, while

sv down /etc/sv/SERVICE

stops it. To restart a service (Figure 1), use

sv restart /etc/sv/SERVICE

Figure 1: The basic commands for starting and stopping services.

The command

sv status SERVICE

shows its current status, while

sv status/var/service/*

returns the status of all services (Figure 2). No confirmation message is given unless the -v option is used, and even then it is the briefest of status reports.

Figure 2: The list of running services in Void Linux.

In addition, sv can be used to add new services. After setting up the service and its run file, add a symbolic link with:

ln -s /etc/sv/SERVICE /var/service/

To prevent a service from starting automatically, create a file in the service's directory with:

touch /etc/sv/SERVICE/down

Rather than creating a file named down, as you might expect, the command signals runit to create a supervise subdirectory, a collection of binary files that define how the service runs (Figure 3). If you no longer want to prevent the service from starting automatically, delete the supervise directory.

Figure 3: You can create a file in the service's directory that sets it to not run automatically.

As you can see, sv works with already existing Linux commands, making the command easier to learn.

svlogd is used to set up an optional log in a preexisting directory that rotates when the current log reaches a certain size. Its syntax is:

svlogd OPTIONS LOG-PATH

svlogd's options include a timestamp (-t), a human readable timestamp in YYYY-MM-DD_HH:MM:SS.xxxxx format (-tt), and a line length for entries (-l NUMBERS) (Figure 4).

Figure 4: The steps in the creation of a log directory. The log records all runit-related activity, including actions taken in any runit directory.

A log can be configured by placing a config file in the log directory. Table 1 shows some of the most important configuration options.

When necessary, you can monitor a specific service (s) with runsvdir. The structure of the command is:

runsvdir /etc/sv/SERVICE LOG-PATH

Up to 1,000 services can be monitored. Every five seconds, runsvdir checks whether the time of the last modification, the inode, or the device of a listed service has changed. If so, runsvdir rescans, and, if a service is stopped, stops monitoring it. Similarly, if the service has been restarted, then a new process is started. In addition, all activity in runit-related directories is recorded. runsvdir is not needed for runit to function so much as it is an administrative tool to help keep track of selected services. Closely related to runsvdir are runsvchdir (runsvchdir DIRECTORY), which changes the logfile for runsvdir, and runsv (runsv SERVICE). runsv starts, stops, or pauses the specified service and can interrupt a service or send an alarm if the service is running.

Runit's last utilities are chpset, which can run a specialized version of a service for one user or group, and utmpset, which modifies utmp and/or wtmp when a user logs out. However, neither chpset or utmpset are essential to runit for many users. Like other init systems, once set up, runit operates largely in the background and should rarely require such specialist tools on a small network or a lone workstation.

Reconsidering init Choices

Runit is notably smaller and more limited in scope than the omnipresent systemd. If you hold to the Unix philosophy that an app should do one thing and do it well, you are likely to warm to runit to a degree that you have not to systemd.

However, that is not runit's only virtue. Runit is economically and consistently written and easy to learn. After exploring runit for several hours, I felt competent to use it in a way I have yet to feel with systemd despite several years of use. Although runit might seem a return to a simpler age before systemd, I am nearly convinced that it would not be a bad thing.

Support for multiple init systems would be difficult for any distribution, and perhaps impractical. For this reason, it may be a while before runit is an alternative in the current systemd-dominated world. Still, if runit was compatible with KDE's Plasma and practical to set up in Debian, I would be seriously tempted to use it on my main workstation.