Init systems

Choosing one

Set it at install time:

A_INIT=busybox
busyboxthe default. busybox init, /etc/rc.boot, /etc/rc.d scripts. Nothing extra installed.
openrcdependency-based, from Gentoo. /etc/init.d, rc-update.
sysvinitthe traditional one. /etc/inittab, /etc/rc3.d.
runittiny supervision. /etc/sv, sv up.
dinitdependency handling without the size. dinitctl.
s6-66s6 and s6-rc supervision with the 66 frontend.
systemdunits, journald, the suite.
systemd-libresystemd with the nonfree firmware loading paths removed.

Anything other than busybox is installed along with its supervision tools, and gets init= on the kernel command line.

Services are declared once

Arctic defines a service in /etc/rc.d as a few variables:

#!/bin/sh
NAME=iwd
CMD=/usr/bin/iwd
ARGS=""
BACKGROUND=yes

. /etc/arctic/svc.lib
svc_main "$@"

That is the only definition. arctic-init-setup translates it into whatever the running init expects — an OpenRC init.d script, a runit run file, a dinit service file, an s6 service directory, a systemd unit.

Shipping one definition and generating the rest means adding a service to Arctic is one file, and no init quietly drifts out of step with the others.

arctic-init-setup openrc              regenerate for OpenRC
arctic-init-setup runit --root /mnt   or into a target

A rebuild that changes the enabled set regenerates them automatically for whichever init the machine runs.

What translation actually does

Daemons and one-shots are different, and the translation knows the difference. A service with a CMD becomes a supervised process; one without — network, nftables, fstrim — becomes a one-shot that calls the rc.d script's own start and stop.

That distinction matters per init. Under runit a one-shot cannot be a supervised service at all — it would exit immediately and be restarted forever — so those go into runit's stage-1 boot script instead. Under dinit they become type = scripted; under systemd, Type=oneshot with RemainAfterExit.

Daemons that would fork are told to stay in the foreground when the init supervises them: dbus-daemon --nofork, sshd -D, crond -f.

Where things land

busybox/etc/rc.d, enabled via /etc/arctic/services
openrc/etc/init.d, /etc/runlevels/default
sysvinit/etc/init.d, /etc/rc3.d, /etc/rc5.d
runit/etc/sv, /etc/runit/runsvdir/default, stages in /etc/runit/13
dinit/etc/dinit.d, /etc/dinit.d/boot.d
s6-66/etc/s6/sv, /etc/66/service
systemd/etc/systemd/system

s6 needs its database compiled on the target once installed:

s6-rc-compile /etc/s6/rc/compiled /etc/s6/sv

Honest status

busybox init is what Arctic is built around, is what every service script is written against, and is the only one that has been through a full install-and-boot on real hardware. The others generate correct definitions and install their packages, but they have had far less use. If you are installing Arctic for the first time, use the default.

systemd in particular is a large dependency chain that Arctic does not yet build in full. If the package is unavailable the installer says so and falls back to busybox init rather than producing a machine that cannot boot.

More: arctic linux docs · install · declarative configuration · generations and rollback · kernels · packages (alpm) · desktops and audio · ephemeral shells · musl · building from source