1 History and development
runit emerged as a compact service supervision suite for Unix-like systems, combining an init process with a persistent supervision framework. It was created to provide dependable process control without the complexity found in larger service managers. Over time, it became known for its straightforward file-based configuration and its emphasis on predictable behavior at boot and during normal operation.
1.1 Origins of runit
runit was developed by David Osterlund and later maintained by Gerrit Pape. It grew out of practical needs in system administration, where administrators wanted a small toolset that could keep critical services running and recover them quickly if they failed. Its design was influenced by Unix traditions of composing simple programs that each perform one job well.
1.2 Design goals
The project was built around a few clear goals: simplicity, speed, and reliability. It avoids large dependency chains and focuses on supervising services with minimal overhead. Another central goal is clarity of behavior, so that startup, shutdown, and restart sequences are easy to understand and reproduce.
1.3 Adoption and usage
runit has been used on Linux, BSD, and various embedded systems, especially where lightweight administration is valued. It is often chosen for machines that run a small number of long-lived daemons or for environments where administrators want deterministic boot behavior. Its adoption has been strongest among users who prefer modular tools and compact system software.
1.4 Related supervision philosophy
runit belongs to a broader family of supervision-oriented tools that treat services as continuously monitored processes rather than one-time launch commands. This approach emphasizes automatic recovery, explicit control files, and separation between a service and its log handling. The philosophy aligns with Unix-style supervision frameworks that favor transparency over hidden orchestration.
2 Architecture
runit’s architecture separates system startup, service supervision, and shutdown into distinct phases. Each stage has a narrow purpose, which makes the overall system easier to audit and debug. Services are represented in directories, and the supervision logic continuously watches those directories for runnable definitions.
2.1 Core components
The suite is usually described in terms of three major parts: the initial boot stage, the per-service supervisor, and the shutdown sequence. Together, these components provide an end-to-end lifecycle for system services. The structure is intentionally small so that the same tools can be reused across different machines and environments.
2.1.1 init stage
The init stage is the first process started by the kernel and is responsible for bringing the system into a usable state. In runit-based systems, this stage performs early boot tasks and then hands control to the supervision framework. It is designed to be minimal and to avoid unnecessary branching or complex policy.
2.1.2 service supervision stage
The supervision stage is the core of runit’s design. It launches services, keeps track of them, and restarts them when needed. Each service is monitored independently, which prevents failures in one daemon from directly affecting others.
2.1.3 shutdown stage
The shutdown stage handles the orderly termination of running services. It sends stop signals, waits for processes to exit, and then proceeds with the final system halt or reboot action. This phase aims to preserve service discipline by giving daemons a chance to clean up before the machine powers down.
2.2 Service directories
Services are usually defined by directories containing executable scripts and optional metadata. A directory-based layout makes configuration visible to administrators and easy to manage with standard filesystem tools. The supervision system scans these locations to determine which services should be active.
2.2.1 run script
The run script is the main executable for a service. It contains the command that should be supervised and restarted if it exits. Because the script is plain text, administrators can adjust startup parameters without needing a separate configuration language.
2.2.2 log service
Logging is commonly handled by a separate companion service directory. This split keeps application output distinct from the main process and allows log handling to be supervised just like the service itself. The arrangement supports consistent file creation, rotation, and archival behavior.
2.3 Process states and control flow
runit tracks whether a service is running, stopping, or waiting to be started. When a supervised process exits, the supervisor decides whether to restart it based on the service definition and current control state. This control flow keeps service behavior uniform and reduces ambiguity during failures or administrative changes.
3 Service management
Service management in runit is centered on starting, stopping, and monitoring processes through lightweight commands and directory-based state changes. The model is intentionally explicit, so administrators can see which services are enabled and how they are being handled. This makes it suitable for systems where predictable operations matter more than elaborate policy layers.
3.1 Starting services
A service typically starts when its directory is recognized by the supervision tree. The supervisor executes the run script and monitors the resulting process. Startup is immediate and usually does not depend on large dependency graphs.
3.2 Stopping services
Stopping a service generally involves signaling the supervised process to exit cleanly. If the process does not terminate promptly, the supervisor may escalate according to its normal control behavior. The design favors orderly shutdown over abrupt removal whenever possible.
3.3 Restarting services
Restarts occur when a service exits unexpectedly or when an administrator explicitly requests a restart. Because supervision is continuous, recovery can happen automatically without needing a separate daemon manager. This makes transient failures less disruptive to long-running systems.
3.4 Enabling and disabling services
Services are enabled by placing them under the supervision tree, often through symlink-based directory organization. Disabling a service typically removes it from the active scan path or stops supervision for that entry. This arrangement allows administrators to make changes with ordinary filesystem operations.
3.5 Dependency handling
runit does not rely on a heavy dependency engine. Instead, it encourages services to be written so they can start independently or through simple local ordering. Administrators who need sequencing often create small wrapper scripts or arrange startup directories to satisfy basic prerequisites.
4 Supervision features
runit is known for features that keep services alive and visible to administrators. Its supervision model is built to detect exits quickly and respond with minimal delay. Additional components help with readiness, logs, and status reporting.
4.1 Automatic respawning
If a supervised service exits, the supervisor can start it again automatically. This respawning behavior is one of the system’s defining characteristics. It helps maintain availability for daemons that are expected to run continuously.
4.2 Crash handling
When a process crashes, runit records the exit as a supervision event and can relaunch the service. This makes failures observable without requiring manual intervention after each incident. Repeated crashes may still indicate a misconfiguration or software defect, but the supervision layer keeps the service under watch.
4.3 Readiness signaling
Some services need time to initialize before they are ready to accept requests. runit supports patterns that let a service indicate readiness after startup work is complete. This helps avoid race conditions in environments where other programs depend on a daemon being fully available.
4.4 Logging integration
Logging is treated as a first-class service function rather than an afterthought. Output can be connected to a supervised logger, which keeps log management separate from application execution. This separation improves reliability and makes log handling easier to supervise independently.
4.4.1 svlogd
svlogd is a log daemon commonly associated with runit. It reads input, writes log files, and applies log management rules in a supervised manner. Its behavior is intentionally simple, which suits systems that prefer transparent log pipelines.
4.4.2 log rotation
Log rotation is handled through the logging subsystem rather than through a broad system-wide mechanism. Files can be rolled over based on size or retention rules, depending on configuration. This approach keeps rotation local to each service and avoids centralized complexity.
4.5 Service status monitoring
Administrators can inspect whether a service is running, waiting, or down through status commands and supervision directories. This visibility makes it easy to check system health without parsing complex state databases. Status information is generally immediate and tied to the actual process state.
5 Command-line tools
runit provides a small set of command-line utilities for controlling services and processes. These tools are designed to be composable and easy to script. Their names are short, reflecting the package’s preference for compact administration.
5.1 sv
sv is the primary control tool for supervised services. It can start, stop, restart, and query status depending on the command given. Administrators use it to interact with individual services without directly manipulating internal state.
5.2 chpst
chpst adjusts the execution context of a process before launching it. It can set resource limits, change users or groups, and modify environment-related attributes. This is useful for running services under constrained or specified conditions.
5.3 runsv
runsv is the per-service supervisor that monitors a single service directory. It handles lifecycle events, restarts, and control requests for that service. Its role is central to the overall supervision model.
5.4 runsvdir
runsvdir watches a directory of service directories and starts a separate supervisor for each one. This makes it the component that connects a filesystem layout to a running supervision tree. It is often used to manage many services at once.
5.5 runit-init
runit-init serves as the initial boot process on systems configured to use runit as init. It bridges kernel startup and the service supervision environment. In that role, it helps establish the rest of the system’s control flow.
6 Installation and configuration
Installation and configuration are usually straightforward because runit relies heavily on standard directories and executable scripts. Setup commonly involves packages, boot integration, and arranging service directories in the expected layout. Administrators often value the fact that configuration can be reviewed directly in the filesystem.
6.1 Package installation
On many systems, runit is installed from the distribution package manager. The package typically provides the supervision tools, init components, and logging helpers needed for basic operation. After installation, services can be added by creating the appropriate directory structure.
6.2 Boot integration
Boot integration requires the system to start runit’s init or supervision components early in the boot process. This may involve replacing or chaining from another init mechanism, depending on the platform. Once active, the supervision tree continues running until shutdown.
6.3 Directory layout
The standard layout usually separates service definitions, log directories, and control information. This structure supports simple discovery and makes it easy to enable or disable services by moving directories or symlinks. The clarity of the layout is one of the reasons runit is considered approachable.
6.4 Migration from other init systems
Moving to runit from another init system often involves translating startup scripts into run scripts. Administrators may also need to rethink dependency order, since runit favors direct supervision over global orchestration. The migration is typically manageable for systems with modest service complexity.
6.5 Common configuration patterns
Common patterns include one directory per daemon, a separate supervised logger, and small wrapper scripts for environment setup. Many installations also use a dedicated service directory tree for enabled services and another location for inactive definitions. These patterns keep service behavior explicit and easy to duplicate.
7 Platforms and distributions
runit has been used across several Unix-like platforms, with particular appeal on systems that value compact service management. Its portability stems from its reliance on basic process control and filesystem conventions. As a result, it can operate in environments ranging from desktop Linux to small appliances.
7.1 Linux support
Linux is the platform most commonly associated with runit. It integrates well with standard proc-based process control and filesystem permissions. Many Linux administrators appreciate its small footprint and the directness of its supervision model.
7.2 BSD support
BSD variants also support runit, often with similar directory-based service layouts. The toolset fits the Unix process model well, so porting tends to be practical. On these systems, it is used where lightweight and transparent service control is preferred.
7.3 Distros using runit
Several distributions have offered runit as a primary or optional init system. It is often selected by users who want a leaner service manager than the default option. Distribution support can vary, but the underlying supervision concepts remain consistent.
7.4 Embedded and minimal systems
Embedded deployments benefit from runit’s small size and low runtime overhead. Minimal systems may use it because it avoids large frameworks and supports fast boot behavior. In such settings, the simple supervision model can be easier to maintain than more elaborate alternatives.
8 Advantages and limitations
runit’s strengths lie in its compactness, clarity, and dependable supervision. At the same time, its minimalist philosophy means that some advanced orchestration features are intentionally absent. The balance appeals to administrators who want direct control rather than a broad management platform.
8.1 Simplicity and small footprint
One of runit’s main advantages is its modest resource usage. The codebase and operational model are both narrow in scope, which can reduce complexity during troubleshooting. This simplicity also makes it easier to understand how services are started and maintained.
8.2 Reliability and supervision model
The continuous supervision approach improves resilience for long-running services. Automatic restart behavior can recover processes after crashes or exits with little delay. Because the system keeps each service under direct watch, failure handling is usually straightforward.
8.3 Comparison with other init systems
Compared with larger init systems, runit offers less built-in policy and fewer abstractions. It does not attempt to solve every boot-time or dependency problem in a single framework. For administrators who want a more explicit and compact model, this can be a major advantage.
8.4 Known limitations
runit’s minimalism can also be a constraint. It provides fewer features for complex dependency graphs, rich unit metadata, and extensive central orchestration. In large environments with many interrelated services, administrators may need to build additional conventions around it.