Using runit for Service Supervision on a Headless Artix Server

A headless server without systemd

You need a small, headless server and you would rather not run systemd as PID 1. On an Arch-based system that usually means switching distributions or rebuilding the init layer. Artix Linux offers install media with runit preconfigured, so the practical question is not whether you can avoid systemd, but whether runit gives you enough operational visibility for a server that runs unattended.

The short answer is yes, for simple supervised services. runit is intentionally minimal: it starts a service, restarts it if it dies, and logs very little else. You trade systemd's unit files, cgroup accounting, and socket activation for straightforward shell scripts and a small process tree. The catch is logging: there is no journald by default, so you must arrange persistent logs yourself before the server goes into production.

How runit supervises services

Under runit, runsvdir runs as PID 1 and watches service directories. Each service lives in a directory—commonly under /etc/sv—containing an executable run script that starts the program in the foreground. To activate a service, you symlink its directory into /var/service. The sv command then reports status, starts, stops, or restarts the supervised process.

This differs from systemd, where a unit file declares dependencies and the manager handles cgroups, timers, and socket activation. runit has none of that built in. If a service needs logging, you typically run a second supervised process—a logger such as socklog—or write to a file directly from the run script.

Worked example: supervise a custom service

Run these commands as root on the Artix host. Replace myservice and /usr/local/bin/myservice with your own service name and executable.

# Create the service definition directory
mkdir -p /etc/sv/myservice

# Write the run script. The program must stay in the foreground.
cat > /etc/sv/myservice/run <<'EOF'
#!/bin/sh
exec /usr/local/bin/myservice
EOF

# Make it executable
chmod +x /etc/sv/myservice/run

# Activate the service
ln -s /etc/sv/myservice /var/service

# Check supervision status
sv status myservice

Permissions matter: /var/service and the supervise subdirectories are typically owned by root, so sv requires root or sudo. The run script must be executable, and the program it launches should not daemonize; runit expects the process to remain in the foreground.

Expected check: sv status myservice should report that the service is running and show its process ID. If it reports "fail" or "down," inspect the service directory and confirm the executable exists and does not exit immediately.

Risk: enabling a broken run script can create a tight restart loop. Test the script manually before symlinking it into /var/service.

Logging without journald

Because Artix with runit does not use systemd-journald, system logs are not collected automatically. A common approach is to supervise a logger such as socklog and point service output at it, or to append timestamps and write directly to files under /var/log. Verify that logs are rotating and writable before depending on the server remotely.

Trade-offs and limitations

• No built-in cgroup resource control or socket activation. Complex service dependencies must be handled in shell logic.
• Artix repositories can lag behind Arch official repositories. Some AUR packages assume systemd and may need manual patching.
• Removing systemd from an existing Arch installation is invasive and can break packages that expect systemd libraries. A fresh Artix install with runit is safer for a headless server.
• Power management and sleep/resume may require additional setup such as elogind, which is less relevant on a headless server but worth noting if you later add hardware.

Verify before production use

1. Confirm PID 1: ps -p 1 -o comm= should return runsvdir or another non-systemd process.
2. Confirm supervision: sv status myservice should show the service as run.
3. Confirm package set: pacman -Q | grep -E '^systemd' should return nothing, and pacman -Q | grep artix should list Artix-specific packages.
4. Confirm logging: check /var/log or your logger's output for recent entries.

Package names such as artix-runit vary between releases. Check the current Artix wiki before copying migration commands, and treat version-specific instructions as unverified until you confirm them against your installed ISO.

Rollback for the example

Creating the symlink under /var/service changes system state. To remove the example service:

rm /var/service/myservice
sv down myservice   # optional, if still supervised

This stops supervision and removes the service from the active directory without touching the definition under /etc/sv.

For a headless server that only needs a handful of reliable services, runit on Artix is a workable systemd-free option. Start with one service, confirm logging works, and expand only after the supervision loop is stable.