Artix Linux Init Decision Guide: runit, OpenRC, s6, and systemd-shim

The init decision and why it comes first

When you install Artix Linux, the first engineering choice is not the desktop environment—it is which init system will supervise services. Artix is built without systemd as PID 1, but it supports several alternatives. That choice determines how packages behave, how services start, and how you recover from a broken boot. The practical takeaway: stay with runit unless you have a specific need for OpenRC's dependency handling, s6's isolation model, or the systemd compatibility layer provided by systemd-shim.

Constraints that narrow the choice

Before comparing features, settle these constraints:

• Package compatibility – some third-party software expects systemd unit files or socket activation.
• Service dependencies – do you need automatic ordering, or is explicit start/stop acceptable?
• Isolation requirements – do you need per-service supervision guarantees, or basic process monitoring?
• Seat and session management – desktop environments may expect a logind implementation; switching inits can affect elogind or seat permissions.
• Maintenance budget – how much time can you spend writing and debugging init scripts?

Supported options at a glance

Option	Artix package	PID 1 process	Primary strength	Main constraint
runit	runit (default)	runit	Small, simple supervision with short service scripts	No built-in socket activation; fewer high-level service features
OpenRC	openrc	rc	Dependency-based service ordering and Gentoo-style init scripts	More complex than runit; may not integrate cleanly with packages that ship only systemd units
s6	s6	s6 (or s6-svscan, depending on boot method)	Modular supervision tree with strong process isolation	Terse configuration syntax; documentation is sparse
systemd-shim	systemd-shim	runit (unchanged)	Compatibility layer for some systemd-aware software without systemd as PID 1	Artix-specific; can conflict with native service scripts and complicate upgrades

Trade-offs in practice

runit keeps the system lean and aligns with Artix's philosophy. It does not provide socket activation, so automation that depends on systemd socket units will need another path. Boot-time differences between runit, OpenRC, and s6 are typically small and workload-dependent; do not select an init based on unmeasured speed claims.

OpenRC adds a dependency graph, which helps when services must start in a specific order. However, it does not replicate systemd's socket-activation model, and packages that assume systemd unit files may start inconsistently or require manual translation.

s6 offers strong isolation and a composable supervision tree, but its configuration syntax is not intuitive for newcomers. A typo in a service definition can leave a service down without an obvious error, and community troubleshooting resources are limited.

systemd-shim is an Artix-specific package. It does not replace runit as PID 1; instead, it provides a compatibility layer so some systemd-aware applications can run. Keep it minimal, avoid overlapping service names with native Artix scripts, and expect that upgrades may require attention.

Concrete validation after choosing

Install the package for your chosen init (for example, pacman -S openrc) and reboot before validating. Run the following as root or with sudo. Replace <service> with a non-critical service you can safely restart.

1. Confirm PID 1

In any terminal, run:

ps -p 1 -o comm=

Expected check: the process name matches your chosen init (for example, runit, rc, or s6). If you expected OpenRC but see runit, inspect kernel boot parameters and installed packages before troubleshooting services.

2. List services

• runit: sv -w lists supervised services; service directories live under /etc/runit/runsvdir.
• OpenRC: rc-status shows runlevels and services from /etc/init.d.
• s6: s6-rc-status shows services from the compiled s6-rc database.
• systemd-shim: systemctl list-units --type=service shows units visible to the shim. If systemd-shim is not active, this may return nothing.

Risk: these are read-only checks.

3. Test start and stop

• runit: sv up <service> then sv down <service>. Verify with sv status <service>.
• OpenRC: rc-service <service> start then rc-service <service> stop.
• s6: use s6-rc-change -u <service> to bring a service up and s6-rc-change -d <service> to bring it down. The service name must match the compiled s6-rc database; confirm the exact name with s6-rc-status first.
• systemd-shim: systemctl start <service> then systemctl stop <service>. Risk: if the same service is also managed by a native Artix script, you may create conflicting supervisors.

Risk for all: stopping a critical service can disconnect you or block boot. Test on a disposable service.

4. Check logs

There is no universal log path. For runit and OpenRC, review /var/log/ and your configured syslog daemon. For s6, logging is per-service and must be configured; do not assume a default directory such as /var/log/s6 exists. For systemd-shim, journalctl -b may show unit logs if the shim's journal component is active.

If you must switch init systems

Switching inits changes system state and requires a reboot. A safer approach is to boot from an Artix live medium and chroot into your installation rather than trying to stop PID 1 from a running session. Before rebooting, back up /etc and your service definitions. If your bootloader passes an init= kernel argument, remove or adjust it so the new init can start. Install the target init package and follow the official Artix migration notes for that init. If you move away from a setup that expects systemd-logind, ensure elogind or an equivalent is installed for desktop seat management. Rollback: keep the live medium and your /etc backup so you can restore service definitions and boot parameters if the new init fails to start.

Limitations and a practical check

Commands, paths, and package names can differ between Artix releases; verify against your installed version's documentation. systemd-shim is Artix-specific and is not a full systemd replacement. OpenRC's dependency resolution does not guarantee compatibility with packages that ship only systemd unit files. s6's learning curve means small configuration errors can silently disable services.

After any change, reboot and run ps -p 1 -o comm= plus the service listing command for your init. If PID 1 is not what you expect, inspect kernel boot parameters and installed init packages before debugging individual services.