What Is systemd and What Are the Alternatives?

Updated

systemd is an init daemon and service manager: it runs as PID 1, the first process the kernel starts, and it brings up the rest of the system — networking, cron, syslog, and other daemons. It is the default on most mainstream Linux distributions, but it is not the only option. Alternatives include SysVinit, OpenRC, runit, s6, dinit, and others, and some distributions ship without systemd entirely. If you are choosing a distribution or trying to remove systemd from an existing install, the decision usually comes down to how much of your system depends on systemd-specific interfaces.

What systemd actually does

The kernel spawns one process at boot and gives it PID 1. That process is responsible for starting everything else the OS needs. systemd fills that role and expands it well beyond a classic init: it also handles service supervision, logging (journald), device management (udev), network configuration (systemd-networkd), name resolution (systemd-resolved), timers, and user session management.

That breadth is the core of the disagreement. A traditional init starts services and gets out of the way. systemd absorbs many separate components into one project, so replacing it means replacing or reconfiguring several subsystems at once, not just swapping one daemon.

Common criticisms

The No systemd resource collection frames its case around two things: scope and reliability.

  • Scope creep. systemd replaces many independent tools with components from a single project, which critics argue reduces modularity and choice.
  • Bug and security history. The site lists a long series of issues, including:
    • A Datadog outage reported to have cost $5 million, attributed to a systemd upgrade.
    • A widespread Azure outage after systemd 237-3ubuntu10.54 was published to the bionic-security pocket, where instances could no longer resolve DNS queries.
    • CVE-2017-15908 (resolved loop on packets with pseudo DNS types), CVE-2018-15688 (out-of-bounds write in systemd-networkd DHCPv6 option handling), and CVE-2018-16864/16865/16866 (a systemd-journald exploit chain).
    • Functional bugs such as systemctl reporting slow status (>10s) with a disk journal, services going silent after a journal restart, and a tmpfiles rule that could destroy root.

These are the specific, checkable items the source raises. Whether they outweigh systemd's benefits is a judgment call — the point is that the criticism is grounded in named incidents and CVE numbers rather than general dislike.

Init alternatives

The source lists these init daemons, marking inactive ones where development has stopped for several years:

Init Status
systemd active
SysVinit active
OpenRC active
runit active
s6 active
Shepherd active
finit active
Hummingbird active
superd active
31init active
Dinit active
procd active
uselessd inactive
Upstart inactive
InitNG inactive
cinit inactive
minit inactive
Epoch inactive
dmaster active
prometheus active

For most people looking to move away from systemd, the practical shortlist is OpenRC, runit, s6, and dinit — all actively developed and used by real distributions.

How to get rid of systemd

The source's own section on this is titled "How do I get rid of systemd?" and the honest answer is that it ranges from easy to impractical depending on your starting point.

The reliable path: install a distribution that doesn't use systemd. This avoids fighting a package manager and init system that assume systemd is present.

The hard path: convert an existing system. This means replacing PID 1, rebuilding or reconfiguring packages that ship systemd units, and handling the services systemd was managing for you (logging, networking, DNS, timers). Expect breakage in anything that calls systemctl, reads the journal, or depends on systemd-specific unit features.

A reasonable order of operations if you attempt a conversion:

  1. Identify every service currently managed by systemd (systemctl list-units) and find its equivalent unit or script for your target init.
  2. Replace the logging path if you relied on journald.
  3. Replace network and DNS management if you used systemd-networkd or systemd-resolved.
  4. Install and configure the new init, then switch the bootloader/kernel command line to use it.
  5. Verify by rebooting and confirming PID 1 is the new init and that networking, logging, and your critical services come up.

The verification step matters: a system that boots but silently loses DNS or logging is a common failure mode, and it mirrors the Azure incident above.

Distributions without systemd

The site's stated purpose is to help you "find Linux distributions without systemd." That list is the fastest route to a working non-systemd system, since the distribution maintainers have already done the integration work. If your goal is simply to run Linux without systemd rather than to convert a specific machine, start there rather than with a manual conversion.

Choosing between them

  • Want minimal disruption and a supported path? Pick a distribution that ships your preferred init.
  • Want a small, simple init? runit and dinit are lightweight; OpenRC is a common middle ground with broad distro support.
  • Want a supervision toolkit you can compose? s6 is built around that model.
  • Need to keep an existing install? Budget for replacing logging, networking, and DNS alongside PID 1, and test the reboot before trusting it.