Almost every mainstream Linux distribution boots with systemd. A small but growing group does not, and one init system keeps coming up among them: Dinit. Chimera Linux is built on it, Artix offers it, and in 2026 KaOS switched to it. This guide covers what Dinit is, how it works day to day, and how it compares to the alternatives.

If you need the background first, our guide to what systemd is and process supervisors like s6 and runit cover the landscape.

What an init system does

The kernel’s last act during boot is to start one program as PID 1. That program is the init system, and it is responsible for:

• Mounting filesystems, starting udev, setting the hostname
• Starting every service, in an order that respects their dependencies
• Supervising services: noticing when they die and optionally restarting them
• Adopting and reaping orphaned processes, so they do not become zombies
• Shutting everything down cleanly

The designs differ mainly in how much else they take on beyond that core.

Where Dinit sits

Init	Dependencies	Supervision	Scope
SysV init	Script ordering only	None	Minimal
runit	None (ordering in scripts)	Yes	Minimal
OpenRC	Yes	Optional	Service manager on top of an init
Dinit	Yes	Yes	Init plus service manager, nothing else
s6 / s6-rc	Yes	Yes	Suite of small tools
systemd	Yes	Yes	Init plus logging, timers, network, login, and much more

Dinit’s pitch is that it provides the two things people genuinely missed when leaving systemd, real dependency management and supervision, in a single small program with a readable configuration format, and stops there.

It is written in C++ by Davin McCall, runs on Linux and the BSDs, and its main binaries are dinit (the daemon) and dinitctl (the control tool).

Service files

Services are described in plain files, one per service, usually in /etc/dinit.d/. The filename is the service name. A simple daemon:

# /etc/dinit.d/nginx
type            = process
command         = /usr/bin/nginx -g "daemon off;"
depends-on      = network
restart         = true
logfile         = /var/log/nginx-dinit.log

Compare that to a systemd unit file and the structure is recognisable: what to run, what it needs, and what to do when it exits.

Service types

Type	Meaning
process	A long-running process that Dinit starts and supervises directly. The preferred type
bgprocess	A daemon that forks into the background; Dinit tracks it through a PID file
scripted	A command that runs to completion to “start” the service, like mounting filesystems
internal	No process at all. Used for grouping, such as a network or boot milestone
triggered	Waits for an external trigger before it counts as started

Dependency types

Setting	Meaning
depends-on	Hard dependency: start this first, and stop me if it stops
depends-ms	Milestone dependency: must start first, but may stop later without stopping me
waits-for	Soft: start it first and wait, but start me even if it fails
before / after	Ordering only, without a dependency

Boot is modelled as a service too, usually named boot, that depends on everything that should start. Enabling a service adds it to the boot service’s dependencies, typically as a link in a boot.d directory.

dinitctl: day-to-day use

dinitctl list                  # every loaded service and its state
dinitctl status nginx          # one service in detail
dinitctl start nginx           # start now
dinitctl stop nginx            # stop now
dinitctl restart nginx
dinitctl enable nginx          # start now and at every boot
dinitctl disable nginx
dinitctl reload nginx          # re-read the service file

If you know systemctl, the mapping is nearly one to one. Our systemctl guide makes a useful comparison.

User services

Dinit can also run as a per-user service manager, launched when you log in, with services defined in your user config directory. Chimera Linux uses this for things like PipeWire, the same role systemctl --user plays on systemd systems.

What you give up compared to systemd

systemd is not just an init system. Leaving it means replacing its other parts with separate tools:

systemd component	Typical replacement on a Dinit system
journald	syslog-ng, socklog, or per-service log files
timers	cron, such as cronie or snooze
logind	elogind, or seatd plus turnstile
networkd / resolved	NetworkManager, dhcpcd, iwd, or ifupdown
udevd	eudev or standalone udev
Service sandboxing	Largely manual, via wrappers or bubblewrap

The sandboxing gap is the one systemd advocates point to most. Directives like ProtectSystem= and NoNewPrivileges=, covered in our systemd service hardening guide, are a one-line way to confine a service that Dinit does not replicate.

Software compatibility is the other cost. A growing number of desktop components assume systemd, especially logind. Distributions like Chimera and Artix do real work to keep GNOME and KDE running without it.

Why distributions choose it

The reasons given by Dinit-based distros tend to be:

• Scope: an init that only does init and supervision is easier to audit and understand
• Readability: service files are short and the behaviour is predictable
• Portability: it runs on non-glibc systems (Chimera uses musl) and on BSD
• Proper dependencies: something runit and SysV never offered

It is a defensible engineering choice, not just a statement about systemd, and Dinit is a mature, actively maintained project.

Should you try it?

The realistic way to try Dinit is on a distribution built around it, such as Chimera Linux or Artix’s Dinit edition, in a virtual machine. Replacing systemd on Debian, Fedora, or Ubuntu is technically possible but unsupported, and every package that assumes systemd becomes your problem.

If what you want is a lighter or more transparent system, that is a good reason to experiment. If you just want a working desktop, the distro’s default init system is the one that will be best tested.

Frequently Asked Questions

What is Dinit?

Dinit is an init system and service manager for Linux and BSD, written in C++ by Davin McCall. It runs as PID 1, starts services in parallel based on their declared dependencies, supervises them, and restarts them if configured. It aims to be much smaller than systemd while offering proper dependency management.

Which distributions use Dinit?

Chimera Linux uses Dinit as its only init system. Artix Linux offers it as one of several init choices. KaOS switched from systemd to Dinit in 2026. It can also be installed on other distributions, though replacing the init system on a systemd-based distro is not a supported configuration.

Where do Dinit service files live?

System service descriptions live in /etc/dinit.d/ and sometimes /usr/lib/dinit.d/. Each file is named after the service and contains key and value settings such as type, command and depends-on. Enabled services are recorded as links in a boot.d directory.

How do I start and enable a service with Dinit?

Use dinitctl start followed by the service name to start it now, and dinitctl enable followed by the name to start it now and at every boot. dinitctl list shows every loaded service and its state, and dinitctl stop and dinitctl disable reverse those actions.

Is Dinit better than systemd?

It is smaller and does one job, which some users prefer. systemd offers far more, including logging, timers, network and login management, sandboxing and socket activation. Dinit relies on separate tools for those. Which is better depends on whether you want an integrated platform or a minimal core.

Does Dinit support user services?

Yes. Dinit can run as a per-user service manager, started from a login session, with user services defined under the user configuration directory. Chimera Linux uses this for user-level services such as PipeWire.