Switching Artix Linux to runit: A Practical Init System Migration Guide

If you need to move an Artix Linux installation from OpenRC to runit—or simply decide which init system to standardize on—the safe path is to change one variable in /etc/rc.conf, install the matching supervisor packages, and make sure no previous init system remains enabled. Artix deliberately separates the base operating system from the init system, so the switch is a configuration change rather than a rebuild. The main risk is leaving two supervisors active, which can stop the machine before it reaches a login prompt.

How Artix Selects Its Init System

An init system is the first user-space process the Linux kernel starts; it runs as PID 1. Its job is to mount filesystems, start daemons, and supervise them so they restart if they crash. A supervisor is the part of the init system that watches individual services.

Artix packages the base system independently of the init system. At install time you can choose OpenRC, runit, s6, or sysvinit. After installation, the choice is stored in /etc/rc.conf as the INITSYSTEM variable. The boot process reads that value and launches the corresponding supervisor as PID 1.

Worked Example: Switching from OpenRC to runit

Moving to runit requires three coordinated changes: install the runit supervisor, point /etc/rc.conf at runit, and create the symlink that activates the runit service tree. Run all commands in a terminal with sudo unless noted.

1. Ensure the artix-runit repository is enabled in /etc/pacman.conf, then install the supervisor package:

   sudo pacman -Syu runit

2. Edit the init selection file:

   sudoedit /etc/rc.conf

   Set the value so the file contains exactly one active assignment:

   INITSYSTEM=runit

   Remove or comment out any other INITSYSTEM lines. Leaving two values causes the boot process to start two supervisors, leading to resource conflicts and a possible failure to reach a login prompt.
3. Activate the runit service tree:

   sudo ln -sf /etc/runit/runsvdir/default /etc/runit/runsvdir/current

4. Reboot:

   sudo reboot

After the system returns, confirm that runit is PID 1. Run this as any user:

ps -p 1 -o comm=

The expected result is the string runit. If the output is openrc, init, or anything else, the switch did not take effect.

Supervising Services That Lack Native runit Scripts

Not every daemon in the Artix repositories ships a native runit or s6 service script. Coverage varies by init system; OpenRC typically has the broadest set of packaged service files in Artix, while runit and s6 may require custom directories for some daemons.

A runit service directory is a folder containing an executable script named run. For a hypothetical daemon called <service-name>, create the directory and script:

sudo mkdir -p /etc/sv/<service-name>

Then write /etc/sv/<service-name>/run with contents similar to:

#!/bin/sh
exec 2>&1
exec /usr/bin/<service-name> --config /etc/<service-name>.conf

Make the script executable:

sudo chmod +x /etc/sv/<service-name>/run

Runit skips service directories silently if the run script is not executable or if it lacks a final exec line. The exec line replaces the shell process with the daemon so that runit can signal and supervise the actual service rather than a wrapper shell.

Common Mistakes and Boot Failure Modes

• Multiple INITSYSTEM values. If /etc/rc.conf contains both INITSYSTEM=openrc and INITSYSTEM=runit, the boot process may start two supervisors. This produces resource conflicts and can prevent the system from reaching a login prompt.
• Leftover enabled services. Disabling the old init system packages is not always enough. If OpenRC services remain enabled in the default runlevel while runit is also active, the two supervisors can fight over the same daemons.
• Silent custom-service failures. A runit service directory with a non-executable run script, or one that ends without exec, is ignored without an obvious error. The service simply does not appear under runit control.
• Missing repository configuration. Installing runit without the artix-runit repository enabled can pull an incomplete set of packages or fail to provide the Artix-specific integration files.

Rolling Back to the Previous Init System

Because switching init systems changes boot-time state, rollback is a real operation, not just a package removal. To return to OpenRC:

1. Set INITSYSTEM=openrc in /etc/rc.conf and remove any other values.
2. Remove the runit service-tree symlink:

   sudo rm /etc/runit/runsvdir/current

3. Ensure the openrc package is installed:

   sudo pacman -S openrc

4. Reboot and verify with ps -p 1 -o comm=; the output should be openrc.

Verifying the Result and Checking Logs

Besides ps -p 1 -o comm=, use the supervisor's own status tool to confirm services are managed by the chosen init system:

• For runit: sv status /run/service/*
• For OpenRC: rc-status
• For s6: s6-svstat /run/service/*

Review boot logs for missing init-script errors. Depending on your logging configuration, check /var/log/boot.log or the system journal. The absence of errors about missing init scripts is a good sign that the switch completed cleanly.

Limitations to Keep in Mind

Artix's multi-init support is a packaging and configuration feature, not a guarantee that every service has a first-class script for every supervisor. Before committing a production machine to runit or s6, inventory the daemons you actually run and confirm that native service files exist or that you are prepared to maintain custom service directories. Switching is also not a hot operation: it requires a reboot, and a mistake can leave the machine unbootable until you rescue it from installation media or an existing bootloader entry.