Runit service supervision and systemd unit compatibility limits

Direct Answer

There is no standardized, fully automated method that preserves complete systemd unit semantics when converting to runit scripts. Existing converters handle only basic ExecStart/ExecStop translation and lose declarative dependency directives (Wants, Requires, PartOf, Conflicts, After/Before). Dependency ordering in runit must be implemented manually through run-script sequencing or external orchestration.

Confirmed Limits of Automated Conversion

• No native parser: runit does not read .service, .socket, .timer, or .target files.
• Converter output scope: Tools such as systemd2runit or distribution helpers (e.g., Artix's systemd2runit package) emit a minimal run script and optional finish/check scripts. They do not translate:

# systemd directives with no runit equivalent
Wants=, Requires=, PartOf=, Conflicts=
After=, Before= (ordering only)
ConditionPathExists=, ConditionKernelVersion=
MemoryLimit=, CPUQuota=, IOWeight= (cgroup v2)
DynamicUser=, PrivateTmp=, ProtectSystem=
Restart=on-failure (runit supervise restarts unconditionally)
StandardOutput=journal (runit logs via svlogd)

• Flat supervision model: Each service in /service is supervised independently. There is no built-in dependency graph; sv up starts services in filesystem order unless you script otherwise.

Practical Migration Steps

1. Inventory systemd units: systemctl list-unit-files --type=service --state=enabled and capture each unit with systemctl cat <unit>.
2. Generate baseline run scripts: Run a converter (e.g., systemd2runit <unit>) to produce /etc/sv/<name>/run. Review every line.
3. Manually re-implement lost semantics:
   • Ordering: In the consumer service's run script, add a sv wait or sv check loop for each prerequisite before exec.
   • Resource limits: Apply systemd-run --scope equivalents via cgexec, prlimit, or kernel boot parameters.
   • Security hardening: Translate PrivateTmp=yes to a per-service TMPDIR in run; map ProtectSystem=strict to bind mounts or namespaces via unshare wrappers.
   • Restart policy: Runit's supervise restarts on any exit. To mimic Restart=on-failure, write a finish script that exits 0 only on clean shutdown signals.
4. Enable and test: ln -s /etc/sv/<name> /service/ then sv up <name>. Verify with sv status <name> and sv log <name>.

Dependency Maintenance Strategies

Approach	How It Works	Trade-off
Run-script sv wait chains	Each run blocks on sv check dep1 && sv check dep2 before exec.	Explicit, visible in script; adds boot latency if overused.
Stage directories (e.g., /etc/runit/1, 2, 3)	Boot stages run sequentially; services in stage N start after stage N-1 completes.	Coarse-grained; fits traditional runit layouts (Void, Artix).
External orchestrator (s6-rc, nosh, or custom)	Declare a dependency graph once; tool expands to runit-compatible scripts.	Adds another layer; defeats runit minimalism for some admins.

Verification Checklist

• Compare systemctl show <unit> output against the final run script for every directive.
• Confirm cgroup placement: cat /proc/<pid>/cgroup matches intended slice.
• Simulate failure: sv down <name>; sv up <name> and observe restart behavior.
• Boot into multi-user target and verify all migrated services reach run state without manual intervention.

One Diagnostic Detail That Changes the Recommendation

Are you migrating a complete host (all services) or only select packages that lack runit-native scripts? A full-host migration justifies investing in a stage-based or orchestrator approach; a few packages are faster to hand-script individually.