sv
Control and monitor services managed by runit
TLDR
Start a service
Stop a service
Get service status
Reload a service
Start a service, but only if it's not running and don't restart it if it stops
SYNOPSIS
sv command [service_name_or_directory ...]
PARAMETERS
up
Starts the service and ensures it stays running.
down
Stops the service and ensures it stays down.
once
Starts the service if it's down. It will not be restarted if it exits.
pause
Sends a SIGSTOP signal to the service, pausing it.
cont
Sends a SIGCONT signal to the service, resuming it.
hup
Sends a SIGHUP signal to the service.
alrm
Sends a SIGALRM signal to the service.
int
Sends a SIGINT signal to the service.
term
Sends a SIGTERM signal to the service.
quit
Sends a SIGQUIT signal to the service.
usr1
Sends a SIGUSR1 signal to the service.
usr2
Sends a SIGUSR2 signal to the service.
exit
Tells the runsv(8) supervisor to exit for the service. Use with caution.
kill
Sends a SIGKILL signal to the service, forcing termination.
status
Reports the current status (up/down, PID, uptime) of the service.
check
Checks if the service is running and correctly supervised.
start
Alias for 'up'. Starts the service.
stop
Alias for 'down'. Stops the service.
restart
Sends SIGTERM, waits, then restarts the service ('term' then 'up').
force-reload
Alias for 'restart'. Re-reads service configuration and restarts.
force-restart
Sends SIGKILL, waits, then restarts the service ('kill' then 'up').
force-stop
Sends SIGKILL to immediately stop the service.
reload
If a 'reload' script exists in the service directory, executes it. Otherwise, sends SIGHUP.
shutdown
Sends SIGTERM to all supervised services, then SIGKILL after a delay. Used for system shutdown.
DESCRIPTION
sv is the service management command for the runit init scheme. It is used to control and query the status of services supervised by runit. Unlike traditional init systems, runit emphasizes simplicity, robustness, and speed, and sv embodies these principles by providing a straightforward interface to interact with supervised processes.
sv can start, stop, restart, and check the status of services, as well as send various signals to them. It operates on service directories, typically located in /etc/service or /service, where each directory represents a supervised service and contains a 'run' script that runit executes. sv communicates with the runsv(8) supervisor process, which monitors the 'run' script and its associated log processes.
Its design makes it particularly suitable for environments where minimal overhead and high reliability are paramount, such as embedded systems or servers where resource efficiency is critical.
CAVEATS
sv is part of the runit init system, which is less common than systemd or SysVinit on mainstream Linux distributions.
It relies on a specific service directory structure (e.g., /etc/service or /service).
Its design is minimalist; it doesn't offer complex unit file configurations or dependency management like systemd.
All service control commands are synchronous; sv will wait for the service state change to occur or timeout.
SERVICE DIRECTORY STRUCTURE
runit services are defined by directories, typically located in /etc/service or /service. Each service directory must contain an executable run script, which is executed by runsv(8) to start the service. Optionally, it can contain a log/run script for logging, and a control/ directory for more advanced control scripts (e.g., control/reload, control/down).
HISTORY
sv is an integral part of the runit init scheme, a cross-platform Unix init and service supervision suite. runit was originally developed by Daniel J. Bernstein (djb) and refined by Laurent Bercot and others. Its design prioritizes simplicity, small size, and robustness, making it an alternative to more complex init systems like SysVinit and later systemd. runit's philosophy focuses on simple, independent services managed by runsv processes, with sv acting as the primary user interface to interact with these supervisors. It gained popularity in environments valuing reliability and minimal resource consumption, such as embedded systems or certain server deployments, often found in smaller or specialized Linux distributions.