Running OpenRC on Artix Linux: What the Service Scripts Actually Buy You

The problem: you want Arch's packages without systemd as PID 1

If you like Arch's rolling-release package freshness but don't want systemd as your init system, Artix is one of the few distributions that treats this as a first-class choice rather than a hack. Artix ships ISOs built around several init systems — OpenRC, runit, s6, and dinit — and the OpenRC variant is the one that feels most familiar if you've used Gentoo or Alpine.

The thesis of this post: OpenRC on Artix is worth choosing when you value readable, auditable service management over the integrated feature set of systemd. It's a real trade, not a free win, and the worked example below shows exactly what you're signing up for.

How OpenRC manages services

OpenRC keeps the traditional Unix split: a small PID 1 (sysvinit's init on Artix's OpenRC edition) starts OpenRC, which then runs service scripts. Services live as executable shell scripts in /etc/init.d/, and instead of systemd's unit dependency graph, each script declares its ordering needs in a depend() function:

depend() {
    need net
    use logger
}

need means "must be started before me"; use means "start before me if it's enabled, but don't fail if it isn't." Runlevels (like default and boot) group which services start together. The three commands you'll use daily:

• rc-service <name> start|stop|restart|status — control one service now
• rc-update add|del <name> <runlevel> — enable or disable at boot
• rc-status -a — see every runlevel and what's running, stopped, or crashed

All of these run as root (or via sudo/doas) on the Artix machine itself. Nothing here requires network access or a reboot.

Worked example: wrapping a small daemon

Say you have a small daemon binary at /usr/local/bin/weatherd that you want supervised at boot. Create /etc/init.d/weatherd as root:

#!/sbin/openrc-run

command=/usr/local/bin/weatherd
command_args="--config /etc/weatherd.conf"
command_background=true
pidfile=/run/weatherd.pid

depend() {
    need net
}

The shebang #!/sbin/openrc-run is what makes OpenRC interpret the script. command_background=true tells OpenRC to daemonize the process itself and track it via the pidfile — handy when the program has no built-in daemon mode. Then:

chmod +x /etc/init.d/weatherd
rc-update add weatherd default
rc-service weatherd start
rc-service weatherd status

Expected result: status reports the service as started, and rc-status default lists it. After a reboot, confirm it came back with rc-status default again. If startup ordering looks wrong, check /var/log/rc.log (enable rc logging in /etc/rc.conf if it isn't already) plus whatever logging your daemon does itself.

One caveat: I haven't run this exact script against a current Artix snapshot — Artix is rolling-release, so verify paths like /sbin/openrc-run on your installation before copying anything verbatim.

The trade-off

The appeal is transparency: every service is a shell script you can read end to end, and debugging a boot problem usually means reading one file rather than querying a journal and a dependency graph. The cost is real, though:

• Most upstream projects ship systemd units, not OpenRC scripts. Artix maintains -openrc companion packages for common daemons, but coverage can lag behind Arch's package updates, and occasionally you'll write or adapt a script yourself.
• Features people associate with systemd — socket activation, unified cgroup-based resource limits per service, systemd-run-style transient units — don't exist here. You replace them with cron, ulimit, or explicit design, or you go without.
• OpenRC's supervision is lighter than runit or s6. If automatic restart-on-crash matters more than script readability, Artix's runit edition may fit better.

Verify before you commit

Before assuming you're on the OpenRC edition, check PID 1: ps -p 1 -o comm= should print init, not systemd. Then compare rc-update show against the scripts actually present in /etc/init.d/ — drift between the two is a common source of "why didn't that start?" moments after package changes.

The actionable takeaway: pick a daemon you actually run, write a ten-line /etc/init.d script for it using the pattern above, and reboot once. If reading and fixing that script felt easier than debugging a unit file, OpenRC on Artix is doing its job for you.