So, let's begin with some overview of OpenRC.
OpenRC is not a replacement for the init binary, which is provided by sysvinit. Instead, it works in conjunction with it.
initscripts, systemd and OpenRC
Before 2012, Arch Linux used a custom BSD-Style init system called initscripts. But, according to the current set of Arch developers, initscripts weren't modern enough and were a chore to maintain.
There was a new kid in town called systemd, it was modern and provided a lot of features (all?) that made the developers drool.
The main reason for adopting systemd was — less effort on part of the developers as they no longer had to develop and maintain initscripts.
Another reason was that (theoretically) upstream developers would be providing systemd service files (required to run daemons and more) for their packages and hence distro packagers wouldn't have to write their custom service files. In reality, I don't think many software developers have started providing service files for their programs. But, this could change in the future.
Anyway, there was a proposal to incorporate OpenRC into Arch, but it was rejected.
So, why not use systemd?
Firstly, if initscripts weren't deprecated, I wouldn't have switched to OpenRC. But, since they were deprecated, I had to go shopping for a new init system.
The main reason for not using systemd is the philosophy behind it. It tries to do a lot for an init system, and feels very intrusive. It also tries to create a dependence on itself so that everyone is forced to use it. Case in point, udev merged into systemd (systemd-udevd), consolekit deprecated in favour of systemd-logind, etc. Currently, there are workarounds such as extracting udev from systemd, but for how long?
Also, I don't like how systemd handles logging. Binary logs... seriously? Also, by default it logs to a volatile file system, which again is a questionable decision. Thankfully, this can be changed to a non-volatile location.
There are some good things about systemd too, one of which is systemd-nspawn, which in simple terms is an alternative to chroot.
Note: I did try systemd for about a month, and there weren't many problems that I faced. It is still a very new technology undergoing heavy development, so there are many rough edges, which is to be expected. It just didn't have a feel good factor to it, due to the reasons listed above.
So, after ruling out systemd, I considered daemontools, runit and OpenRC. I settled for OpenRC, as it is the only one undergoing active development and I felt that it will require the least effort on my part.
Using OpenRC on Arch
If you intend to use pacman (Arch Linux's package manager), there are multiple options to install OpenRC.
Note: The following instructions pertain to the AUR packages only. Also, these packages will use
/etc/openrc instead of the default location of
Update - 03 June 2013: Arch Linux has gone forward with the /usr move, and the paths below have been updated accordingly.
So firstly, you need to install the openrc-sysvinit package, which is basically the usual sysvinit, but is patched to use
/etc/openrc/inittab instead of
/etc/inittab. Also, the binary is installed as
/usr/bin/init-openrc for legacy compatibility with initscripts. Since initscripts have been deprecated and removed from the Arch repositories, you can edit the PKGBUILD to install the binary as
/usr/bin/init, if you so wish.
Finally, you need to install the openrc-arch-services-git package which provides OpenRC service files and the associated configuration files for those services.
Configuration and Usage
With the installation complete, you need to add
init=/usr/bin/init-openrc to the kernel parameters of your bootloader configuration file. For example, my
/boot/syslinux/syslinux.cfg has the following:
LABEL arch MENU LABEL Arch Linux LINUX ../vmlinuz-linux APPEND root=UUID=12805cb8-5d77-90ad-84h1-674331l550g7 ro edd=off resume=/dev/sdb6 vga=792 init=/usr/bin/init-openrc INITRD ../initramfs-linux.img
After you have restarted the computer, you will boot into your pristine OpenRC installation.
There are four runlevels in OpenRC by default:
An Overview of the Important Commands
List the enabled services and the runlevels for which they have been enabled:
# rc-update show
Add a service to a specific runlevel:
# rc-update add <service> <runlevel>
Remove a service from a specific runlevel:
# rc-update remove <service> <runlevel>
The following steps are recommended to get a usable system
# rc-update add udev sysinit
Note: Since udev is now systemd-udevd and included in the systemd package, you need that package installed for it to work. So yeah, you cannot remove systemd from your system unless you want to extract udev from the systemd package.
You might want to enable a cron daemon too, I prefer dcron:
# rc-update add dcron default
# rc-update add dbus default
# rc-update add alsa default
# rc-update add syslog-ng default
List the status of services for the current runlevel:
List the status of services for all the runlevels:
# rc-status --all
List the services which have crashed:
# rc-status --crashed
List all the available services:
Manually start a specific service:
rc-service <service> start
Manually stop a specific service:
rc-service <service> stop
Configuring the System
Most of the configuration is done through:
Files under the
Note: From this point on I will refer to
/etc/openrc/conf.d as simply
Some important settings and locations
Set hostname using
Configure the hardware clock through
Locale can be specified through
/etc/locale.conffor system-wide effect, or through
~/.bashrcfor a particular user.
conf.d/sysctl.ddirectory to configure the kernel parameters, instead of
Specify modules to be loaded during boot in
Blacklisting of modules is done through
Configure the network through
Since Arch mounts
/tmpas tmpfs by default, OpenRC gives an error while unmounting
/tmpduring shutdown. Solve it by adding the following to
To start X automatically:
Enable autologin to a tty through
/etc/openrc/inittabwith something like:
c6:2345:respawn:/usr/bin/agetty -a <username> -8 -s 38400 tty6 linux
Put the following in
[[ -f ~/.bashrc ]] && . ~/.bashrc # start x on login if [[ -z $DISPLAY && ! -e /tmp/.X11-unix/X0 ]]; then exec xinit -- /usr/bin/X -nolisten tcp vt7 fi
In case you need a service file which is not present in the openrc-arch-services-git package, you have the following options.
Search for it in udeved's repo here.
I have added a few of my own. You can find them here.
Search for it in Gentoo's repositories.
Write one yourself. For help with this, take a look at
man runscriptand also study existing scripts.
If you need assistance with using OpenRC on Arch, you can ask for help on this thread at the Arch Linux Forums.
There's an OpenRC page available on the Arch Wiki too.
If you want to try something other than systemd, OpenRC is worth giving a shot. I have been using OpenRC on Arch for the past few months, and it hasn't given me any trouble. That said, I don't see OpenRC gaining more traction on Arch, but if things remain more or less the same as they are presently, there is no reason for me to move away from it.
As time progresses, more and more distributions will be switching to systemd. Even Debian would have done so already, were it not for projects such as Debian GNU/kFreeBSD. It remains to be seen how much choice will be available to us in the coming months, and if options run out, I may have to switch to systemd.
As I have said before, I am not totally against systemd. But it is not fully mature yet, and I am not willing to help test something I am not too fond of. A few months down the line may be a different story.
Either way, I am not moving away from Linux in the foreseeable future. After all, an init system isn't enough to drive me away from Arch Linux in particular, or for that matter, Linux in general.