LinuxCommandLibrary

runsv

Start and manage a service

TLDR

Start a runit service as the current user

$ runsv [path/to/service]
copy

Start a runit service as root
$ sudo runsv [path/to/service]
copy

SYNOPSIS

runsv service_directory

PARAMETERS

service_directory
    The path to the service directory containing the 'run' script and optionally 'log/run', 'down', etc. This directory defines the service's behavior and associated resources.

DESCRIPTION

runsv is a core component of the daemontools (and compatible systems like s6 or perp) suite designed for robust process supervision. It monitors a single service, specified by a service directory. Its primary function is to run the service's executable script, typically named run, and automatically restart it if the process exits. This ensures high availability for critical applications. runsv handles various signals, allowing external tools like sv to control the service's state (e.g., up, down, restart). It also manages a log subdirectory, often used to pipe service output to multilog or similar logging tools. By providing automatic restarts and controlled shutdown, runsv simplifies the management of long-running daemon processes, making them resilient to crashes and system events. It's usually invoked by svscan, which continuously scans a directory for new or removed service directories and ensures runsv instances are running for each.

CAVEATS

runsv is not a standalone init system; it requires svscan(8) or a similar supervisor to manage multiple service directories effectively.
Its configuration relies on a specific directory structure and shell scripts, which might be less intuitive for users accustomed to more declarative service definitions (e.g., systemd units).
Error output from the supervised run script might not always be immediately clear, requiring inspection of logs.
While daemontools is very stable, the original project is no longer actively developed, though many compatible alternatives exist.

SERVICE DIRECTORY STRUCTURE

A runsv-managed service typically resides in a directory (e.g., /etc/service/myservice). Inside, a file named run (an executable script) defines how to start the service. Optionally, a log subdirectory with its own run script handles service logging, often piping output to multilog. A down file (empty) can prevent runsv from starting the service if present. Other files like control and status are used by sv(8).

PROCESS STATES AND CONTROL

runsv maintains the state of the supervised process (e.g., up, down). External commands like sv(8) interact with runsv via a named pipe (often in /service/myservice/supervise/control) to send commands like start, stop, restart, reload, or query the service's status. This provides a consistent and programmatic interface for service management.

HISTORY

runsv is a key component of daemontools, a collection of programs for managing UNIX services written by Daniel J. Bernstein (D.J.B.). Released in the late 1990s, daemontools pioneered a robust, lightweight, and reliable approach to service supervision that significantly influenced subsequent service management systems. Its design principles, focusing on simple, single-purpose utilities and a declarative directory-based configuration, proved highly effective for maintaining service uptime. While daemontools itself hasn't seen recent updates from D.J.B., its concepts and implementations have inspired many modern supervision suites like s6, perp, and even aspects of systemd's design regarding process supervision and logging.

SEE ALSO

svscan(8), sv(8), multilog(8), systemd(1)

Copied to clipboard