OpenRC

OpenRC is init system for Unix-like systems that maintains compatibility with the system-provided init system]], normally located in. OpenRC is Gentoo's native init system, although other init systems are available.

OpenRC will start necessary system services in the correct order at boot, manage them while the system is in use, and stop them at shutdown. It can manage daemons installed from the Gentoo repository, can optionally supervise the processes it launches, and has an the possibility to start processes in parallel - when possible - to shorten boot time.

OpenRC was developed for Gentoo, but is designed to be used in other Linux distributions and BSD systems. By default, OpenRC is invoked by sysvinit on Gentoo.

Daemons installed from outside the Gentoo repository, e.g. software downloaded as source code and compiled manually, may sometimes need to be adapted to work with OpenRC (which is sometimes trivial).

Features
OpenRC does not require large, fundamental, changes to the traditional Unix-like system. OpenRC integrates with other system software as a component of of a modular and flexible system. It is designed to be fast, lightweight, easily configurable, and adaptable. OpenRC has only a few basic dependencies, on core system components.

As a modern init system, OpenRC provides a number of useful features:


 * cgroups support.
 * Process supervision.
 * Dependency-based launch, with parallel startup of services.
 * Automatic resolving, and ordering, of dependencies.
 * Hardware initiated initscripts.
 * Setting ulimit and nice values per service through the rc_ulimit variable.
 * Permits complex init scripts that start multiple components.
 * Modular architecture, fitting into existing infrastructure.
 * OpenRC has its own optional init system called openrc-init, see OpenRC/openrc-init for details.
 * OpenRC has its own optional process supervisor, see OpenRC/supervise-daemon for details.

See the comparison of init systems article for more information on init systems.

Documentation
OpenRC has it's own useful documentation, maintained by the OpenRC developers themselves. Be aware that Gentoo does not use all of OpenRC's functionality by default:
 * README
 * User Guide
 * OpenRC init process guide - How to use OpenRC's own init system (not used by default in Gentoo).
 * agetty guide - Setting up the agetty service in OpenRC (By default, ttys are spawned with sysvinit in Gentoo).
 * Using runit with OpenRC
 * Using S6 with OpenRC
 * Using supervise-daemon - Optional process supervision.
 * Using BusyBox with OpenRC
 * Service script writing guide - For developers or packagers.
 * NEWS - Important information about each release.
 * HISTORY - Histroy of how OpenRC came to be.

The main OpenRC configuration file,, contains extensive comments documenting OpenRC configuration.

Files

 * The global OpenRC configuration file.
 * The global OpenRC configuration file.


 * Contains configuration files for individual initscripts.
 * Contains configuration files for individual initscripts.

Logging
OpenRC doesn't log anything by default. To log OpenRC's output during boot, uncomment and set the rc_logger option in. The log will be saved at by default.

Network management
OpenRC can be used with one of several network managers or even with none. By default, with Gentoo's OpenRC profiles, netifrc scripts are utilized to manage network connections.

See the Network manager article for a list of options on network management.

Dependency behavior
Changing the default dependencies of init scripts, might be needed to fit more complex setups. See for how to change the default behavior; notice the rc_depend_strict option. In addition, next networking examples show how flexible OpenRC can be.

The SSH service must come up with the internal network, for instance eth0 and never wlan0.
 * Multiple network interfaces (example)

Overrule the "net" dependency from, and refine it to depend on "net.eth0":

The SSH service must start with eth0 (not wlan0) in "default" runlevel, but in "office" runlevel it must start with wlan0 (not eth0).
 * Multiple network interfaces in multiple runlevels (example)

Keep the default:

Make additional symlinks to with the network interface names:

Settings are read from and  now:

Add the dependencies:

In this example net.eth0 and net.wlan0 read their settings from, or depending on the active runlevel. Add all runscripts to the different runlevels:

To switch between "default" runlevel and "office" runlevel without rebooting the computer, change to "nonetwork" runlevel in between. The network interfaces will be stopped this way, and re-read their runlevel specific configuration. This works best when "nonetwork" is a stacked runlevel in both the "default" and "office" runlevels, and the display manager and other non-network services are added to the "nonetwork" runlevel only.

 default runlevel <---> nonetwork runlevel <---> office runlevel 

Selecting a specific runlevel at boot
OpenRC reads the kernel command-line used at boot time, and will start the runlevel specified by the softlevel parameter if provided. If no softlevel parameter is provided, the default runlevel will be used.

The following example shows a grub configuration allowing to choose to boot into either the default or nonetwork runlevels:

Runlevels
OpenRC can be controlled and configured using, and  commands.

Delete a service from default runlevel, where  is the name of the service to be removed:

Listing
Listing commands do not need to be ran as root.

Use to display all available init scripts and their current runlevel (if they have been added to one):

Running or  will display only the init scripts that have been added to a runlevel.

Alternatively, the command can be used with the    option to view the state of all services:

Named runlevels
OpenRC runlevels are directories living in to create additional runlevels is enough to issue:

Stacked runlevels
Is possible manage variants using.

An usage example for using stacked runlevel on laptop to group networking services based on location is at OpenRC/Stacked runlevel.

Prefix
Gentoo Prefix installs Gentoo within an offset, known as a prefix, allowing users to install Gentoo in another location in the filesystem hierarchy, hence avoiding conflicts. Next to this offset, Gentoo Prefix runs unprivileged, meaning no root user or rights are required to use it.

By using an offset (the "prefix" location), it is possible for many "alternative" user groups to benefit from a large part of the packages in the Gentoo Linux Portage tree. Currently users of the following systems successfully run Gentoo Prefix: Mac OS X on PPC and x86, Linux on x86, x86_64 and ia64, Solaris 10 on Sparc, Sparc/64, x86 and x86_64, FreeBSD on x86, AIX on PPC, Interix on x86, Windows on x86 (with the help of Interix), HP-UX on PARISC and ia64.

OpenRC runscript already support prefix-installed daemons, during the Summer of Code 2012 work will be done to implement full secondary/session daemon behavior to complete the overall feature set provided by Prefix.

OpenRC/Prefix, a tutorial for trying it out.

Hotplug
OpenRC can be triggered by external events, such as new hardware from udev. This is what the configuration file says about hotplugged services:

CGroups support
OpenRC starting with version 0.12 has extended cgroups support. See OpenRC/CGroups for details.

Chroot support
The system may report the following message upon attempting to start a service:

* WARNING: is already starting

This may be fixed by issuing the following command:

logind
Some setups require systemd-logind. Elogind can be a suitable replacement as a standalone logind running with OpenRC.

tmpfiles.d
systemd has a special tmpfiles.d file syntax for managing temporary files. provides a tmpfiles.d interpreter for OpenRC.

Both can also be used to manage volatile entries in or.

udev, eudev, and mdev
udev, eudev, and mdev are sytems available on Gentoo to manage. eudev is the default, and was created as part of the Gentoo project, but OpenRC should be able to work with any, on Gentoo.

Older Gentoo installs used udev as the main provider. Based on this was changed to eudev. However, the rc service is still.

See mdev, for possible use, e.g. for embedded systems.

BusyBox integration
N.B. This section lacks information on how to actually use BusyBox with OpenRC.

Please note that there are currently many BusyBox applets that are incompatible with OpenRC, see for details. Be warned that using OpenRC with BusyBox may require some work to set up. BusyBox is more adapted to embedded use, see previous section about mdev.

BusyBox can be used to replace most of the userspace utilities needed by OpenRC (, shell,, and other POSIX tools), by using a complete BusyBox as the shell for OpenRC , all the calls that normally would cause a fork/exec would be spared, improving the overall speed.

The SysV-init file provided by Gentoo is not compatible with the BusyBox. Here is an example inittab compatible with BusyBox:

BusyBox provides a number of applets that could be used to replace third party software like acpid or dhcp/dhcpcd.

See the OpenRC documentation on using BusyBox with OpenRC.

Respawning crashed services
OpenRC can return state of services to runlevel setting state, to provide stateful init scripts and automatic respawning.

To respawn crashed services from the default runlevel, run : crashed services will be started and any manually-run services will be stopped. To keep manually-started services running, run or, for short.

By default will attempt to start crashed services, not to restart them. This сontrolled by the rc_crashed_stop (default NO) and rc_crashed_start (default YES) options in.

Manually recovering crashed services
When a process crashes upon start, the following message will appear when checking its status.

To remedy this situation, zap the service: