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 is 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 used to install openrc are:

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

The name of the OpenRC service package is “package name-openrc”, which is usually 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 is 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 prove OpenRC’s versatility.

If the soft level 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 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. For example: Openrc nonetwork.

The OpenRC commands

There are multiple commands that you can use to control and configure OpenRC.

Add and remove services:
  • # 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:
  • # 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

Set the rc cgroup cleanup parameter to yes to make this happen automatically when the service ends.

Other functions of OpenRC

You can use the rc_ulimit variable to set ulimit and nice values per service.

OpenRC may also use cgroups for process management on Linux. You should use the rc_cgroup_mode parameter in /etc/rc.conf  to control whether cgroups version one, two, or both are used 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 to print 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. You can actually add a runlevel to another 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. Also, 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 office

      To fix the problem, zap the service:

      					# 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 ended 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 you want to start, end, or show the status of a service after it has crashed during starting, an error or warning message will appear. For example, when using the “docker” service:

          					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:

          software testing

          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 »
          component placement

          Component placement  

          Component placement is one of the most critical parts of PCB design. First, you must understand the fundamental criteria for arranging components on a

          Read More »

          Linux System Programming

          This article focuses on Linux system calls and other low-level operations, such as the C library’s functions. System programming is the process of creating system software, which

          Read More »
          emc testing

          EMC Testing

          When an electrical product is tested for electromagnetic compatibility (EMC) it is determined whether or not it will perform satisfactorily in the electromagnetic environment

          Read More »

          BSP Development Process

          Every board comes with a base BSP (Board Support Package) from the manufacturers. However, in most cases, different levels of customization must meet the

          Read More »

          BSP Development Costs

          The Board Support Package (BSP) represents the software link layer that allows, traditionally a real-time operating system (RTOS), to run on a particular hardware

          Read More »

          Leave a Reply

          Your email address will not be published. Required fields are marked *

          This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.