A Survey of Init Systems

Init Alternatives


While most distros ship with systemd, init alternatives exist. Here are a few of the leading init systems available for Linux.

Not long ago, few Linux users cared about the init system. It mostly ran in the background, the first process to run during bootup, and the one that started and, if necessary, stopped the others. However, the init system came under closer scrutiny in 2012-2015, when systemd started to be used as the init system in most major distributions. Many complained about its complexity and the way that it was promoted by officials in major distributions. Thanks to the Devuan distro, some even began to talk about “Init Freedom,” the right to choose your init system as though it was as basic as the four software freedoms advocated by the Free Software Foundation. Others replied that init freedom would complicate compiling packages and general distro releases.

Today, the discussion continues. While most distributions ship systemd, a number of alternatives exist. Below is a quick summary of the leading init systems. If you are interested in trying one, the search filters on DistroWatch can let you locate which distro, if any, defaults to the init system that interests you. Alternatively, you can replace your existing init with another one, although the task is not for the faint-hearted, nor recommended for any except well-informed experts.

GNU Daemon Shepherd

Founded in 2002 as GNU dmd, GNU Daemon Shepherd was originally intended for the Hurd kernel. Today, it should work on any system that includes the Guile programming language. Currently, Guix is the only distribution that includes it.

Like other init systems, Shepherd controls other services. Features that make it stand out include a graphical interface called herd and the ability to create virtual services -- that is, generic services that can be associated with a particular category of applications. For example, a virtual service for mail could control Exim, Sendmail, or any other mailer-daemon. Each service is defined by the specific actions it provides, plus its current state and whether it can respawn or runs only once when started, how the service can be edited while running, and what other services, if any, can replace it. A service root is also available for editing the shepherd daemon itself.

Since Shepherd is not in widespread use, evaluating it is difficult. However, it appears to be midway in complexity between a basic init like runit and a complex one like systemd. Its reliability remains unproved.


OpenRC is a collection of scripts originally developed by Roy Marples for Gentoo and now used by a handful of lesser-known distributions as well. Its core component reads the current runlevel, then starts the required scripts, and exits. The scripts are similar to those of SysVinit, but are easier to write because they are based on preexisting assumptions and building boxes. An optional daemon supervisor is also available. The result is a flexible init system with minimal overhead and Gentoo’s do-it-yourself approach to system architecture.


In contrast to systemd, runit is designed as a minimal system. It uses only two runlevels, the normal default and single for recovery, although more can be added. It is actually a collection of six utilities:

  • runit-inited starts the kernel
  • runit-init manages the booted system
  • sv starts, stops, and adds services
  • svlogd sets up and manages a log for runit
  • chpset optionally runs a specialized version of a service for one user or group
  • utmpset modifies utmp and/or wtmp when a user logs out

Most of the time, the first three utilities are all that are needed to use runit, while svlogd is advised.

Runit’s size makes it much faster than most inits and especially suitable for older hardware. Its size also makes it easy to understand and learn. In fact, a few hours is all that is needed to learn runit. The fact that it was developed on Debian may make it especialy suitable for Debian derivatives.


SysVinit refers to an init descended from System V Unix. Until systemd’s popularity, SysVinit or variations of it were the most popular init for Linux, although a minority of distros, such as Slackware, rely on their own startup scripts.

SysVinit is built around a set of several states, or runlevels, including one for normal operations, and one for repairs usually known as single-user mode. Others can be added as required. Each runlevel can have its own mounted filesystems and can start with either a command line or its own desktop environment. Often, there is one runlevel for shutting down the machine and another for rebooting, both of which run checks and ensure that applications are turned off gracefully -- that is, so they can start again without problems. Runlevels are usually numbers, although the numbering often differs with the distribution.

SysVinit’s main limitation is that services are run in the order in which they are started or closed down. Years ago, this arrangement made sense, but today it does not take advantage of memory or multiple cores, so many alternative inits run services concurrently. However, given the speed of modern hardware, this arrangement is often less of a problem than it used to be, which is why SysVinit continues to be used by at least 37 distributions, according to DistroWatch.


Systemd was initially developed by Lennart Poettering and Kay Sievers of Red Hat in 2010. By 2018, it had become the dominant Linux init system, despite intense arguments for or against it. Many of the objections to it were philosophical as much as technical, with many considering it unnecessarily complex. Some objections, too, were about how the decision was made, in particular in Debian, where after a close vote, the final decision to use systemd was finally made by the Technical Committee, giving rise to accusations of elitism. These objections linger strongly to this day, even though the most major distributions have long since settled on systemd.

While systemd’s name implies a single application, it is actually a suite of at least 69 binaries. The most basic control the running of services, like any init system. Unlike SysVinit, systemd runs system calls in parallel, making it theoretically faster. However, systemd also acts as an administrative layer to an entire Linux system in which everything from filesystems and sockets to services and system settings is defined in detail and can be analyzed, edited, and controlled. This overlay offers unprecedented control and means that administrators can move from distribution to distribution in a common interface. As a result, both configuration and security are made easier.


Upstart was probably the first modern init for Linux, developed by Canonical as a replacement for SysV. It probably opened the way for more recent projects like systemd. Upstart’s main advantage is that it is event-driven, meaning that starting services are not queued, but can start immediately after the command is given. This feature gives it a distinct advantage when external drives are mounted, device firmware started, or scanning for new devices. At the same time, it is backward compatible with SysVinit scripts -- making it a drop-in replacement -- and extensible.

With these advantages, Upstart seemed about to become the dominant init system for a few years. However, the appearance of systemd soon superseded Upstart. Upstart development stopped in 2018, although the development files are still available.

Choosing Priorities

Linux is not the only operating system. In 2005, Apple released launchd as a replacement for its FreeBSD-style init. Attempts are being made to reverse engineer launchd for FreeBSD, and it is likely only a matter of time before a similar effort is made for Linux. For custom, hands-on control of the init system, you can also use the S6 collection of scripts along with OpenRC or runit to your liking.

However, even without other efforts, Linux still offers a wide variety of choices. A few years ago, when Debian voted down the idea of officially supporting multiple init systems, there was a marked tendency for administrators and distribution officers to prefer systemd, partly to remain compatible with other distros, and partly for the added control of the entire system. By contrast, those who consider the Unix design philosophy relevant favored inits like runit that do nothing except start and stop services efficiently. In between those two extremes is GNU Daemon Shepherd. Which init a user or a distribution prefers remains very much a matter of priorities. A surprising number still fall back on SysVinit, but the alternatives are there for those who want them.

Related content

  • Back to the Future

    If you find systemd needlessly complicated, runit offers an easy-to-use, minimal init alternative.

  • Professor Knopper's Lab – Removing systemd

    The systemd service manager has been widely adopted by many Linux distros, so why would you want to remove it? The professor reveals why and how.

  • Init Systems

    SysV init was formerly the sole candidate for starting processes on Linux, but today, a tech-savvy generation of init systems is waiting in the starting blocks.

  • Systemd Units

    Systemd units use files to control resources that Systemd manages.

  • Systemd GUIs

    Graphical frontends make it easier to take full advantage of the Systemd process manager. We examine some leading tools for the KDE environment.

comments powered by Disqus

Issue 248/2021

Buy this issue as a PDF

Digital Issue: Price $12.99
(incl. VAT)