OpenRC: Difference between revisions
Prabuanand (talk | contribs) m (reworded sentence) |
Prabuanand (talk | contribs) (reworded sentence and links to make easier to follow, fixed typo) |
||
Line 1: | Line 1: | ||
Alpine Linux uses [https://github.com/OpenRC/ openrc] for its init system. | Alpine Linux uses [https://github.com/OpenRC/ openrc] for its init system. The init system manages the services, startup and shutdown of your computer. | ||
To learn the basics of OpenRC quickly, refer to the [https://docs.alpinelinux.org/user-handbook/0.1a/Working/openrc.html working with OpenRC] guide from Alpine Linux documentation project. | |||
== Quickstart == | == Quickstart == | ||
Line 85: | Line 85: | ||
=== Stacked runlevels === | === Stacked runlevels === | ||
Stacked runlevels allows "inheritance" of services. A few use cases are given below: | |||
* [https://docs.alpinelinux.org/user-handbook/0.1a/Working/openrc.html#_runlevel_stacking Running an office runlevel with VPN service] | |||
* [[#Preventing slow services from delaying boot|Preventing slow services from delaying boot]] | |||
For more detailed information, refer [https://wiki.gentoo.org/wiki/OpenRC/Stacked%20runlevel Gentoo wiki]. | |||
== Configuration == | == Configuration == | ||
Line 95: | Line 98: | ||
=== Cgroups === | === Cgroups === | ||
OpenRC supports cgroups v2 in the default configuration. To enable hybrid cgroups, edit the file {{Path|/etc/rc.conf}} and change the setting for {{ic|rc_cgroup_mode}} as follows:{{Cat|/etc/rc.conf|rc_cgroup_mode{{=}}"hybrid"}} | |||
Then you should run {{Cmd|# rc-service cgroups start}} | Then you should run {{Cmd|# rc-service cgroups start}} | ||
Line 161: | Line 164: | ||
Services that take a while to start will block the boot process until they complete. E.g.: <code>iwd</code> and <code>networking</code> might delay startup of an interactive system rather than start in the background. | Services that take a while to start will block the boot process until they complete. E.g.: <code>iwd</code> and <code>networking</code> might delay startup of an interactive system rather than start in the background. | ||
This can be remedied as per Patrycja's blog post titled [https://ptrcnull.me/posts/openrc-async-services/ OpenRC: Start services after login prompt | This can be remedied using [[#Stacked runlevels|stacked runlevels]] as per Patrycja's blog post titled [https://ptrcnull.me/posts/openrc-async-services/ OpenRC: Start services after login prompt]. | ||
{{Warning|If the file {{Path|'''/etc/inittab'''}} is edited wrongly, the system may not boot. Take backup and learn how to restore using rescue disk before proceeding.}} | {{Warning|If the file {{Path|'''/etc/inittab'''}} is edited wrongly, the system may not boot. Take backup and learn how to restore using rescue disk before proceeding.}} | ||
# Create a custom runlevel '''async''': {{Cmd|# mkdir /etc/runlevels/async}} | |||
# Add default as a stacked runlevel {{Cmd|# rc-update add -s default async}} | |||
# Remove slow services from default and add them to async {{Cmd|<nowiki># rc-update del chronyd default | |||
# rc-update add chronyd async </nowiki>}} | # rc-update add chronyd async </nowiki>}} | ||
# Add changing of runlevel to async by adding the line '''::once:/sbin/openrc async''' to {{Path|/etc/inittab}} file as follows: {{Cat|/etc/inittab|<nowiki>... | |||
::wait:/sbin/openrc default | ::wait:/sbin/openrc default | ||
::once:/sbin/openrc async -q | ::once:/sbin/openrc async -q | ||
Line 178: | Line 178: | ||
tty1::respawn:/sbin/getty 38400 tty1 | tty1::respawn:/sbin/getty 38400 tty1 | ||
...</nowiki>}} | ...</nowiki>}} | ||
After rebooting, services from async will start separately. | After rebooting, services from async will start separately. Other services started in default runlevel may still block agetty from running, due to the wait label. | ||
== Command usage == | == Command usage == |
Revision as of 10:01, 3 August 2025
Alpine Linux uses openrc for its init system. The init system manages the services, startup and shutdown of your computer.
To learn the basics of OpenRC quickly, refer to the working with OpenRC guide from Alpine Linux documentation project.
Quickstart
Action | Command | |
Managing a service - start,stop and restart | ||
Start <serviceName> now | # rc-service <serviceName> start
| |
Stop <serviceName> now | # rc-service <serviceName> stop
| |
Restart <serviceName> now | # rc-service <serviceName> restart
| |
Adding and removing service from runlevels | ||
Add <serviceName> to <runlevel> | # rc-update add <serviceName> <runlevel>
| |
Remove <serviceName> from <runlevel> | # rc-update del <serviceName> <runlevel>
| |
Check services in a runlevel and their status | ||
To check status of <serviceName> | $ rc-service <serviceName> status
| |
To view services configured at <runlevel> | $ rc-update show <runlevel>
| |
To view currently active runlevels and state of services | $ rc-status
| |
Check and manage runlevels | ||
To view available runlevels | $ rc-status -l
| |
To change to a different <runlevel> | $ openrc <runlevel>
| |
Stacked runlevels | ||
To add <s-runlevel> as a stacked <runlevel> | # rc-update add -s <s-runlevel> <runlevel>
| |
User Services - adding -U or --user to most of above commands should work | ||
To view currently active User runlevels and state of User services | $ rc-status -U
| |
To change to a different user <runlevel> | $ openrc -U <runlevel>
| |
Add User <serviceName> to user <runlevel> | $ rc-update -U add <serviceName> <runlevel>
| |
Command Usage - add -h or --help to all commands | ||
To view command usage for all openrc commands | $ rc-status -h or $ rc-status --help
|
Runlevels
A runlevel is basically a collection of services that needs to be started. Instead of random numbers they are named, and users can create their own if needed. The default startup uses the runlevels sysinit, boot, and default, in that order. Shutdown uses the shutdown runlevel.
The available runlevels are:
- default - Used if no runlevel is specified. (This is generally the runlevel you want to add services to.)
- hotplugged
- manual
The special runlevels are:
- sysinit - Brings up system specific stuff such as
/dev
,/proc
and optionally/sys
for Linux based systems. It also mounts/lib/rc/init.d
as a ramdisk using tmpfs where available unless/
is mounted rw at boot.rc
uses/lib/rc/init.d
to hold state information about the services it runs. sysinit always runs when the host first starts and should not be run again. - boot - Generally the only services you should add to the boot runlevel are those which deal with the mounting of filesystems, set the initial state of attached peripherals and logging. Hotplugged services are added to the boot runlevel by the system. All services in the boot and sysinit runlevels are automatically included in all other runlevels except for those listed here.
- single - Stops all services except for those in the sysinit runlevel.
- reboot - Changes to the shutdown runlevel and then reboots the host.
- shutdown - Changes to the shutdown runlevel and then halts the host.
Stacked runlevels
Stacked runlevels allows "inheritance" of services. A few use cases are given below:
For more detailed information, refer Gentoo wiki.
Configuration
The main configuration file for OpenRC is /etc/rc.conf. The OpenRC service scripts for each service can be found at /etc/init.d/ and their respective service configuration files at /etc/conf.d/.
If the setting rc_parallel="YES" is configured, the OpenRC system tries to start services in parallel for a slight speed improvement. This setting however comes with a message from openRC developers:

To improve boot times, consider the idea suggested in the preventing slow services from delaying boot section.
Cgroups
OpenRC supports cgroups v2 in the default configuration. To enable hybrid cgroups, edit the file /etc/rc.conf and change the setting for rc_cgroup_mode
as follows:
Contents of /etc/rc.conf
Then you should run
# rc-service cgroups start
to take effect and
# rc-update add cgroups
to auto mount the cgroup filesystem on boot.
User services
OpenRC supports managing services for users. User services are currently experimental and available from v3.22 for the following:
Prerequisites
- XDG_RUNTIME_DIR variable must be set
Config files
OpenRC uses ~/.config, if $XDG_CONFIG_HOME is unset. Adjust below instructions, if $XDG_CONFIG_HOME differs.
The main configuration file for OpenRC User services for a specific user is ~/.config/rc/rc.conf. The folder ~/.config/rc/runlevels/ contains the runlevels for OpenRC user services.
The service scripts for each OpenRC user service provided as part of official packages can be found at /etc/user/init.d/ and their respective service configuration files at /etc/user/conf.d/.
The folders ~/.config/rc/init.d/ and ~/.config/rc/conf.d/ have customized service scripts for User services files and their respective configuration files.
Configure environment variables
For Wayland
Allow propagation of the WAYLAND_DISPLAY environment variables by adding the following lines to file ~/.config/rc/rc.conf as follows:
Contents of ~/.config/rc/rc.conf
For Xorg
If Elogind is not used, ensure that XDG_RUNTIME_DIR is set manually in ~/.xinitrc. For eg, for dwm add:
Contents of ~/.xinitrc
User service management
Issue the command $ rc-status -Ur
to view and verify the name of the current user runlevel before proceeding.
To start PipeWire user service, issue the command:
$ rc-update -U pipewire start
Verify that the above OpenRC user service is started before proceeding further:
$ rc-status -U
To enable PipeWire user service, issue the command:
$ rc-update -U add pipewire
The above steps can be repeated for other User services like pipewire-pulse
, wlsunset
etc
PAM support
The default installation of OpenRC user services is without PAM support. To ensure that user services do not linger on logout, enable PAM support for OpenRC user services by installing the openrc-user-pam package.
# apk add openrc-user-pam
Preventing slow services from delaying boot
Services that take a while to start will block the boot process until they complete. E.g.: iwd
and networking
might delay startup of an interactive system rather than start in the background.
This can be remedied using stacked runlevels as per Patrycja's blog post titled OpenRC: Start services after login prompt.

- Create a custom runlevel async:
# mkdir /etc/runlevels/async
- Add default as a stacked runlevel
# rc-update add -s default async
- Remove slow services from default and add them to async
# rc-update del chronyd default # rc-update add chronyd async
- Add changing of runlevel to async by adding the line ::once:/sbin/openrc async to /etc/inittab file as follows:
Contents of /etc/inittab
... ::wait:/sbin/openrc default ::once:/sbin/openrc async -q # Set up a couple of getty's tty1::respawn:/sbin/getty 38400 tty1 ...
After rebooting, services from async will start separately. Other services started in default runlevel may still block agetty from running, due to the wait label.
Command usage
To view the command usage for all OpenRC commands (rc-update, rc-service, rc-status, openrc etc.) either use --help or (-h) flag. For eg:$ rc-update --help
or $ rc-update -h
will show usage information for rc-update
.
The busybox command equivalent for traditional GNU/Linux systems is as follows:
# reboot # ⇔ shutdown now -r # halt # ⇔ shutdown now -H # poweroff # ⇔ shutdown now -P
Troubleshooting
Whenever a openRC service fails to run, to troubleshoot enable debugging option and run the command.
For example, if running the command rc-service greetd start
causes greetd service to immediately crash, then alter the command to enable and view the debug:
# rc-service -d greetd restart
XDG_RUNTIME_DIR unset
While configuring user services, running the command $ doas rc-update add -U pipewire gui
will generate the above error XDG_RUNTIME_DIR unset
. Always issue the command as normal user $ rc-update add -U pipewire gui
and do NOT use doas
.
ERROR: user.greetd failed to start
While using user services with greetd, the above error message will appear. This failed error message for user.greetd
service is harmless as per !81612#note_492385.