https://DevOpsCloud.io -- Cloud Monk Losang Jinpa

Return to launchd

systemd is a software suite that provides an array of system components for Linux<ref>

</ref> operating systems. Its main aim is to unify service configuration and behavior across Linux distributions;<ref>

</ref> Its 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.<ref>

</ref> It also plays on the term “System D”, which refers to a person's ability to adapt quickly and improvise to solve problems.<ref name=“control-center” />

Since 2015, the majority of Linux distributions have adopted systemd, having replaced other init systems such as SysV init. It has been praised by developers and users of distributions that adopted it for providing a stable, fast out-of-the-box solution for issues that had existed in the Linux space for years.<ref>

</ref><ref>

</ref><ref name=“arch-migration-to-systemd”>

</ref> At the time of adoption of systemd on most Linux distributions, it was the only software suite that offered reliable parallelism during boot as well as centralized management of processes, daemons, services and mount points.

Opponents of systemd contend that it suffers from mission creep and bloat; the latter affects other software (such as the GNOME desktop) adding dependencies on systemd—complicating compatibility with other Unix-like operating systems, and making it hard to move away from. Concerns have also been raised about Red Hat and its parent company IBM controlling the scene of init systems on Linux.<ref>

</ref><ref name=“The New Stack” /> Opponents also contend that the complexity of systemd results in a larger attack surface, reducing the overall security of the platform.<ref>

</ref>

Lennart Poettering and Kay Sievers, the software engineers working for Red Hat who initially developed systemd,<ref name=“README” /> started a project to replace Linux's conventional System V init in 2010.<ref>

</ref> An April 2010 blog post from Poettering, titled “Rethinking PID 1”, introduced an experimental version of what would later become systemd.<ref>

</ref> 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 Linux became the first major Linux distribution to enable systemd by default, replacing Upstart. The reasoning at the time was that systemd provided extensive parallelization during startup, better management of processes and overall a saner, dependency-based approach to control of the system.<ref name=“fedora-systemd” />

In October 2012, Arch Linux made systemd the default, switching from SysVinit.<ref>

</ref> Developers had debated since August 2012<ref name=“arch-migration-to-systemd” /> and came to the conclusion that it was faster and had more features than SysVinit, and that maintaining the latter was not worth the effort in patches.<ref>

</ref> Some of them thought that the criticism towards the implementation of systemd was not based on actual shortcomings of the software, rather the disliking of Lennart from a part of the Linux community and the general hesitation for change. Specifically, some of the complaints regarding systemd not being programmed in bash, it being bigger and more extensive than SysVinit, the use of D-bus, and the optional on-disk format of the journal were regarded as advantages by programmers.<ref>

</ref>

Between October 2013 and February 2014, a long debate among the Debian Technical Committee occurred on the Debian mailing list,<ref name=“debian-bug” /> 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<ref name=“lwn-20131105” /><ref name=“phoronix-20131230” /> 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, discarding its own Upstart.<ref name=“Shuttleworth” /><ref name=“quantal” />

In November 2014 Debian Developer Joey Hess,<ref name=“hess-resignation” /> Debian Technical Committee members Russ Allbery<ref name=“allbery-resignation” /> and Ian Jackson,<ref name=“jackson-resignation” /> and systemd package-maintainer Tollef Fog Heen<ref name=“heen-resignation” /> 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 FOSS community that rendered regular maintenance virtually impossible.

In August 2015 systemd started providing a login shell, callable via

.<ref>

</ref>

In September 2016, a security bug was discovered that allowed any unprivileged user to perform a denial-of-service attack against systemd.<ref>

</ref> Rich Felker, developer of musl, stated that this bug reveals a major “system development design flaw”.<ref>

</ref> In 2017 another security bug was discovered in systemd,

, which “allows disruption of service” by a “malicious DNS server”.<ref>

</ref><ref>

</ref> Later in 2017, the Pwnie Awards gave author Lennart Poettering a “lamest vendor response” award due to his handling of the vulnerabilities.<ref>

</ref>

. Several systemd targets, including

telephony

,

bootmode

,

dlog

, and

tizen service

are from Tizen and are not components of systemd.<ref name=“Gundersen2014” />]]

will be accessible exclusively by systemd through

systemd-nspawn

<ref>

</ref>]]

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:<ref name=“gnome_asia_2014” />

• A system and service manager (manages both the system, by applying various configurations, and its services)
• A software platform (serves as a basis for developing other software)
• The glue between applications and the kernel (provides various interfaces that expose functionalities provided by the kernel)

Systemd includes features like on-demand starting of daemons, snapshot support, process tracking<ref>

</ref> and Inhibitor Locks.<ref>

</ref> 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.<ref name=“biggest_myths” /> 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 (see udev), scheduled execution (replacing cron), 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 (PID 1) 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.<ref name=“debian-debate” /> For inter-process communication (IPC),

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.

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:

• is a system and service manager for Linux operating systems.

• is a command to introspect and control the state of the systemd system and service manager. Not to be confused with sysctl.

• may be used to determine system boot-up performance statistics and retrieve other state and tracing information from the system and service manager.

tracks processes using the Linux kernel's cgroups subsystem instead of using process identifiers (PIDs); 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.<ref name=“lwn-20131107” /> Since version 205, systemd also offers ControlGroupInterface, which is an API to the Linux kernel cgroups.<ref name=“systemd-controller” /> The Linux kernel cgroups are adapted to support kernfs,<ref name=“lkml-20140128” /> and are being modified to support a unified hierarchy.<ref name=“lkml-20140313” />

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

    Further expansions should include descriptions of hostnamed, localed, machined, resolved, shutdownd, and timesyncd.

;

}} :

is a daemon responsible for event logging, with append-only binary files serving as its logfiles. The system administrator may choose whether to log system events with

,

or

. The potential for corruption of the binary format has led to much heated debate.<ref>

</ref> ;

}} :

is the standard library for utilizing udev, which allows third-party applications to query udev resources. ;

}} ;

}} :

is a daemon that manages user logins and seats in various ways. It is an integrated login manager that offers multiseat improvements<ref name=“logind-service” /> and replaces ConsoleKit, which is no longer maintained.<ref name=“consolekit” /> For X11 display managers the switch to

requires a minimal amount of porting.<ref name=“display-managers” /> It was integrated in systemd version 30. ;

}} :

is a daemon to handle the configuration of the network interfaces; in version 209, when it was first integrated, support was limited to statically assigned addresses and basic support for bridging configuration.<ref name=“systemd-1” /><ref name=“systemd-2” /><ref name=“systemd-3” /><ref name=“systemd-4” /><ref name=“systemd-5” /> In July 2014, systemd version 215 was released, adding new features such as a DHCP server for IPv4 hosts, and VXLAN support.<ref name=“phoronix-20140704” /><ref>

</ref>

networkctl

may be used to review the state of the network links as seen by systemd-networkd.<ref>

</ref> Configuration of new interfaces has to be added under the /lib/systemd/network/ as a new file ending with .network extension. ;

}}: provides network name resolution to local applications ;

}} :

is a boot manager, formerly known as gummiboot. Kay Sievers merged it into systemd with rev 220. ;

}} :

is a daemon that can be used to control time-related settings, such as the system time, system time zone, or selection between UTC and local time-zone system clock. It is accessible through D-Bus.<ref name=“timedated” /> It was integrated in systemd version 30. ;

}}: is a daemon that has been added for synchronizing the system clock across the network. ;

}} :

is a utility that takes care of creation and clean-up of temporary files and directories. It is normally run once at startup and then in specified intervals. ;

}} : udev is a device manager for the Linux kernel, which handles the

directory and all user space actions when adding/removing devices, including firmware loading. In April 2012, the source tree for udev was merged into the systemd source tree.<ref name=“sievers-20120403” /><ref name=“sievers-20120525” /> : On 29 May 2014, support for firmware loading through udev was dropped from systemd, as it was decided that the kernel should be responsible for loading firmware.<ref>

</ref>

is configured exclusively via plain-text files.

records initialization instructions for each daemon in a configuration file (referred to as a “unit file”) that uses a declarative language, replacing the traditionally used per-daemon startup shell scripts. The syntax of the language is inspired by {{Mono|.ini}} files.<ref>

</ref>

Unit-file types<ref name=“unitfiles” /> include:

• (automatically initiated by systemd<ref>

  </ref>)

• (which can be used as a cron-like job scheduler<ref name=“phoronix-20130128” />)

• (used to group and manage processes and resources<ref>

</ref>)

• (used to group worker processes, isn't intended to be configured via unit files<ref>

  </ref>)

<!– TODO: permute fourth and fifth columns; “runs without” is meaningless if “enabled by default” is false –>

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<ref>

</ref><ref>

</ref> and has reached version 4.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”.<ref>

</ref>

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.<ref name=“Poettering-GNOME” />

In November 2012, the GNOME Project concluded that basic GNOME functionality should not rely on systemd.<ref name=“Paters” /> 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.<ref name=“consolekit-abandoned” /> 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.<ref name=“Vitters” /><ref name=“wayland” />

GNOME has further integrated

.<ref name=“systemd-gnome” /> As of Mutter version 3.13.2,

is a dependency for Wayland sessions.<ref name=“mutter-logind” />

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, which is similar to the problems created by PulseAudio, another project which was also developed by Lennart Poettering.<ref>

</ref><ref>

</ref>

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.<ref name=“volkerding-2012” />

, Slackware does not support or use systemd, but Volkerding has not ruled out the possibility of switching to it.<ref name=“slackware-systemd” />

In January 2013, Lennart Poettering attempted to address concerns about systemd in a blog post called The Biggest Myths.<ref name=“biggest_myths” />

In February 2014, musl's Rich Felker opined that PID 1 is too special to be saddled with additional responsibilities. PID 1 should only be responsible for starting the rest of the init system and reaping zombie processes. The additional functionality added by systemd can be provided elsewhere and unnecessarily increases the complexity and attack surface of PID 1.<ref>Broken by design: systemd, Rich Felker, main author of musl, 9 February 2014.</ref>

In March 2014 Eric S. Raymond opined that systemd's design goals were prone to mission creep and software bloat.<ref name=“esr-slashdot-2014” /> 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.<ref name=“lkml-20140402” /> In late April 2014 a campaign to boycott systemd was launched, with a website listing various reasons against its adoption.<ref name=“upload” /><ref name=“boycott” />

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”.<ref name=“apocalypse” /> 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.<ref name=“apocalypse” />

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.<ref name=“zdnet-20140919” /> On social media, Ts'o also later compared the attitudes of Sievers and his co-developer, Lennart Poettering, to that of GNOME's developers.<ref name=“Tso” />

Forks of systemd are closely tied to critiques of it outlined in the above section. Forks generally try to improve on at least one of portability (to other libcs and Unix-like systems), modularity, or size. A few forks have collaborated under the FreeInit banner.<ref>

</ref>

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.<ref name=“eudev” /> A stated goal of the project is to keep eudev independent of any Linux distribution or init system.<ref name=“gentoo-eudev” /> In 2021, Gentoo announced that support of eudev would cease at the beginning of 2022. An independent group of maintainers have since taken up eudev.<ref name=“eudev-news”>

</ref>

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

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.<ref name=“elogind” />

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.<ref name=“consolekit2” /> Development ceased in December 2017 and the project may be defunct.<ref>

</ref>

LoginKit was an attempt to implement a logind (systemd-logind) shim, which would allow packages that depend on systemd-logind to work without dependency on a specific init system.<ref name=“loginkit” /> The project has been defunct since February 2015.<ref>

</ref>

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.<ref name=“undeadly_systembsd” /> Project development finished in July 2016.<ref>

</ref>

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.”<ref name=“undeadly_systembsd” />

Notsystemd intends to implement all systemd's features working on any init system.<ref>

</ref> 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.

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.<ref name=“phoronix_uselessd” /> Project development halted in January 2015.<ref>

</ref>

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.<ref name=“uselessd_home” />

InitWare is a modular refactor of systemd, porting the system to BSD platforms without glibc or Linux-specific system calls. It is known to work on DragonFly BSD, FreeBSD, NetBSD, and GNU/Linux. Components considered unnecessary are dropped.<ref>

</ref>

• BusyBox
• launchd
• Linux distributions without systemd
• Operating system service management
• readahead
• runit
• Service Management Facility
• GNU Daemon Shepherd
• Upstart

</ref> <ref name=“license”>

</ref> <ref name=“unitfiles”>

</ref> <ref name = control-center>

</ref> <ref name=“debian-debate”>

</ref> <ref name=“biggest_myths”>

</ref> <ref name=“gnome_asia_2014”>

</ref> <ref name=“Gundersen2014”>

</ref> <ref name=“phoronix-20130128”>

</ref> <ref name=“lwn-20131107”>

</ref> <ref name=“systemd-controller”>

</ref> <ref name=“lkml-20140128”>

</ref> <ref name=“lkml-20140313”>

</ref> <ref name=“logind-service”>

</ref> <ref name=“consolekit”>

</ref> <ref name=“display-managers”>

</ref> <ref name=“systemd-1”>

</ref> <ref name=“systemd-2”>

</ref> <ref name=“systemd-3”>

</ref> <ref name=“systemd-4”>

</ref> <ref name=“systemd-5”>

</ref> <ref name=“phoronix-20140704”>

</ref> <ref name=“timedated”>

</ref> <ref name=“sievers-20120403”>

</ref> <ref name=“sievers-20120525”>

</ref> <ref name=“fedora-systemd”>

</ref> <ref name=“slackware-systemd”>

</ref> <ref name=“arch-git”>

</ref> <ref name=“arch-systemd”>

</ref> <ref name=“coreos-systemd”>

</ref> <ref name=“coreos-github”>

</ref> <ref name=“debian-systemd”>

</ref> <ref name=“ctte-20140211”>

</ref> <ref name=“Fedora 14”>

</ref> <ref name=“gentoo-handbook”>

</ref> <ref name=“gentoo-bugzilla”>

</ref> <ref name=“gentoo-doc”>

</ref> <ref name=“gentoo-wiki-systemd”>

</ref> <ref name=“mageia1”>

</ref> <ref name=“mageia”>

</ref> <ref name=“opensuse”>

</ref> <ref name=“AutoWR-1”>

</ref> <ref name=“rhel”>

</ref> <!– <ref name=“ubuntu-wiki”>

</ref> <ref name=“ubuntu-planned-systemd”>

</ref> –> <ref name=“debian-bug”>

</ref> <ref name=“lwn-20131105”>

</ref> <ref name=“phoronix-20131230”>

</ref> <ref name=“Shuttleworth”>

</ref> <ref name=“quantal”>

</ref> <ref name=“Poettering-GNOME”>

</ref> <ref name=“Paters”>

</ref> <ref name=“consolekit-abandoned”>

</ref> <ref name=“Vitters”>

</ref> <ref name=“wayland”>

</ref> <ref name=“systemd-gnome”>

</ref> <ref name=“mutter-logind”>

</ref> <ref name=“volkerding-2012”>

</ref> <ref name=“apocalypse”>

</ref> <ref name=“allbery-resignation”>

</ref> <ref name=“hess-resignation”>

</ref> <ref name=“jackson-resignation”>

</ref> <ref name=“heen-resignation”>

</ref> <ref name=“lkml-20140402”>

</ref> <ref name=“esr-slashdot-2014”>

</ref> <ref name=“Tso”>

</ref> <ref name=“boycott”>

</ref> <ref name=“upload”>

</ref> <ref name=“eudev”>

</ref> <ref name=“elogind”>

</ref> <ref name=“gentoo-eudev”>

</ref> <ref name=“phoronix_uselessd”>

</ref> <ref name=“uselessd_home”>

</ref> <ref name=“undeadly_systembsd”>

</ref> <ref name=“consolekit2”>

</ref> <ref name=“loginkit”>

</ref> <ref name=“zdnet-20140919”>

</ref> <!– <ref name=“ubuntu-vivid-switch”>

</ref> –> <ref name=“ubuntu-init-switch”>

</ref> <!– <ref name=“official_website”>

</ref> <ref name=“official_systemd_system_and_service_manager_github”>

</ref>–> <ref name=“launchpad-upstart-packages”>

</ref>

}}

• Rethinking PID 1

Snippet from Wikipedia: Systemd

systemd is a software suite that provides an array of system components for Linux operating systems. The main aim is to unify service configuration and behavior across Linux distributions. Its 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 init systems such as SysV init. It has been praised by developers and users of distributions that adopted it for providing a stable, fast out-of-the-box solution for issues that had existed in the Linux space for years. At the time of adoption of systemd on most Linux distributions, it was the only software suite that offered reliable parallelism during boot as well as centralized management of processes, daemons, services and mount points.

Critics of systemd contend that it suffers from mission creep and bloat, the latter affecting other software (such as the GNOME desktop), adding dependencies on systemd, reducing its compatibility with other Unix-like operating systems and making it difficult for sysadmins to integrate alternative solutions. In addition, they contend that the complexity of systemd results in a larger attack surface, reducing the overall security of the platform. Concerns have also been raised about Red Hat and its parent company IBM controlling the scene of init systems on Linux.

Creative Commons Attribution-Share Alike 4.0

navbar_rhel