Systemd


systemd is a software suite that provides an array of system components for Linux operating systems.
Its main aim is to unify service configuration and behavior across Linux distributions; systemd's primary component is a "system and service manager"—an init system used to bootstrap user space and manage user processes. It also provides replacements for various daemons and utilities, including device management, login management, network connection management, and event logging. The name systemd adheres to the Unix convention of naming daemons by appending the letter d. It also plays on the term "System D", which refers to a person's ability to adapt quickly and improvise to solve problems.
Since 2015, the majority of Linux distributions have adopted systemd, having replaced other systems such as the UNIX System V and BSD init systems. systemd has faced mixed reception from Linux users, with arguments that systemd suffers from mission creep and bloat, as well as criticism over software adding dependencies on systemd—frustrating compatibility with other Unix-like operating systems.

History

and Kay Sievers, the software engineers working for Red Hat who initially developed systemd, started the project to develop systemd in 2010. They sought to surpass the efficiency of the init daemon in several ways. They wanted to improve the software framework for expressing dependencies, to allow more processing to be done concurrently or in parallel during system booting, and to reduce the computational overhead of the shell.
In May 2011 Fedora became the first major Linux distribution to enable systemd by default. Between October 2013 and February 2014, a long debate among the Debian Technical Committee occurred on the Debian mailing list, discussing which init system to use as the default in Debian 8 "jessie", and culminating in a decision in favor of systemd. The debate was widely publicized and in the wake of the decision the debate continues on the Debian mailing list. In February 2014, after Debian's decision was made, Mark Shuttleworth announced on his blog that Ubuntu would follow in implementing systemd.
In November 2014 Debian Developer Joey Hess, Debian Technical Committee members Russ Allbery and Ian Jackson, and systemd package-maintainer Tollef Fog Heen resigned from their positions. All four justified their decision on the public Debian mailing list and in personal blogs with their exposure to extraordinary stress-levels related to ongoing disputes on systemd integration within the Debian and open-source community that rendered regular maintenance virtually impossible.
In August 2015 systemd started providing a login shell, callable via machinectl shell.
In September 2016, a security bug was discovered that allowed any unprivileged user to perform a denial-of-service attack against systemd. Rich Felker, developer of musl, stated that this bug reveals a major "system development design flaw". In 2017 another security bug was discovered in systemd,, which "allows disruption of service" by a "malicious DNS server".

Design

Poettering describes systemd development as "never finished, never complete, but tracking progress of technology". In May 2014, Poettering further described systemd as unifying "pointless differences between distributions", by providing the following three general functions:
Systemd includes features like on-demand starting of daemons, snapshot support, process tracking and Inhibitor Locks. It is not just the name of the init daemon but also refers to the entire software bundle around it, which, in addition to the init daemon, includes the daemons, and, and many other low-level components. In January 2013, Poettering described systemd not as one program, but rather a large software suite that includes 69 individual binaries. As an integrated software suite, systemd replaces the startup sequences and runlevels controlled by the traditional init daemon, along with the shell scripts executed under its control. systemd also integrates many other services that are common on Linux systems by handling user logins, the system console, device hotplugging, scheduled execution, logging, hostnames and locales.
Like the init daemon, is a daemon that manages other daemons, which, including itself, are background processes. is the first daemon to start during booting and the last daemon to terminate during shutdown. The daemon serves as the root of the user space's process tree; the first process has a special role on Unix systems, as it replaces the parent of a process when the original parent terminates. Therefore, the first process is particularly well suited for the purpose of monitoring daemons.
executes elements of its startup sequence in parallel, which is theoretically faster than the traditional startup sequence approach. For inter-process communication, makes Unix domain sockets and D-Bus available to the running daemons. The state of itself can also be preserved in a snapshot for future recall.

Core components and libraries

Following its integrated approach, systemd also provides replacements for various daemons and utilities, including the startup shell scripts, pm-utils, inetd,, syslog, watchdog, cron and. systemd's core components include the following:
tracks processes using the Linux kernel's cgroups subsystem instead of using process identifiers ; thus, daemons cannot "escape", not even by double-forking. not only uses cgroups, but also augments them with and, two utility programs that facilitate the creation and management of Linux containers. Since version 205, systemd also offers ControlGroupInterface, which is an API to the Linux kernel cgroups. The Linux kernel cgroups are adapted to support kernfs, and are being modified to support a unified hierarchy.

Ancillary components

Beside its primary purpose of providing a Linux init system, the systemd suite can provide additional functionality, including the following components:
;
;
;
;
;
;
;
;
;
;

Configuration of systemd

is configured exclusively via plain-text files.
records initialization instructions for each daemon in a configuration file that uses a declarative language, replacing the traditionally used per-daemon startup shell scripts. Unit-file types include:
man systemd.unit explains the hierarchy of the configuration files. Their paths are defined during compilation. The default:

UNIT LOAD PATH
 Unit files are loaded from a set of paths determined during
 compilation, described in the two tables below. Unit files found
 in directories listed earlier override files with the same name
 in directories lower in the list.
 Table 1. Load path when running in system mode.
 ┌────────────────────────┬─────────────────────────────┐
 │Path │ Description │
 ├────────────────────────┼─────────────────────────────┤
 │/etc/systemd/system │ Local configuration │
 ├────────────────────────┼─────────────────────────────┤
 │/run/systemd/system │ Runtime units │
 ├────────────────────────┼─────────────────────────────┤
 │/usr/lib/systemd/system │ Units of installed packages │
 └────────────────────────┴─────────────────────────────┘

Adoption

Linux distributionDate added to software repositoryEnabled by default?Date released as defaultRuns without?
Alpine Linux
Android
Arch Linux
AntiX Linux
Artix Linux
CentOS
CoreOS
Debian
Devuan
Fedora
Gentoo Linux
Knoppix
Linux Mint
Mageia
Manjaro Linux
openSUSE
Parabola GNU/Linux-libre
Red Hat Enterprise Linux
Slackware
Solus
Source Mage GNU/Linux
SUSE Linux Enterprise Server
Ubuntu in Yaketty
Missing functionality using init systems other than systemd
Void Linux, removed

While many distributions boot systemd by default, some allow other init systems to be used; in this case switching the init system is possible by installing the appropriate packages. A fork of Debian called Devuan was developed to avoid systemd and has reached version 2.0 for stable usage. In December 2019, the Debian project voted in favour of retaining systemd as the default init system for the distribution, but with support for "exploring alternatives".

Integration with other software

In the interest of enhancing the interoperability between systemd and the GNOME desktop environment, systemd coauthor Lennart Poettering asked the GNOME Project to consider making systemd an external dependency of GNOME 3.2.
In November 2012, the GNOME Project concluded that basic GNOME functionality should not rely on systemd. However, GNOME 3.8 introduced a compile-time choice between the and ConsoleKit API, the former being provided at the time only by systemd. Ubuntu provided a separate binary but systemd became a de facto dependency of GNOME for most Linux distributions, in particular since ConsoleKit is no longer actively maintained and upstream recommends the use of instead. The developers of Gentoo Linux also attempted to adapt these changes in OpenRC, but the implementation contained too many bugs, causing the distribution to mark systemd as a dependency of GNOME.
GNOME has further integrated. As of Mutter version 3.13.2, is a dependency for Wayland sessions.

Reception

The design of systemd has ignited controversy within the free-software community. Critics regard systemd as overly complex and suffering from continued feature creep, arguing that its architecture violates the Unix philosophy. There is also concern that it forms a system of interlocked dependencies, thereby giving distribution maintainers little choice but to adopt systemd as more user-space software comes to depend on its components.
In a 2012 interview, Slackware's lead Patrick Volkerding expressed reservations about the systemd architecture, stating his belief that its design was contrary to the Unix philosophy of interconnected utilities with narrowly defined functionalities., Slackware does not support or use systemd, but Volkerding has not ruled out the possibility of switching to it.
In January 2013, Lennart Poettering attempted to address concerns about systemd in a blog post called The Biggest Myths.
In February 2014, musl's Rich Felker opined that PID 1 is too special, should be 10 lines of code and not require reboot on upgrade. PID 1 should only start the real init script, and reap zombie processes. All the functionality of systemd then can be provided by the init script and programs run from it. PID 1 so has only a small attack surface, and user level programs can evolve diversly.
In March 2014 Eric S. Raymond opined that systemd's design goals were prone to mission creep and software bloat. In April 2014, Linus Torvalds expressed reservations about the attitude of Kay Sievers, a key systemd developer, toward users and bug reports in regard to modifications to the Linux kernel submitted by Sievers. In late April 2014 a campaign to boycott systemd was launched, with a Web site listing various reasons against its adoption.
In an August 2014 article published in InfoWorld, Paul Venezia wrote about the systemd controversy and attributed the controversy to violation of the Unix philosophy, and to "enormous egos who firmly believe they can do no wrong". The article also characterizes the architecture of systemd as similar to that of svchost.exe, a critical system component in Microsoft Windows with a broad functional scope.
In a September 2014 ZDNet interview, prominent Linux kernel developer Theodore Ts'o expressed his opinion that the dispute over systemd's centralized design philosophy, more than technical concerns, indicates a dangerous general trend toward uniformizing the Linux ecosystem, alienating and marginalizing parts of the open-source community, and leaving little room for alternative projects. He cited similarities with the attitude he found in the GNOME project toward non-standard configurations. On social media, Ts'o also later compared the attitudes of Sievers and his co-developer, Lennart Poettering, to that of GNOME's developers.
On 6 July 2015, an issue was raised on the systemd GitHub page expressing concerns about the hard coding of DNS servers in the systemd code. Poettering responded that it is not the actual DNS but rather the fallback DNS that is hard coded. He added that the fallback DNS is only used if "nobody configured anything" and to prevent connectivity issues due to catastrophic failure of configuration files or a lack of DHCP on the network. As Poettering described, the system "should do the right thing" if, as an example, the /etc directory were missing or empty. Poettering also noted that the /etc/systemd/resolved.conf file installed with systemd contains exactly the same DNS servers as the fallback DNS, thereby resulting in the same operation regardless of the /etc directory being empty or present.

Forks and alternative implementations

eudev

In 2012, the Gentoo Linux project created a fork of udev in order to avoid dependency on the systemd architecture. The resulting fork is called eudev and it makes udev functionality available without systemd. A stated goal of the project is to keep eudev independent of any Linux distribution or init system.

elogind

Elogind is the systemd project's "logind", extracted out to be a standalone daemon. It integrates with PAM to know the set of users that are logged into a system and whether they are logged in graphically, on the console, or remotely. Elogind exposes this information via the standard org.freedesktop.login1 D-Bus interface, as well as through the file system using systemd's standard /run/systemd layout. Elogind also provides "libelogind", which is a subset of the facilities offered by "libsystemd". There is a "libelogind.pc" pkg-config file as well.

uselessd

In 2014, uselessd was created as a lightweight fork of systemd. The project sought to remove features and programs deemed unnecessary for an init system, as well as address other perceived faults. Project development halted in January 2015.
uselessd supported the musl and µClibc libraries, so it may have been used on embedded systems, whereas systemd only supports glibc. The uselessd project had planned further improvements on cross-platform compatibility, as well as architectural overhauls and refactoring for the Linux build in the future.

systembsd

In 2014, a Google Summer of Code project named "systembsd" was started in order to provide alternative implementations of these APIs for OpenBSD. The original project developer began it in order to ease his transition from Linux to OpenBSD. Project development halted in July 2016.
The systembsd project did not provide an init replacement, but aimed to provide OpenBSD with compatible daemons for,,, and. The project did not create new systemd-like functionality, and was only meant to act as a wrapper over the native OpenBSD system. The developer aimed for systembsd to be installable as part of the ports collection, not as part of a base system, stating that, "systemd and *BSD differ fundamentally in terms of philosophy and development practices."

consolekit2

ConsoleKit was forked in October 2014 by Xfce developers wanting its features to still be maintained and available on operating systems other than Linux. While not ruling out the possibility of reviving the original repository in the long term, the main developer considers ConsoleKit2 a temporary necessity until systembsd matures.
Development ceased in December 2017 and the project may be defunct.
However, Consolekit2 is still being maintained as a part of Gentoo Linux.

loginkit

LoginKit was an attempt to implement a logind shim, which would allow packages that depend on systemd-logind to work without dependency on a specific init system.
The project has been defunct since February 2015.

notsystemd

Notsystemd intends to implement all systemd's features working on any init system. It was forked by the Parabola GNU/Linux-libre developers to build packages with their development tools without the necessity of having systemd installed to run systemd-nspawn.

s6

s6 is a small suite of programs for UNIX, designed to allow process supervision, in the line of daemontools and runit, as well as various operations on processes and daemons. It is meant to be a toolbox for low-level process and service administration, providing different sets of independent tools that can be used within or without the framework, and that can be assembled together to achieve powerful functionality with a very small amount of code.