Why runit on Artix Linux Is a Sane Way to Supervise Services

If you've ever debugged a service that silently died at 3 a.m., you know the real question isn't "how do I start this daemon" — it's "who notices when it stops?" On Artix Linux with runit, the answer is a tiny supervisor process that does almost nothing except notice, restart, and log. That narrowness is the point, and it's why runit is worth considering as a deliberate engineering choice rather than just "systemd avoidance."

The problem: supervision without the surface area

Systemd solves service management thoroughly, but it solves a lot of other things too — logging, device management, login sessions, timers, DNS. For a small VPS, a home server, or an embedded-ish box, much of that is surface area you didn't ask for. Artix is an Arch-derived distribution that swaps systemd out entirely and officially supports several alternatives: runit, OpenRC, s6, and dinit. You keep pacman and Arch's rolling-release packages (plus Artix's own repos for init-specific bits), but the init layer is yours to choose.

Runit's pitch is minimalism with one non-negotiable feature: automatic restart-on-crash supervision. It doesn't do socket activation, dependency graphs, or cgroup accounting. It starts your service, watches it, and brings it back if it exits.

How runit actually works

Runit boots in three stages: stage 1 (one-time initialization), stage 2 (the service supervisor, runsvdir, which runs for the life of the system), and stage 3 (shutdown). Each service is just a directory containing a small executable run script — usually two or three lines of shell that exec the daemon in the foreground. A per-service runsv process watches it and restarts it if it dies.

The elegant part is how services are enabled. There's no systemctl enable writing symlinks into opaque target directories. You symlink the service directory from /etc/runit/sv/ into the active service directory (typically /run/runit/service/), and runsvdir picks it up within seconds. Remove the symlink and the service stops being managed. Service state is plain filesystem state, inspectable with ls.

A worked example: supervised cron

On Artix-runit, installing cron looks like this (run as root or via sudo):

pacman -S cronie cronie-runit
ln -s /etc/runit/sv/cronie /run/runit/service/
sv status cronie

The cronie-runit companion package carries the run script — this pattern repeats across Artix packages: the upstream daemon from Arch repos, plus a small *-runit package with the supervision glue. The sv status command should report the service as run along with its PID and uptime. If it says down or fail, check the service's log (runsv can pipe output to a log/run script) or run the run script manually to see the error.

To prove supervision works, kill the daemon:

pkill crond
sleep 2
sv status cronie

Within moments, runsv restarts it and the status shows a fresh PID. That behavior — no configuration, no restart policies to tune — is runit's entire value proposition in one command.

You can write your own service the same way. Create /etc/runit/sv/myjob/run:

#!/bin/sh
exec /usr/local/bin/myjob 2>&1

Make it executable, symlink it into the service directory, done. Note the exec: the script must replace itself with the daemon so runsv watches the right process, and the daemon must stay in the foreground.

The trade-offs, honestly

Runit gives you no dependency ordering beyond what you script yourself, no socket activation, and no built-in resource limits — if you need cgroups, you wire them up with other tools. Some Arch packages assume systemd exists: anything depending on systemd-logind needs Artix's elogind replacement, and there's no journald, so you choose a syslog daemon or per-service loggers. Artix is also a small community project; documentation and support channels are thinner than Arch's, and occasionally a package update assumes systemd behavior you have to patch around.

Paths and command names above reflect the conventional Artix-runit layout, but confirm against your installed system: pacman -Ql runit and the Artix wiki's runit section are the authoritative references, and details can shift between releases.

Try it in a VM first

The cheapest evaluation is an Artix-runit VM: install it, run sv status /run/runit/service/* to see what's supervised, read a few run scripts under /etc/runit/sv/, and do the kill-and-watch-it-restart test. If your workload is "a handful of daemons that must stay up," runit's transparency will feel like a feature you didn't know you were missing. If you need complex boot orchestration or per-service resource accounting, that's your signal to look at s6, OpenRC — or stay with systemd.