What Is an Init System and Which Alternatives to systemd Exist?

An init system is the first process the Linux kernel starts, so it runs as PID 1 and is responsible for spawning the other daemons the OS needs — networking, cron, syslog, and so on. systemd is one such init daemon, and it is the default on most major distributions; if you want to avoid it, the actively developed alternatives include SysVinit, OpenRC, runit, s6, Shepherd, finit, dinit, and a handful of smaller projects. The choice matters most if you care about keeping PID 1 small and single-purpose, or if you have been affected by systemd's bug and security history.

What an init daemon actually does

The kernel hands PID 1 to the init daemon at boot. From there it:

• Starts the services the system needs to become usable (networking, logging, scheduled jobs).
• Stays running as the parent of those processes, reaping orphans and supervising restarts.
• Acts as the fallback process that must never exit — if PID 1 dies, the kernel panics.

That is the whole job in the traditional model. Everything else — device management, login sessions, DNS resolution, containers — was historically handled by separate tools.

What systemd is, and how it differs from SysVinit

systemd claims to be a good and modern replacement for SysVinit. The difference is scope rather than just mechanism:

The criticism is not that systemd is an init system — it is that it is a large, tightly coupled suite occupying PID 1, where a bug in any component can take down the whole system.

The main criticisms and documented problems

The site's case against systemd rests on a list of notable bugs and security issues, several with real-world impact:

• A Datadog outage costing 5 million dollars was caused by a systemd upgrade.
• A widespread Azure outage occurred when systemd 237-3ubuntu10.54 was published to the bionic-security pocket — instances could no longer resolve DNS queries, breaking networking.
• CVE-2018-16864, CVE-2018-16865, and CVE-2018-16866 — a systemd-journald exploit chain.
• CVE-2018-15688 — out-of-bounds write in systemd-networkd DHCPv6 option handling.
• CVE-2017-15908 — a loop on packets with pseudo DNS types in resolved.
• #5644 — tmpfiles: R! /dir/.* destroys root.
• #6381 — booting with an encrypted root partition fails instantly in systemd-cryptsetup.
• #11810 — can't suspend again after suspending once.
• #8579 — systemd breaks my mouse.
• #2460 — systemctl status can take more than 10 seconds when the disk journal is used.
• #6237 — systemd can't handle process privileges for usernames starting with a number, such as 0day.
• #4863 — systemd-journald drops all bytes after a \0.
• #6620 — services writing to stdout become silent after a journal restart.
• #2402 — mounts efivarfs read-only.
• #1596 — journalctl -r -n flags processed incorrectly.
• #1312 — restarting a systemd service on dependency failure.
• #1143 — PID 1 gets stuck printing systemd[1]: Time has been changed continuously.
• #437 — timeX.google.com provides non-standard time.
• #6078 — applying systemd-networkd configuration disconnects all other interfaces.
• #6369 — hostnamed does not like FQDNs with trailing dots.
• #6478 — systemctl treats active→failed as a successful operation.
• systemd user manager interferes with ecryptfs, leaving the private directory unmounted.

The pattern is that because systemd is monolithic, a defect in a peripheral component (DNS, journal, networkd) can break core system behavior.

Active alternative init systems

These are the projects with current development activity:

• SysVinit — the traditional init; simple, well understood, still maintained.
• OpenRC — dependency-based init used by Gentoo, Alpine, and others; keeps service supervision separate from the rest of the system.
• runit — small, fast, supervision-focused; popular on Void Linux.
• s6 — a suite of small tools built around process supervision, designed for composability rather than a monolith.
• Shepherd — the GNU Guix System init, written in Scheme.
• finit — a small, fast init with dependency handling.
• dinit — a service manager and init with dependency support.
• superd, 31init, procd, dmaster, prometheus — additional projects listed as active.

Inactive projects to avoid

The site explicitly marks these as having had no development activity for several years:

• uselessd
• Upstart
• InitNG
• cinit
• minit
• Epoch

If you are choosing an init system for a new install, picking one of these means adopting an unmaintained component.

How to get rid of systemd

The practical route is to choose a distribution that ships an alternative init by default rather than trying to swap init on an existing systemd install. The site's "How do I get rid of systemd?" section and its useful links point to distributions built around SysVinit, OpenRC, runit, and s6. Migrating an already-installed systemd distribution is the harder path, because so many components (logging, device management, session handling) assume systemd is present.

Choosing between them

• If you want maximum familiarity and minimal change, SysVinit is the closest to the traditional model.
• If you want dependency-based service management without a monolith, OpenRC is the common choice.
• If you want small, supervision-first tooling, runit or s6 fit that description.
• If you want a modern small init with dependency handling, dinit or finit are the active options.

The decision usually comes down to which distribution you are willing to run, since the init system is effectively fixed by that choice.