Learning Artix Linux - Alternative Inits: runit, s6 & dinit

#Introduction

OpenRC isn't the only option. Episode 6 introduces you to three alternative inits fully supported by Artix: runit, s6, and dinit. They were born from a different philosophy than OpenRC — smaller, more focused on process supervision, and each with its own configuration model.

The goal of this episode isn't to pick a winner, but to build reading fluency: understanding each init's commands, directory structures, and way of thinking. That way, you can follow every example in this series regardless of which variant you choose, and decide on the best init for your needs in episode 22.

#runit: Simple with Automatic Logging

#Concept: Service Directories and runsvdir

runit follows the principle "a service is a directory." Each service has its own folder containing a run script, and the runsvdir supervisor runs all registered services. On Artix, the main directory is /etc/runit/runsvdir/.

To enable a service, create a symlink from the service directory into the default runsvdir:

ln -s /etc/runit/sv/sshd /etc/runit/runsvdir/default/sshd

That symlink is what makes the service start at boot. Remove the symlink to disable it. You can see all active services with ls /etc/runit/runsvdir/default/.

#The sv Command

Service control on runit is done with sv:

sv status /etc/runit/runsvdir/default/*
sv up sshd
sv down sshd
sv restart sshd

The sv status output shows each service's status, usually run with a PID or down. Because runit keeps services alive, a crashed process is automatically restarted by the supervisor.

#Per-Service Logging

runit integrates logging: if a service folder has a log subfolder with a run script, the service's output is streamed straight to the logger. This comes for free with no extra configuration:

tail -f /var/log/runit/sshd/current

The command tail -f /var/log/runit/sshd/current follows the service log, which svlogd rotates automatically. Built-in logging is one of runit's main advantages.

#s6: A Modern Supervision Tree

#Concept: Service Database and s6-svscan

s6 is philosophically similar to runit, but with more complete tooling. Services are managed via a service database in /etc/s6/sv/, and s6-svscan is the main supervisor. s6 supports the concept of "scan directories" and ready-to-use services started with a single command.

List active services with s6-rc:

s6-rc -l list
s6-rc -l list | grep up

The command s6-rc -l list shows all defined services along with their status. Unlike runit's symlink approach, s6 uses a database built from the service directories.

#The s6-svc Command

Runtime control is done with s6-svc, and status with s6-svstat:

s6-svc -u /run/service/sshd
s6-svc -d /run/service/sshd
s6-svc -r /run/service/sshd
s6-svstat /run/service/sshd

-u for up, -d for down, and -r for restart. The s6-svstat output shows the PID, uptime duration, and restart count. s6 is very transparent about status because every service is continuously supervised.

#Advantage: Connected Supervision

s6 supports s6-svc -s for signals and connections between supervisors on different machines. This is why s6 is used in ecosystems like Alpine and Void as a modern initiative. For serious server use, this capability is valuable.

#dinit: Small and Dependency-Clear

#Concept: .dinit Service Files

dinit takes a different approach: services are defined as text files ending in .dinit in /etc/dinit.d/. These files use a declarative format similar to systemd units, but far lighter:

type = process
command = /usr/sbin/sshd
depends-on = network
restart = true

depends-on = network is how dinit manages dependencies. The format is clear and easy to read, making dinit friendly to anyone who has touched systemd units.

#The dinitctl Command

Service control is done with dinitctl:

dinitctl start sshd
dinitctl stop sshd
dinitctl restart sshd
dinitctl status sshd

dinitctl status shows status and active dependencies. Because dinit tracks dependencies explicitly, services can start in parallel once their dependencies are ready — one of dinit's big strengths over other inits.

#Project Status

dinit is the youngest init in the Artix family and keeps maturing. Because its format is declarative and lightweight, dinit appeals to those who want a modern init without systemd's weight. Its development is revisited in episode 21.

#Comparing the Four Inits

#A Quick Comparison Table

To compare easily, keep this map in your head:

Init    Enable at boot          Runtime control     Status
OpenRC  rc-update add X default rc-service X start  rc-status
runit   ln -s ... runsvdir      sv up X             sv status X
s6      s6-rc -u change X       s6-svc -u X         s6-svstat X
dinit   dinitctl enable X       dinitctl start X    dinitctl status X

Notice the pattern: every init has the same three core operations — registering at boot, controlling at runtime, and checking status. Only the syntax differs.

#When to Choose Which

• OpenRC: the most documented, familiar, good for those just coming from SysV.
• runit: very simple, automatic logging, resource-efficient, ideal for lightweight servers.
• s6: modern tooling, strong supervision, great for experiments and complex environments.
• dinit: declarative format, parallel start, fits those who like minimal systems.

There's no single answer. Many users try OpenRC first, then move to runit or s6 once comfortable.

#Practice: Trying Another Init

#Safe Experiments in a VM

The best way to understand the differences is to try them. Install a second VM with a different ISO variant, then compare the same task:

# On the runit VM
ln -s /etc/runit/sv/sshd /etc/runit/runsvdir/default/sshd
# On the dinit VM
dinitctl enable sshd

One same service, two different activation methods. After trying two or three inits, you'll be more confident reading documentation from communities using different inits.

#Conclusion

Episode 6 introduced three alternative inits: runit with service directories and automatic logging, s6 with a modern supervision tree and complete tooling, and dinit with declarative .dinit files and parallel startup. All have their own commands and configuration structures.

Key takeaways:

• runit: service = directory, control with sv, logs via svlogd.
• s6: service database in /etc/s6/sv/, control with s6-svc.
• dinit: declarative .dinit files, control with dinitctl.
• Dependencies: symlinks on runit, depends-on on dinit, scripts on s6.
• OpenRC is the most familiar; runit/s6/dinit are smaller and more modern.
• Try each init in a separate VM before deciding which one to use.

In the next episode, episode 7, we'll cover users, groups, network, and boot — user and sudo management, NetworkManager and nmcli, dhcpcd, static IP configuration, and the boot process without systemd from init to runlevel.