Product Code Database
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 Bootstrapping 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 .
Critics of systemd contend that it suffers from mission creep and software bloat, the latter affecting other software (such as the GNOME desktop), adding dependencies on systemd, reducing its compatibility with other Unix-like 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. A number of new forked Linux distributions have since been created that use alternative init systems like SysV or OpenRC. Systemd has not been adopted by Unix-like systems outside the Linux space, like FreeBSD, OpenBSD and Oracle Solaris.
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.
In October 2012, Arch Linux made systemd the default, switching from SysVinit. Developers had debated since August 2012 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. 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.
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 in his blog that Ubuntu would follow in implementing systemd, discarding its own Upstart.
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 FOSS community that rendered regular maintenance virtually impossible.
In August 2015, systemd started providing a login shell, callable via .
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". Later in 2017, the Pwnie Awards gave author Lennart Poettering a "lamest vendor response" award due to his handling of the vulnerabilities.
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 [[runlevel]]s controlled by the traditional init daemon, along with the [[shell script]]s 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 Child process; 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. 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.
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]]. 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.
is configured exclusively via [[plain|Plain text]]-[[text file]]s although GUI tools such as systemd-manager are also available.
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 script]]s. The syntax of the language is inspired by [[ files|INI file]].
| Alpine Linux | ||||
| Android | ||||
| Arch Linux | ||||
| AntiX | ||||
| Artix Linux | ||||
| CentOS | (v7.0) | |||
| CoreOS | (v94.0.0) | |||
| Debian | (v8.0) | . In bullseye, a number of alternative init systems are supported | ||
| Devuan | ||||
| Fedora Linux | (v14) | (v15) | ||
| Gentoo Linux | ||||
| GNU Guix System | ||||
| Knoppix | ||||
| Linux Mint | (v18.0) | (LMDE 3) | ||
| Mageia | (v1.0) | (v2.0) | ||
| Manjaro Linux | ||||
| openSUSE | (v11.4) | (v12.2) | ||
| Parabola GNU/Linux-libre | ||||
| Red Hat Enterprise Linux | (v7.0) | (v7.0) | ||
| Slackware | ||||
| Solus project | ||||
| Source Mage | ||||
| SUSE Linux Enterprise Server | (v12) | (v12) | ||
| Ubuntu | (v13.04) | (v15.04) | in Yaketty (16.10) | |
| 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 5.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".
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.
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 to be saddled with additional responsibilities, believing that PID 1 should only be responsible for starting the rest of the init system and reaping , and that the additional functionality added by systemd can be provided elsewhere and unnecessarily increases the complexity and attack surface of PID 1.
In March 2014, Eric S. Raymond commented 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 website 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.
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."
uselessd supported the musl and uClibc libraries, so it may have been used on , 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.
|
|
