runit

runit
Name	runit
Author	Holger Levsen
Developer	void Linux community, skarnet (Daniel Sockness)
Initial release	2004
Programming language	C, POSIX shell
Operating system	Unix-like
License	BSD-like

runit

runit is a cross-platform, Unix-like service supervision and init replacement suite that provides fast, minimal, and reliable process supervision. Originally developed in the early 2000s, it emphasizes simplicity, composability, and predictable behavior across a range of systems from embedded devices to full-scale distributions. The suite is organized as a set of small, focused programs that together implement a process lifespan model distinct from many traditional init implementations.

Overview

runit implements a three-stage model for system initialization, service supervision, and shutdown. It is often used as an alternative to other init systems such as systemd, Upstart, sysvinit, and OpenRC. The project draws design parallels with supervision systems like daemontools and s6, and is recognized within communities around Debian, Slackware, Void Linux, Alpine Linux, and Gentoo. The design goals prioritize fast boot times, simple service scripts, and deterministic service restarts under failure conditions, making it suitable for environments managed by configuration tools like Ansible, Puppet, SaltStack, and Chef.

Design and Components

runit is composed of three conceptual stages implemented by separate executables and scripts. The first stage handles one-time initialization tasks during bootstrap and is comparable in scope to init sequences used by BSD derivatives and Solaris legacy inits. The second stage provides the core supervision facility that continuously monitors service processes; it uses a process tree model similar to that found in daemontools and supervision primitives in UNIX System V-style service management. The third stage performs orderly shutdown and halt/reboot handling, interoperable with ACPI and firmware interactions often managed by GRUB or system firmware components.

Key components include the supervisor daemon responsible for monitoring service directories, a lightweight init replacement that adopts PID 1 responsibilities, and a set of helper utilities for logging, signaling, and process control. Logging helpers can be integrated with syslog implementations such as rsyslog and syslog-ng or piped to structured collectors used by Fluentd and Logstash. Service definitions are simple directory trees with executable run scripts, allowing administrators to compose dependencies and lifecycle hooks without monolithic configuration languages.

Usage and Configuration

Services under runit are configured using directory conventions and executable scripts rather than declarative unit files. A service directory typically contains a run script that starts the main process, an optional finish script for cleanup, and a log subdirectory when logging is required. This approach resembles the style used by daemontools and by lightweight process supervisors in embedded distributions like OpenWrt and BusyBox environments. Administrators manage services using commands provided in the suite, enabling start, stop, restart, and supervise actions analogous to control mechanisms in Upstart and systemd.

Because runit uses standard process semantics, integration with package managers such as dpkg, RPM, apk-tools, and xbps is straightforward; packages can install service directories to conventional locations monitored by the supervisor. Configuration management systems including CFEngine and Fabric frequently deploy runit service trees as part of reproducible infrastructure provisioning. The minimal scripting model supports portability across POSIX shells used in projects like NetBSD and FreeBSD ports.

Integration with Init Systems and Compatibility

runit can function as a PID 1 init replacement or as a supervisor under an existing init system. When replacing system init, it assumes early boot responsibilities and offers shutdown and runlevel-like semantics compatible with legacy sysv scripts, enabling deployments in distributions that historically used init scripts and rc.d frameworks. In coexisting setups, runit is often launched by primary init systems such as systemd in containerized or transitional scenarios, and it can supervise service trees within namespaces used by containerd, Docker, LXC, and rkt runtime environments.

Compatibility layers and packaging conventions have been developed in several distributions to make the transition from sysvinit easier, and wrappers exist to adapt sysv-style initscripts to runit’s run script model. The suite interoperates with service discovery mechanisms employed by Consul, etcd, and Zookeeper when used in distributed systems, facilitating integration into orchestration stacks including Kubernetes and Nomad via sidecar supervisors or init containers.

Security and Reliability Features

runit’s design favors small, auditable code and minimal attack surface, aligning with security principles emphasized by projects like OpenBSD and Alpine Linux. The supervision process enforces strict control over child processes and reaps zombies reliably, reducing privilege escalation and resource leakage risks encountered in less deterministic init implementations. Logging can be isolated per service to avoid cross-contamination of sensitive output and integrated with access controls used by SELinux and AppArmor profiles.

Reliability is achieved through deterministic restart policies: services are restarted immediately or after configured delays and can be constrained using process limits from systemd-style cgroups when deployed in containerized contexts. The predictability of runit’s behavior simplifies failure analysis with tooling such as strace, gdb, and Valgrind, and its simplicity eases formal inspection and inclusion in high-availability setups run by operators using Pacemaker and Corosync.

Adoption and Implementations

runit is used directly or indirectly in several operating systems and projects. Prominent adopters include Void Linux, which employs runit as the default init; Alpine Linux, which integrates runit in many container images; and Artix Linux, where runit is an optional user choice. Numerous embedded and appliance vendors prefer the suite for its low overhead in OpenWrt-derived builds and custom network appliances. Third-party init wrappers and language-specific frameworks for Python, Go, and Rust ecosystems often provide convenience bindings to runit-style supervision. Community contributions and packaging integrations exist across distributions like Debian, Fedora, Arch Linux, Gentoo, and Slackware.

Category:Process supervision software