What Is systemd and Which Init System Alternatives Exist?

systemd is one of several init daemons — the first process the kernel starts (PID 1) — and it has drawn sustained criticism for its scope, design, and bug history. If you want to avoid it, maintained alternatives include SysVinit, OpenRC, runit, s6, Shepherd, finit, Dinit, and others; the practical choice depends on whether you're picking a distribution or replacing init on an existing install.

What an init system actually does

The kernel spawns the init daemon first, so it runs as PID 1. From there it starts and supervises the other daemons the OS needs — networking, cron, syslog, and so on. That's the whole job in the classic model: bring the system up, keep services running, shut them down cleanly.

systemd presents itself as a modern replacement for SysVinit in that role, but it bundles far more than service supervision.

The alternatives, and which are still alive

The No systemd project maintains a list of init daemons. The distinction that matters most when choosing is whether the project is still developed.

"Inactive" here means no development activity for several years — treat those as historical interest rather than something to build on.

Why people move away from systemd

The objections on No systemd fall into two buckets: design scope and concrete defects.

On design, the complaint is that systemd is not just an init — it grows into logging (journald), networking (networkd), name resolution (resolved), and more. That concentration is what critics mean by a monolithic design.

On defects, the site collects a long list of notable bugs and security issues, including:

• A Datadog outage reported to have cost 5 million dollars, caused by 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, breaking networking.
• Multiple CVEs: 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).
• Operational oddities such as systemctl treating active→failed as a successful operation, systemctl status taking over 10 seconds when the disk journal is used, and services writing to stdout going silent after a journal restart.

The pattern to take from this list isn't any single bug — it's that a component sitting at PID 1 and touching networking, logging, and resolution has a large blast radius when it fails.

How to get rid of systemd

The site frames this as its own question ("How do I get rid of systemd?"), and there are two routes:

1. Choose a distribution that doesn't ship systemd. This is the low-friction path — you get a supported init (OpenRC, runit, s6, SysVinit, and so on) without fighting the base system.
2. Replace init on an existing install. This is the harder path: you need your chosen init to bring up everything your system depends on, and you need to convert service definitions from systemd units to that init's format.

Either way, the decision comes down to which maintained init you're willing to operate and whether your distribution supports it as a first-class option.

Choosing between them

There's no single "best" alternative — the right pick depends on your constraints:

• If you want the smallest possible supervision layer, look at runit or s6.
• If you want dependency-based service management with a long track record, OpenRC is the common answer.
• If you want the traditional, minimal model, SysVinit still works.
• If you're on a distribution with its own init (Guix's Shepherd, OpenWrt's procd), staying with it is usually simpler than swapping.

Check the maintenance status first: an inactive init means you're on your own for fixes, which matters most for the process running as PID 1.