Skip to content
Home » OpenRC


OpenRC is a dependency-based init system that was designed to work with Unix-like computer operating systems. It keeps compatibility with the system-provided init system, which is usually found in /sbin/init. Also it manages the entire system’s startup and shutdown, including services.

It consists of various modular components. The most important ones are: an init, a core dependency management system, and a daemon supervisor. It’s written in C and uses a POSIX-compliant shell, so it will run on BSD systems and Linux.

OpenRC will start the required system services in the right order at boot, handle them while the system is running, and shut them down when the system finished. It can manage daemons installed from the Gentoo repository, monitor the processes it launches, and start processes in parallel (where possible) to save boot time.

Installation and configuration

The commands for installing openrc are:

  • sudo apt-get update
  • sudo apt-get install openrc

The name of the OpenRC service package is “package name-openrc”, which is generally found in /etc/init.d, and the name of the OpenRC service package is /etc/rc.conf.

By default, OpenRC does not log anything. Uncomment and set the RC logger option in /etc/rc.conf to log OpenRC’s output on boot. By default, the log will be saved to /var/log/rc.log.
FILE /etc/rc.conf:

Network management

You can use OpenRC with any of the various network managers, or with none at all. For examples of static and dynamic network configuration, see /etc/conf.d/net. The netifrc package contains a set of modules for setting and managing network interfaces through separate scripts in the /etc/init.d/ directory. It just includes /etc/init.d/net.lo (for the loopback interface), but it doesn’t include any hard-coded operations. The same piece can handle several interfaces (as net.interface name -> net.lo) as a cost-effective alternative to deploying numerous scripts. OpenRC does not require Netifrc. You can leave it unused in favor of another network manager.

In order to accommodate more complex installations, it may be necessary to change the default dependencies of init scripts. To change the default behavior, go to /etc/rc.conf and look for the rc depending on the strict option. In addition, the following networking examples demonstrate OpenRC’s versatility.

If the softlevel argument is given, OpenRC will start the runlevel defined by the softlevel parameter instead of the default. With the following example grub.conf settings, you can choose whether to boot into the default, nonetwork, or single-user runlevels:

    FILE /boot/grub/grub.conf:
 title = Regular start-up
 kernel (hd0,0)/boot/vmlinuz-linux root=/dev/sda3
 title = Start without networking
 kernel (hd0,0)/boot/vmlinuz-linux root=/dev/sda3 softlevel=nonetwork
 title = Single-user mode
 kernel (hd0,0)/boot/vmlinuz-linux root=/dev/sda3 softlevel=single


OpenRC uses Runlevels in a similar way to sysvinit (or BSD init). At any given time, the system is in one of the defined runlevels. Three internal runlevels and four user-defined runlevels are available.

Internal runlevels, the names are self-explanatory:

  • sysinit
  • shutdown
  • reboot

User Runlevels:

  • boot: Starts all system-necessary services for other runlevels
  • default: Used for day-to-day-operations
  • nonetwork: Used when no network connectivity is required
  • single: Single-user mode
 You can use the openrc command to change the system`s runlevel, e.g.: Openrc nonetwork.

The OpenRC commands

To control and configure OpenRC rc-service, rc-update, and rc-status can be used to control and configure OpenRC.

Adding services to runlevels and removing services from runlevels:

  • # rc-update add service runlevel
  • # rc-update del service runlevel


Start, restart and stop service:

  • # rc-service service start
  • # rc-service service restart
  • # rc-service service stop


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

  • # rc-update show -v


View the state of all services:

  • # rc-status –servicelist


Check failed services:

  • # rc-status –crashed

Orphaned processes

It’s common to find yourself in a state where orphaned processes are working, processes that were previously part of a service. For example, suppose you’re using a supervise daemon to monitor a service and it dies for no apparent cause. Each system will have a different approach to dealing with this.

The cgroup cleanup command is added to all services on Linux systems with cgroups enabled. When the service stops, you can manually run it by typing:

  • # rc-service someservice cgroup_cleanup

To make this happen automatically when the service is ended, set the rc cgroup cleanup parameter to yes.


Other functions of OpenRC

The rc_ulimit variable can be used to set ulimit and nice values per service.

OpenRC may also use cgroups for process management on Linux. The rc_cgroup_mode parameter in /etc/rc.conf should be used to control whether cgroups version one, two, or both are utilized after the kernel has been configured properly. If both are accessible, the default is to use both.

You can apply limit per service by modifying certain settings in the conf.d file. The default /etc/rc.conf under LINUX CGROUPS RESOURCE MANAGEMENT documents these settings in great detail.

Many typical output tasks in libeinfo have wrappers in OpenRC. This enables the printing of color-coded status messages and other information. The bundled service scripts all use ebegin/eend to print nice messages to keep the output consistent.


Advanced Usage

Custom Runlevels
  • Creating

An enabled service is a symlink to the init.d file, and a runlevel is merely a directory in /etc/runlevels. Adding the sshd service to the default runlevel, for example, involves creating a symlink in /etc/runlevels/ default to /etc/init.d/sshd. As a result, creating a new runlevel necessitates the creation of a new directory under /etc/runlevels.

  • Stacking

When switching to the office runlevel, you usually don’t want to disable all of your default services. Runlevel “inheritance” is achieved by stacking runlevels. You can actually add a runlevel to a runlevel if you use the -s flag with rc-update. For example, if you wanted to set up an office runlevel that was the same as default but included the myvpn service, you would perform the following:

					# mkdir /etc/runlevels/office
# rc-update -s add default office
# rc-update add myvpn office
  • Switching

You can use the openrc command to switch to a custom runlevel once you’ve created one. You would use openrc office to switch to your new runlevel, and openrc default to switch back, as shown above.


The SSH service must connect to the internal network, such as eth0, rather than wlan0. Remove the net dependence from /etc/init.d/sshd and replace it with net.eth0:

rc_need="!net net.eth0"


In the “default” runlevel, the SSH service must start with eth0 (not wlan0), however in the “office” runlevel, it must start with wlan0 (not eth0).

# rc_depend_strict="YES"


Make symlinks to sshd with the names of the network interfaces:

					# ln -s sshd /etc/init.d/sshd.eth0
# ln -s sshd /etc/init.d/sshd.wlan0


/etc/conf.d/sshd.eth0 and /etc/conf.d/sshd.wlan0 are now read for settings:

					# cp /etc/conf.d/sshd /etc/conf.d/sshd.eth0
# cp /etc/conf.d/sshd /etc/conf.d/sshd.wlan0


Add the dependencies:

					# echo 'rc_need="!net net.eth0"' >> /etc/conf.d/sshd.eth0
# echo 'rc_need="!net net.wlan0"' >> /etc/conf.d/sshd.wlan0


Depending on the active runlevel, net.eth0 and net.wlan0 read their settings from /etc/conf.d/net or /etc/conf.d/
Add all of the runscripts to the various runlevels:

# rc-update add sshd.eth0 default
# rc-update add sshd.wlan0 office
# rc-update add net.eth0 default office
# rc-update add net.wlan0 default office


Change to “nonetwork” runlevel in between “default” and “office” runlevels to avoid having to reboot the computer. This will stop the network interfaces and force them to re-read their runlevel-specific configuration. The display manager and other non-network services should be added to the “nonetwork” runlevel only.
nonetwork runlevel —> default runlevel runlevel office

					# rc nonetwork && rc office
# rc nonetwork && rc default

  • Respawning crashed services

To provide stateful init scripts and automatic respawning, OpenRC can return the state of services to the runlevel setting state.
Run openrc: crashed services will be started and any manually-run services will be terminated to respawn crashed services from the default runlevel. Run openrc –no-stop or openrc -n to keep manually started services running.
By default, openrc will seek to launch, rather than restart, crashed services. The /etc/rc.conf parameters rc crashed stop (default NO) and rc crashed start (default YES) regulate this.

  • Recovering crashed services manually

When attempting to start, terminate, or show the status of a service after it has crashed during starting, an error or warning message will be printed. When utilizing the “docker” service, for example:

					root #rc-service docker status
 * status: crashed

root #rc-service docker start
 * WARNING: docker has already been started

root #rc-service docker stop
 * Caching service dependencies ...                                         [ ok ]
 * Stopping docker ...
 * Failed to stop docker                                                	[ !! ]
 * ERROR: docker failed to stop


To fix the problem, zap the service:

					root #rc-service docker zap

See other articles:

QEMU development during Global Chip Shortage

QEMU Development

Considering the current developments in the global market, especially having the issue of a Global Chip Shortage, there are some issues to be addressed

Read More »

Yocto Devtool

A command-line utility by the name of devtool serves as the foundation of the extensible SDK. With the help of this tool, you may

Read More »

Advantages of Outsourcing

Nowadays, most embedded systems have functionalities implemented in software. The usage of embedded software by electronics manufacturers for expanded functionality, improved quality, and reusability

Read More »

Yocto Project

Yocto Project is an open source community project that helps developers to create customized systems based on Linux. It has an accessible toolset that

Read More »

Software testing

The investigation of artifacts and the behavior of the software under test is known as software testing. It also determines whether the actual results

Read More »

Leave a Reply

Your email address will not be published.