Artix Linux Init Choice: OpenRC, runit, s6, or dinit in Practice

The problem: inheriting an init system you did not audit

You install Artix Linux on a small VPS, expecting a systemd-free base. The installer gives you OpenRC by default. Later you realize your workload needs a different supervision model, or you inherited a host where the init choice was made for you. The useful takeaway: Artix lets you select among several init systems, but the choice affects boot scripts, service commands, and logging. Switching on a running system is a state-changing operation that can break enabled services, so verify what is running before you install anything.

Match the service model to the host, not the marketing

Artix is a pacman-based distribution that keeps systemd out of the base and maintains its own repositories for init-specific packages. The distribution has offered OpenRC, runit, s6, and dinit variants. Confirm the current list in the official Artix installation media or wiki before deployment.

Init system	Service model	Common management command
OpenRC	Shell scripts in /etc/init.d, with runlevels	rc-service, rc-update
runit	Service directories under /etc/sv, enabled by symlink	sv
s6	Supervision suite with small composable tools	s6-rc or s6-svscan (varies by setup)
dinit	Declarative service descriptions with dependencies	dinitctl

Each model changes how you inspect state. If you come from systemd, expect different commands and no unit files by default.

Check what is running before you install anything

Run this on the Artix host as any user:

ps -p 1 -o comm=

Expected output is the name of PID 1. Depending on the variant, this may be openrc-init, runit, s6-svscan, dinit, or systemd. If it prints systemd, the base is not the systemd-free variant you assumed.

To see whether an Artix init meta-package exists in your configured repositories, run as root or with sudo:

pacman -Ss artix-openrc

Replace artix-openrc with artix-runit, artix-s6, or artix-dinit for other variants. A match confirms the package is available in your repositories; it does not mean it is safe to switch on a production host without testing.

Risk: installing an init meta-package changes system state and can pull in conflicting packages. Do not remove systemd unless you have confirmed nothing else depends on it.

Worked example: enabling sshd

Once you have chosen an init system, enabling a service looks different for each one.

OpenRC (run as root):

rc-update add sshd default
rc-service sshd start

runit (run as root):

ln -s /etc/sv/sshd /var/service/
sv status sshd

The runit example creates a symbolic link from the service definition to the supervised service directory. The sv command then reports whether sshd is running.

If you switch init systems later, previously enabled services do not automatically carry over. You must re-enable them under the new manager and, depending on the bootloader, adjust the kernel command line or init entry.

Limitation: Arch packages are not always Artix-safe

Artix is largely compatible with Arch user repositories, but not all AUR packages build cleanly on Artix. Some assume systemd units or systemd-tmpfiles. Before deploying a package, inspect its dependencies and check whether it installs systemd-specific files.

Community documentation is smaller than for mainstream systemd distributions, so troubleshooting may require reading upstream manuals for the init system you chose.

Practical check and closing

After installing or switching an init system, reboot and verify:

1. Run ps -p 1 -o comm= and confirm it matches your chosen init.
2. List supervised services. For OpenRC, use rc-update show or rc-status to see enabled runlevels. For runit, inspect /var/service.
3. Test that critical services such as sshd start on boot without manual intervention.

If you are changing init on an existing server, test the migration in a virtual machine first. Rollback is not a single package reinstall: you must reinstall the previous init meta-package, re-enable its services, update the bootloader configuration if needed, and resolve any dependency conflicts that the switch introduced.

Artix gives you a supported, systemd-free engineering choice. Pick the init system that fits the host, verify PID 1 after boot, and treat the switch as a state-changing operation, not a drop-in swap.