Hubbry Logo
SystemdSystemdMain
Open search
Systemd
Community hub
Systemd
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Systemd
Systemd
Systemd
View on Wikipedia
from Wikipedia

systemd
Original authorLennart Poettering[1]
DevelopersRed Hat (Lennart Poettering, Kay Sievers, Harald Hoyer, Daniel Mack, Tom Gundersen, David Herrmann);[2] 345 different authors in 2018[3] and 2,032 different authors in total [4]
Initial release30 March 2010; 15 years ago (2010-03-30)
Stable release
258.2[5] Edit this on Wikidata / 7 November 2025
Repository
Written inC
Operating systemLinux
Type
LicenseLGPLv2.1+[6]
Websitesystemd.io

systemd is a software suite for system and service management on Linux[7] built to unify service configuration and behavior across Linux distributions.[8] Its main component is 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,[9] and also plays on the French phrase Système D (a person's ability to quickly adapt and improvise in the face of problems).[10]

Since 2015, nearly all Linux distributions have adopted systemd. 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.[11][12][13] At the time of its adoption, it was the only parallel boot and init system offering centralized management of processes, daemons, services, and mount points [citation needed].

Critics of systemd contend it suffers from feature creep and has damaged interoperability across Unix-like operating systems (as it does not run on non-Linux Unix derivatives like BSD or Solaris). In addition, they contend systemd's large feature set creates a larger attack surface.[14] This has led to the development of several minor Linux distributions replacing systemd with other init systems like SysVinit or OpenRC.[15]

History

[edit]

Lennart Poettering and Kay Sievers, the software engineers then working for Red Hat who initially developed systemd,[2] started a project to replace Linux's conventional System V init in 2010.[16] An April 2010 blog post from Poettering, titled "Rethinking PID 1", introduced an experimental version of what would later become systemd.[17] 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 processes to run 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.[18]

In October 2012, Arch Linux made systemd the default, switching from SysVinit.[19] Developers had debated since August 2012[13] and concluded it was faster and had more features than SysVinit and that maintaining SysVinit was not worth the effort.[20] Some thought the criticism of systemd was not based on actual shortcomings of the software but rather personal dislike of Poettering and a general opposition to change. Several complaints about systemd—including its use of D-bus, C instead of bash, and an optional on-disk journal format—were instead described as advantages by the Arch maintainers.[21]

Between 2013 and 2014, the Debian Technical Committee engaged in a widely publicized debate on the mailing list about which init system to use as the default in Debian 8 before settling on systemd.[22][23][24] Soon after, Debian developer Joey Hess,[25] Technical Committee members Russ Allbery[26] and Ian Jackson,[27] and systemd package maintainer Tollef Fog Heen[28] resigned from their positions, citing the extraordinary levels of stress caused by disputes on systemd integration within the Debian and FOSS community that rendered regular maintenance virtually impossible. Mark Shuttleworth announced soon afterwards that the Debian-based Ubuntu would use systemd to replace its old Upstart init system.[29][30]

In August 2015, systemd started providing a login shell, callable via machinectl shell.[31]

In September 2016, a security bug was discovered that allowed any unprivileged user to perform a denial-of-service attack against systemd.[32] Rich Felker, developer of musl, stated that this bug reveals a major "system development design flaw".[33] In 2017 another security bug was discovered in systemd-resolved, CVE-2017-9445, which "allows disruption of service" by a "malicious DNS server".[34][35] Later in 2017, the Pwnie Awards gave author Lennart Poettering a "lamest vendor response" award due to his handling of the vulnerabilities.[36]

Design

[edit]
The architecture of systemd as it is used by Tizen. Several systemd targets, including telephony, bootmode, dlog, and tizen service are from Tizen and are not components of systemd.[37]
Unified-hierarchy cgroups will be accessible exclusively by systemd through systemd-nspawn.[38]

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:[39]

  • 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[40] and Inhibitor Locks.[41] 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 systemd init daemon, includes the daemons journald, logind and networkd, 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.[42] 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, systemd is a daemon that manages other daemons, which, including systemd itself, are background processes. systemd is the first daemon to start during booting and the last daemon to terminate during shutdown. The systemd 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.

systemd executes elements of its startup sequence in parallel, which is theoretically faster than the traditional startup sequence approach.[43] For inter-process communication (IPC), systemd makes Unix domain sockets and D-Bus available to the running daemons. The state of systemd itself can also be preserved in a snapshot for future recall.

Core components and libraries

[edit]

Following its integrated approach, systemd also provides replacements for various daemons and utilities, including the startup shell scripts, pm-utils, inetd, acpid, syslog, watchdog, cron and atd. systemd's core components include:

  • systemd is a system and service manager for Linux operating systems.
  • systemctl is a command to introspect and control the state of the systemd system and service manager. Not to be confused with sysctl.
  • systemd-analyze may be used to determine system boot-up performance statistics and retrieve other state and tracing information from the system and service manager.

systemd tracks processes using the Linux kernel's cgroups subsystem instead of using process identifiers (PIDs); thus, daemons cannot "escape" systemd, not even by double-forking. systemd not only uses cgroups, but also augments them with systemd-nspawn and machinectl, two utility programs that facilitate the creation and management of Linux containers.[44] Since version 205, systemd also offers ControlGroupInterface, which is an API to the Linux kernel cgroups.[45] The Linux kernel cgroups are adapted to support kernfs,[46] and are being modified to support a unified hierarchy.[47]

Ancillary components

[edit]

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

A screenshot of systemd-boot
A screenshot of timedatectl
journald
systemd-journald 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 systemd-journald, syslog-ng or rsyslog. The potential for corruption of the binary format has led to much heated debate.[48]
libudev
libudev is the standard library for utilizing udev, which allows third-party applications to query udev resources.
localed
localed manages the system locale and keyboard layout.
logind
systemd-logind is a daemon that manages user logins and seats in various ways. It is an integrated login manager that offers multiseat improvements[49] and replaces ConsoleKit, which is no longer maintained.[50] For X11 display managers the switch to logind requires a minimal amount of porting.[51] It was integrated in systemd version 30.
hostnamed
hostnamed manages the system hostname.
homed
homed is a daemon that provides portable human-user accounts that are independent of current system configuration. homed moves various pieces of data such as UID/GID from various places across the filesystem into one file, ~/.identity. homed manages the user's home directory in various ways such as a plain directory, a btrfs subvolume, a Linux Unified Key Setup volume, an fscrypt directory, or mounted from an SMB server.
networkd
networkd 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.[52][53][54][55][56] In July 2014, systemd version 215 was released, adding new features such as a DHCP server for IPv4 hosts, and VXLAN support.[57][58] networkctl may be used to review the state of the network links as seen by systemd-networkd.[59] Configuration of new interfaces has to be added under the /lib/systemd/network/ as a new file ending with .network extension.
resolved
provides network name resolution to local applications
systemd-boot
systemd-boot is a boot manager, formerly known as gummiboot. Kay Sievers merged it into systemd with rev 220.
systemd-bsod
systemd-bsod is an error reporter used to generate Blue Screen of Death.
systemd-nspawn
systemd-nspawn may be used to run a command or OS in a namespace container.
timedated
systemd-timedated 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.[60] It was integrated in systemd version 30.
timesyncd
timesyncd is a client NTP daemon for synchronizing the system clock across the network.
tmpfiles
systemd-tmpfiles 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.
udevd
udev is a device manager for the Linux kernel, which handles the /dev 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.[61][62] In order to match the version number of udev, systemd maintainers bumped the version number directly from 44 to 183.[63]
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.[64]

Configuration of systemd

[edit]
systemd-manager, a tool to configure systemd

systemd is configured exclusively via plain-text files although GUI tools such as systemd-manager are also available.

systemd 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 .ini files.[65]

Unit-file types[66] include:

  • .service
  • .socket
  • .device (automatically initiated by systemd[67])
  • .mount
  • .automount
  • .swap
  • .target
  • .path
  • .timer (which can be used as a cron-like job scheduler[68])
  • .snapshot
  • .slice (used to group and manage processes and resources[69])
  • .scope (used to group worker processes, not intended to be configured via unit files[70])

Adoption

[edit]
Linux distribution Date added to software repository[a] Enabled by default? Date released as default Runs without?
Alpine Linux N/A (not in repository) No N/A Yes
Android N/A (not in repository) No N/A Yes
Arch Linux January 2012[71] Yes October 2012[72] Although Arch provides installation instructions for OpenRC and other init systems are available in the AUR, Arch officially supports only systemd.[73][74]
antiX Linux N/A (not in repository) No N/A Yes
Artix Linux N/A (not in repository) No N/A Yes
CentOS July 2014 Yes July 2014 (v7.0) No
CoreOS July 2013 Yes October 2013 (v94.0.0)[75][76] No
Debian April 2012[77] Yes April 2015 (v8.0)[78] Jessie is the last release supporting installing without systemd.[79] In bullseye, a number of alternative init systems are supported
Devuan N/A (not in repository) No N/A Yes
Fedora Linux November 2010 (v14)[80] Yes May 2011 (v15) No
Gentoo Linux[b] July 2011[81][83][84] Optional[85] N/A Yes
GNU Guix System N/A (not in repository) No N/A Yes
Knoppix N/A No [86][87] N/A Yes
Linux Mint June 2016 (v18.0) Yes August 2018 (LMDE 3) No [88]
Mageia January 2011 (v1.0)[89] Yes May 2012 (v2.0)[90] No [91]
Manjaro Linux November 2013 Yes November 2013 No
openSUSE March 2011 (v11.4)[92] Yes September 2012 (v12.2)[93] No
Parabola GNU/Linux-libre January 2012[71] Optional[94] N/A Yes
Red Hat Enterprise Linux June 2014 (v7.0)[95] Yes June 2014 (v7.0) No
Slackware N/A (not in repository) No N/A Yes
Solus N/A Yes N/A No
Source Mage June 2011[96] No N/A Yes
SUSE Linux Enterprise Server October 2014 (v12) Yes October 2014 (v12) No
Ubuntu April 2013 (v13.04) Yes April 2015 (v15.04) Upstart option removed in Yaketty (16.10)[97][98][c]
Void Linux June 2011, removed June 2015[99] No N/A Yes

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[100][101] 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".[102]

Integration with other software

[edit]

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.[103]

In November 2012, the GNOME Project concluded that basic GNOME functionality should not rely on systemd.[104] However, GNOME 3.8 introduced a compile-time choice between the logind and ConsoleKit API, the former being provided at the time only by systemd. Ubuntu provided a separate logind 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 systemd-logind instead.[105] 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.[106][107]

GNOME has further integrated logind.[108] As of Mutter version 3.13.2, logind is a dependency for Wayland sessions.[109]

Reception

[edit]

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 of Lennart Poettering's projects.[110][111]

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.[112] As of August 2018, Slackware does not support or use systemd, but Volkerding has not ruled out the possibility of switching to it.[113]

In January 2013, Lennart Poettering attempted to address concerns about systemd in a blog post called The Biggest Myths.[42]

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 zombie processes, and that the additional functionality added by systemd can be provided elsewhere and unnecessarily increases the complexity and attack surface of PID 1.[114]

In March 2014, Eric S. Raymond commented that systemd's design goals were prone to mission creep and software bloat.[115] 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.[116] In late April 2014, a campaign to boycott systemd was launched, with a website listing various reasons against its adoption.[117][118]

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".[119] 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.[119]

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.[120] On social media, Ts'o also later compared the attitudes of Sievers and his co-developer, Lennart Poettering, to that of GNOME's developers.[121]

Forks and alternative implementations

[edit]

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.[122]

Forks of components

[edit]

eudev

[edit]

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.[123] A stated goal of the project is to keep eudev independent of any Linux distribution or init system.[124] 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.[125]

elogind

[edit]

Elogind is the systemd project's "logind", extracted 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.[126]

Alternatives to components

[edit]

ConsoleKit2

[edit]

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.[127]

Abandoned forks

[edit]

Fork of components

[edit]
LoginKit
[edit]

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.[128] The project has been defunct since February 2015.[129]

systembsd
[edit]

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.[130] Project development finished in July 2016.[131]

The systembsd project did not provide an init replacement, but aimed to provide OpenBSD with compatible daemons for hostnamed, timedated, localed, and logind. 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."[130]

notsystemd
[edit]

Notsystemd intends to implement all systemd's features working on any init system.[132] 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. Development ceased in July 2018.[133]

Fork including init system

[edit]
uselessd
[edit]

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.[134] Project development halted in January 2015.[135]

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.[136]

InitWare
[edit]

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.[137]

All Systems Go!

[edit]
Lennart Poettering speaking at All Systems Go! 2024

All Systems Go! is the annual systemd conference, which is held in Berlin.[138] The main topic is systemd but other Linux areas are covered as well, like TPM, DBus, desktop environment, containers, eBPF etc.

See also

[edit]

Notes

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Systemd

View on Grokipedia
from Grokipedia
systemd is a suite of software components serving as the system and service manager for operating systems, functioning as the initial process (PID 1) to and initialize the kernel, hardware, and user space services while providing ongoing supervision of processes, logging, device management, and network configuration. Developed primarily by engineers Lennart Poettering and Kay Sievers, systemd was first released in 2010 as a replacement for legacy systems like SysV , introducing parallel service startup, dependency-based activation, and integration with modern kernel features such as and sockets for improved efficiency and reliability. Its adoption began with in 2011 and rapidly expanded to distributions including and in 2012, becoming the default in nearly all major distributions by 2015 due to enhancements in boot performance and service management. However, systemd's expansive scope—encompassing not just but also tools like journald for structured and networkd for networking—has fueled ongoing controversies in the open-source community, with critics arguing it deviates from Unix principles by centralizing too many functions into a monolithic framework, potentially complicating and increasing vulnerability surfaces.

History

Conception and Early Development

Systemd originated from discussions between Lennart Poettering, a developer at Red Hat, and Kay Sievers, then at Novell, who outlined its core concepts—initially under the working name "Babykit"—during a flight returning from the 2009 Linux Plumbers Conference. The initiative aimed to address longstanding deficiencies in Linux initialization systems, such as the serial execution and dependency resolution limitations of SysV init, which led to prolonged boot times and inefficient service management, as well as shortcomings in alternatives like Upstart, including poor dependency handling and licensing constraints. Poettering and Sievers sought a unified, event-driven approach leveraging socket activation for on-demand service startup, parallel processing via cgroups for resource supervision, and reduced reliance on shell scripts to minimize overhead and errors. On April 30, 2010, Poettering publicly proposed systemd in his blog post "Rethinking PID 1," advocating for PID 1 to serve as a sophisticated process manager capable of parallelizing service activation, integrating for , and employing filesystem autofs for concurrent mounting, drawing inspiration from macOS's while adapting to Linux's kernel features like control groups. This marked the formal conception, emphasizing empirical improvements in boot performance—targeting reductions from minutes to seconds through maximized parallelism—and causal dependencies modeled explicitly rather than via brittle scripts. The proposal critiqued existing systems' inability to handle modern hardware dynamics, such as hotplug events, without manual intervention. Early development ensued rapidly under Poettering's lead at , with Sievers contributing significantly to core implementations, alongside Harald Hoyer and others from SUSE, , and . Experimental code was made available via a public repository shortly after the announcement, enabling initial testing on development systems and virtual machines, though limited to minimal validation due to its nascent state. The focus was on prototyping key innovations, including socket-based and D-Bus-triggered activation to decouple service readiness from boot sequencing, and integrating with existing tools like for device management, setting the stage for broader evaluation before distribution integration. By late 2010, prototypes demonstrated viability for replacing SysV in enterprise environments, prioritizing reliability over completeness.

Widespread Adoption and Key Milestones

systemd was initially released on March 30, 2010, by developers and Kay Sievers at . adopted systemd as its default system with Fedora 15, released on May 24, 2011, marking the first major to integrate it and replace Upstart. This early adoption by , sponsored by , facilitated systemd's development and testing in a production environment. Subsequent integrations accelerated in 2012, with and switching to systemd as their primary service manager, enabling parallel boot processes and socket activation features. By 2014, Debian's technical committee voted to adopt systemd following internal debates, implementing it as the default in Debian 8 (Jessie), released on April 26, 2015. Ubuntu followed suit, transitioning from Upstart to systemd in 15.04 (Vivid Vervet), released on April 23, 2015, after an announcement in February 2014. These milestones propelled systemd's dominance; by mid-2015, it had supplanted SysVinit across most prominent distributions, including derivatives like and RHEL, powering over 90% of server and desktop deployments due to its efficiency in service management and dependency handling. Adoption continued with minor distributions and embedded systems, solidifying systemd's role in unifying initialization despite ongoing debates over its scope.

Recent Evolution and Releases

Systemd 257, released in December 2024, introduced support for in socket units, enabling more robust network connectivity options, and added the PrivatePIDs= directive to allow processes to run as PID 1 within their own for enhanced isolation. It also deprecated System V service script support, signaling a shift away from legacy compatibility, and disabled cgroup v1 by default (requiring an to re-enable), with full removal planned for the subsequent version. New tools included systemd-sbsign for Secure Boot EFI binary signing, alongside refinements like reworked systemd-tmpfiles --purge behavior limited to specific flagged lines. The subsequent systemd 258, released on September 17, 2025, fully removed cgroup v1 support and raised the minimum supported version to 5.4, aligning with modern hardware and standards while dropping compatibility for older systems. Key additions encompassed new utilities such as systemd-factory-reset for initiating a on and systemd-pty-forward for secure pseudo-TTY allocation, alongside the ability to embed firmware images directly into Unified Kernel Images (UKIs). enhancements included default 0600 permissions for TTY/PTS devices, PID file descriptors for logind session tracking, and exclusive reliance on as the cryptographic backend, eliminating alternative TLS options. System V style controls and the SystemdOptions EFI variable were also excised. These releases reflect systemd's ongoing evolution toward stricter security postures, reduced legacy overhead, and integration with contemporary capabilities, with v259 anticipated to eliminate remaining System V service script support entirely. Maintenance releases, such as v257.10 in 2025, have focused on bug fixes and stability without major feature additions. The project's cadence of roughly semiannual major updates continues to drive refinements in service management, resource control, and efficiency across adopting distributions.

Design and Architecture

Foundational Principles

systemd's foundational principles center on replacing the sequential, script-based limitations of traditional SysVinit systems with a unified, Linux-optimized framework for initializing and managing userspace services as PID 1. Developed primarily by and Kay Sievers, it prioritizes leveraging kernel-specific capabilities such as for precise process tracking and resource isolation, moving beyond unreliable PID files used in older init systems. This approach ensures robust supervision, where systemd monitors service processes directly via , enabling automatic restarts and failure detection without external dependencies. A core tenet is aggressive parallelization of boot tasks, allowing independent services to activate concurrently based on dependencies rather than fixed scripts, which reduces boot times from minutes to seconds in many configurations— 15, the first major adopter in May 2011, demonstrated boot reductions to under 5 seconds for basic targets. Dependency handling employs a transactional model with directives like After= and Requires=, resolving cycles and queuing jobs to maintain system integrity during state changes. Event-driven mechanisms—encompassing socket, , path, device, and events—facilitate on-demand service startup, conserving resources by deferring non-essential daemons until invoked, reviving and extending Unix socket concepts for modern . Standardization forms another pillar, with portable unit files describing services uniformly across distributions, mitigating the fragmentation of ad-hoc shell scripts and enabling upstream developers to target a consistent interface. Integration with security modules like SELinux and PAM, alongside features such as automounting and runtime directory management, underscores a philosophy of holistic system bootstrapping, where disparate tools are consolidated into a cohesive suite without sacrificing modularity. This design emphasizes predictability and reproducibility, unloading inactive units to minimize memory footprint and ensuring clean shutdowns through cgroup freezing, addressing empirical inefficiencies in legacy systems where services often lingered post-failure.

Core Components

The core of systemd comprises the central process and a set of integrated daemons that handle essential functions such as logging, device management, and user sessions, replacing disparate traditional tools with a unified framework. These components operate as services managed by systemd itself, leveraging for and for resource control. systemd, running as PID 1, acts as the primary system and service manager. It bootstraps the user space during boot, parallelizes service startup based on dependency graphs defined in unit files, and supports mechanisms like socket listening and requests to minimize idle processes. Additionally, it oversees mounts, automounts, and process trees via , ensuring fault isolation and resource limits. systemd-journald functions as the logging subsystem, aggregating messages from the kernel, early boot stages, stdout/stderr of services, and logs into a binary, indexed format stored in /var/log/journal. This enables structured querying with tools like journalctl, persistent storage across reboots, and forwarding to external daemons, improving on traditional or syslog-ng by capturing pre-daemon logs. systemd-logind oversees user authentication and session lifecycle, tracking logged-in users, graphical and console sessions, and multi-seat configurations. It handles events like lid closures for , inhibits shutdowns during active sessions, and provides methods for session queries, facilitating integration with display managers like GDM. systemd-logind also manages inhibition of various system actions, including "sleep" (suspend-to-RAM), to prevent interruptions during active sessions or operations. Active inhibitors are displayed by systemd-inhibit --list, where the "What" column specifies the inhibited action; suspend is blocked only if "sleep" appears in this column for at least one inhibitor. In the absence of a "sleep" inhibitor, suspend proceeds normally. Failures or hangs during suspend are typically attributable to hardware, driver (such as proprietary graphics drivers), kernel modules, or firmware issues rather than inhibition status. Diagnostic logs are available via journalctl -b -1 -u systemd-suspend.service or dmesg. systemd-udevd manages dynamic device handling by processing kernel uevents, creating /dev entries, and applying udev rules for permissions, symlinks, and ownership. As a systemd-native service, it benefits from dependency-aware startup, enabling faster boot times compared to the independent udev daemon it supersedes. Supporting these are daemons like systemd-timedated for NTP synchronization and timezone adjustments via timedatectl, systemd-hostnamed for dynamic hostname changes, and systemd-localed for locale and keyboard layout management, all exposing user-friendly command-line interfaces while maintaining declarative configurations.

Ancillary Tools and Libraries

libsystemd serves as the principal library for applications seeking to interface with systemd's capabilities, encompassing APIs for service notification, communication, and interactions. It includes modules such as sd-daemon for enabling daemons to signal readiness to the systemd manager via file descriptors and sd_notify for protocol-based notifications. A prominent subset is sd-bus, an asynchronous client library integrated into libsystemd, designed for efficient without reliance on higher-level bindings. Stabilized in systemd version 221 on October 31, 2015, sd-bus supports both system and user bus connections, method calls, signal handling, and property access, prioritizing minimal dependencies and direct socket usage over the full D-Bus library. Ancillary tools complement these libraries by providing diagnostic and introspection utilities. systemd-analyze inspects boot performance metrics, including time-to-ready measurements and dependency graphs via commands like blame for unit activation durations and critical-chain for sequential startup paths. busctl facilitates introspection, enabling enumeration of services, objects, interfaces, and properties on connected buses, as well as direct method invocation for testing. Additional utilities include journalctl for retrieving and filtering binary logs from systemd-journald, supporting queries by time, priority, unit, or identifier with options for real-time tailing and output formatting. These tools, distributed within systemd packages, enhance developer and administrator workflows by leveraging libsystemd APIs for programmatic access where command-line interaction suffices for ad-hoc analysis.

Features and Functionality

Service Management and Units

In systemd, units represent the fundamental resources managed by the and service manager, including processes, filesystems, network sockets, and other system objects. Each unit is defined by a in INI-style format, typically with a suffix indicating its type, such as .service for or .socket for network listeners. These files encode dependencies, activation conditions, and runtime behavior, enabling declarative management over imperative scripting used in predecessors like SysV init. Systemd supports 11 unit types: service, socket, target, device, mount, automount, swap, timer, path, slice, and scope. Service units specifically handle the starting, stopping, and supervision of daemon processes, tracking their main process ID (PID) for reliable and automatic restarts if configured. Socket units activate services on-demand via incoming connections, reducing idle resource usage, while target units group other units into milestones like multi-user.target for boot phases. Slices and scopes manage resource allocation via , enforcing limits on CPU, memory, and I/O for services. Service management occurs primarily through the systemctl command-line tool, which introspects unit states, issues control operations, and queries dependencies. Common operations include systemctl start <unit> to launch a service, systemctl stop <unit> to terminate it, systemctl enable <unit> to link it for automatic startup at via symlinks in /etc/systemd/system/, and systemctl status <unit> to display runtime details like active state, logs, and PIDs. Enabling persists across reboots by installing wanted-by links to , while masking units prevents activation entirely. Systemd reloads configurations dynamically with systemctl daemon-reload after editing unit files, ensuring changes take effect without full restarts. Unit files are stored hierarchically: vendor-provided in /usr/lib/systemd/ (immutable), administrator overrides in /etc/systemd/system/, and transient runtime units generated in /run/systemd/. A typical service unit file structure includes a [Unit] section for metadata like , After/Before dependencies, and Wants/Requires for ; a [Service] section with Type (e.g., simple for forking daemons, notify for readiness signals), ExecStart for the command, Restart directives, and cgroup limits; and an [Install] section with WantedBy for enabling. Drop-in overrides in /etc/systemd/system/.d/ allow targeted modifications without altering originals, preserving upgradability.

Per-User Instances

systemd supports per-user instances of the service manager, enabling users to manage their own services, timers, sockets, paths, and other units independently of the system instance via systemctl --user. The per-user manager typically starts automatically upon graphical login or certain PAM sessions that set up the necessary environment. However, in non-interactive sessions (such as SSH logins, cron jobs, or boot-time scripts) or without a graphical/PAM-triggered login, the per-user manager may not be running, leading to errors when invoking systemctl --user, such as "systemctl --user unavailable", "unknown error", or "Failed to connect to bus: No such file or directory". To ensure the per-user manager runs persistently—starting at boot and continuing after logout—enable lingering for the user by executing loginctl enable-linger $USER (run as the user, without superuser privileges). This configuration starts the user manager at boot and maintains it indefinitely. After enabling lingering, reload the user configuration with systemctl --user daemon-reload and then enable/start desired user services (e.g., systemctl --user enable --now example.service). Verify successful connection with systemctl --user status. Additional causes of connection failures include an unset or incorrect XDG_RUNTIME_DIR (which should be /run/user/$(id -u)); if unset, log out and log in again or source the shell profile to restore it. On minimal installations or containers, ensure the dbus-user-session package is installed and that systemd-logind is active. This behavior is standard in systemd and is especially relevant for headless systems like Raspberry Pi, where background or always-on user services are common.

Boot Process and Resource Control

Systemd initializes the system as process ID 1 (PID 1), replacing traditional systems by parsing unit files to construct a for services, sockets, mounts, and other resources. It activates units in parallel when dependencies permit, leveraging modern multi-core processors to execute independent startup tasks concurrently, such as mounting filesystems and launching daemons, rather than sequentially as in SysV . This parallelization, introduced with systemd's release on March 30, 2010, has empirically reduced times; for instance, early adopters like 15 reported boot durations dropping from over 20 seconds to under 10 seconds in multi-user mode compared to prior systems. The sequence progresses through —special units akin to runlevels—starting from sysinit.target for core system initialization (e.g., settlement, local-fs.target), advancing to basic.target, then multi-user.target for networked services, and optionally graphical.target. Dependencies are declared via directives like After=, Requires=, and Wants=, ensuring ordered activation while maximizing parallelism; for example, network-independent services start immediately without awaiting network-online.target. Systemd also handles first-boot setup, generating machine-id and applying unit automatically. Tools like systemd-analyze quantify boot performance by timing critical chain paths and individual units, aiding optimization. For resource control, systemd integrates with Linux control groups (cgroups) to enforce limits on CPU, memory, I/O, and device access for unit-managed processes, organizing them into hierarchical slices, scopes, and services. Directives in unit files, such as MemoryMax=, CPUQuota=, and IOWeight=, apply these controls; for example, MemoryMax=500M caps a service's RAM usage, preventing system-wide exhaustion. Systemd supports both cgroups v1 (via controllers like cpu, ) and the unified cgroups v2 hierarchy, enabled via kernel boot parameters like systemd.unified_cgroup_hierarchy=1, which delegates resource delegation to child controllers for finer-grained management. In cgroups v2 mode, adopted by default in distributions like RHEL 8 onward when configured, systemd binds the unit tree to cgroup paths (e.g., /system.slice/[httpd](/page/Httpd).service), enabling automatic enforcement and monitoring without manual cgroup manipulation. This integration allows slicing resources across user sessions (user.slice) and system services (system.slice), with empirical benefits in container and multi-tenant environments by isolating workloads and averting .

Logging and System Monitoring

systemd-journald serves as the primary logging daemon, collecting and storing log data from multiple sources including the kernel via kmsg, traditional messages, the native Journal API, stdout and stderr streams from services, and subsystem records. Logs are maintained in a structured, indexed binary format with metadata fields supporting up to 2⁶⁴-1 bytes each, enabling efficient querying without reliance on external text parsers. This approach replaces fragmented -based systems by centralizing logs under a unified , with support for isolated journal s to separate log streams for different environments. Storage occurs either persistently in /var/log/journal—requiring the directory's existence and configuration—or volatalily in /run/log/journal, where data is discarded on . Automatic vacuuming manages disk usage by discarding old or oversized entries, eliminating manual rotation typical in legacy systems. Configuration is handled via /etc/systemd/journald.conf (introduced in systemd version 206), allowing options like forwarding logs to , console, or , with kernel command-line overrides available since version 186. Integration supports tools like systemd-cat for piping application output into the journal and passing for enhanced since version 256. The journalctl command provides querying and display capabilities for journal logs, supporting filters by unit (-u), boot ID (-b), priority (-p), time ranges (--since, --until), or custom fields with logic. Output formats include short, verbose (showing all fields with -a), , or export formats for , with real-time monitoring via --follow (-f) for ongoing log tailing. This enables by correlating events across system components, such as service failures or kernel issues, with cursor-based navigation for precise log positioning. For system monitoring, systemd-analyze examines boot performance, reporting aggregate times for kernel, initrd, and userspace phases (e.g., via systemd-analyze time), unit-specific initialization delays (systemd-analyze blame), and dependency chains (systemd-analyze critical-chain). It generates SVG plots of timelines for visual analysis of service startups. Complementing this, systemd-cgtop offers real-time views of control group (cgroup) resource consumption, ranking by CPU (scaled to processor count, e.g., up to 800% on 8 cores), , or I/O, updating every second in a top-like interface. Accurate metrics require enabling MemoryAccounting= and IOAccounting= in unit files, facilitating identification of resource-intensive processes or slices. These tools leverage systemd's cgroup integration for granular oversight without external dependencies.

Configuration and Customization

Unit File Syntax and Directives

Unit files employ an INI-style syntax, consisting of sections denoted by headers in square brackets, such as [Unit], followed by directives in the form Key=Value. Whitespace surrounding the equals sign is ignored, and lines may be concatenated using a backslash at the end, which is replaced by a space in the resulting value. Comments begin with a semicolon or hash mark and are ignored, while empty lines serve for readability and are disregarded during parsing. Boolean values accept strings like yes, true, on, 1 for affirmative and no, false, off, 0 for negative; other values may lead to errors depending on the directive. Values can be quoted with single or double quotes to include spaces or special characters, supporting C-style escapes such as \n for newlines. Line length is capped at 1 MB to prevent parsing issues. Unit files reside in hierarchical directories including /etc/systemd/system/ for local overrides, /run/systemd/system/ for runtime configurations, and /usr/lib/systemd/system/ (or /lib/systemd/system/) for vendor-supplied defaults, with earlier paths taking precedence over later ones. Filenames follow the pattern unit-name.extension, where the extension indicates the unit type (e.g., .service, .socket), limited to 255 characters; template units use @ for instantiation, as in [email protected]. Sections include the universal [Unit] for general properties and dependencies, [Install] for enabling behavior, and type-specific sections like [Service] for service units. Directives in [Unit] are evaluated at runtime, while those in [Install] apply during systemctl enable. Drop-in overrides in subdirectories like unit-name.d/*.conf allow partial modifications without altering originals, processed in lexicographic order. The [Unit] section defines core attributes and inter-unit relationships. Key directives include:
DirectiveDescription
Description=Provides a short, human-readable summary of the unit's purpose.
Documentation=Lists URIs (e.g., man:, http://) for further references, space-separated.
Requires=Establishes a strong dependency, requiring listed units to start successfully before this one; failure propagates.
Wants=Imposes a weak dependency, attempting to start listed units but continuing on failure.
After= / Before=Specifies ordering: this unit starts after (or before) listed units during activation, and reverses for deactivation.
Conflicts=Prevents concurrent activation with listed units, triggering stops if violated.
An example [Unit] section might appear as:

[Unit] Description=Example Service Documentation=man:example(1) Requires=network.target After=network.target Wants=example-data.service

[Unit] Description=Example Service Documentation=man:example(1) Requires=network.target After=network.target Wants=example-data.service

The [Install] section governs installation via symlinks created by systemctl enable. Notable directives are:
DirectiveDescription
WantedBy=On enable, generates symlinks in the .wants/ subdirectory of specified targets (e.g., multi-user.target.wants/).
RequiredBy=Similar to WantedBy but uses .requires/, enforcing strong dependencies.
Alias=Defines additional names as symlinks upon enabling, allowing activation under aliases.
For instance:

[Install] WantedBy=multi-user.target Alias=example-alias.service

[Install] WantedBy=multi-user.target Alias=example-alias.service

Directives support specifiers like %i for template instances or %H for , enabling dynamic configuration. Multiple assignments to the same key may append to lists or override prior values, per directive semantics.

Runtime Management Commands

The primary interface for runtime management in systemd is the systemctl command, which enables administrators to introspect the current state of units and control their activation, deactivation, and reloading without requiring a system reboot. This tool operates by issuing D-Bus method calls to the systemd manager process (PID 1), allowing precise manipulation of services, sockets, targets, and other unit types during system operation. Unlike legacy init systems, systemctl supports parallel operations and dependency resolution, reducing administrative overhead for dynamic environments. Key subcommands for unit control include:
  • start: Immediately activates a unit and its dependencies, transitioning it to an active state if possible; for example, systemctl start [nginx](/page/Nginx).service launches the specified service.
  • stop: Deactivates a unit, stopping its processes and reversing dependencies; this command waits for clean shutdown unless --force is specified.
  • restart: Equivalent to stopping followed by starting a unit, useful for applying configuration changes without manual sequencing.
  • reload: Requests a unit to reload its configuration without interrupting running processes, applicable to units supporting reload signals like daemons with handling.
  • status: Displays detailed runtime information for a unit, including PID, resource consumption, and recent log excerpts from the journal.
For system , list-units enumerates all loaded units with their states (active, inactive, failed), while show retrieves all properties of a specific unit in key-value format, facilitating scripting and . The daemon-reload command rescans unit files after modifications, reloading configuration into the manager without affecting running units, ensuring consistency during live updates. Transient units can be managed via systemd-run, which spawns ephemeral services or scopes for one-off tasks, assigning them properties like CPU limits or priorities at invocation; for instance, systemd-run --scope -p CPUQuota=50% command executes with resource constraints. This complements systemctl by enabling ad-hoc runtime isolation without persistent unit files. Control group monitoring is available through systemd-cgtop, which provides a top-like view of sorted by resource usage (CPU, memory, I/O), aiding in identifying resource-intensive units.

Adoption and Integration

Distribution-Level Implementation

Linux distributions implement systemd by packaging its components—typically as a core set of binaries, libraries, and tools—into their repositories, configuring the bootloader (e.g., GRUB) to invoke /lib/systemd/systemd as process ID 1 via kernel parameters like init=/lib/systemd/systemd if necessary, and generating initramfs images with systemd support using tools such as dracut (in Red Hat derivatives) or mkinitcpio (in Arch Linux). Service management transitions involve converting legacy SysV init scripts to native unit files or using compatibility generators like sysv-generator, with distribution-specific units placed in /usr/lib/systemd/system/ or /lib/systemd/system/ and overrides in /etc/systemd/system/. Presets in /usr/lib/systemd/system-preset/ dictate default service enablement, often customized per distro to enable essential services like networking while disabling others. Distributions contribute variably to upstream development; for instance, employees, including systemd's creators and Kay Sievers, drive features aligned with enterprise needs, such as robust resource control in RHEL. Packaging differences arise from formats—RPM for /RHEL/, DEB for /—and integrations, like Ubuntu's compatibility with or Arch's emphasis on minimalism with user-managed units. Backports and patches address stability or feature gaps, while tools like systemd-analyze aid boot optimization tailored to hardware or use cases.
DistributionFirst Version with Default systemdRelease DateKey Implementation Details
Fedora15May 24, 2011Early pioneer; integrates with dracut for initramfs and SELinux for security; upstream contributions heavy due to involvement.
openSUSE12.1November 4, 2011Replaces SysV init; uses zypper for package management and YaST for configuration; supports transactional updates in later variants.
Arch LinuxCore transition in late 2012Rolling releaseMinimal base install; mkinitcpio hooks enable systemd; user extensibility via and AUR for custom units.
RHEL7June 10, 2014Enterprise focus with SysV compatibility; and units standard; long-term support backports.
Debian8 (Jessie)April 26, 2015Post-vote adoption; supports multi-init via alternatives; integrates with policykit and elogind for session management.
Ubuntu15.04 (Vivid Vervet)April 23, 2015Full shift from Upstart; cloud-init and snapd units prominent; apport for crash reporting leverages journald.
These implementations standardize boot parallelism and dependency resolution across distros while allowing vendor-specific extensions, such as Fedora's atomic desktops using systemd for orchestration or Debian's emphasis on compliance in unit dependencies.

Compatibility with Existing Software

Systemd maintains backward compatibility with System V (SysV) init scripts through the sysv-generator utility, which scans /etc/init.d/ directories at and generates transient .service unit files from compatible scripts, enabling their management under systemd without immediate rewriting. This process respects LSB () headers for dependency resolution and mapping, allowing parallel service startup while honoring explicit sequencing directives from legacy scripts. Socket activation serves as a compatibility bridge for traditional Unix daemons designed for or xinetd, where systemd listens on specified sockets and passes file descriptors to activated processes, supporting unmodified inetd-style services with improved on-demand efficiency. Similarly, activation integrates with daemons expecting bus-launched invocation, facilitating coexistence with software reliant on traditional patterns. Legacy tools interacting with init systems receive support via emulated interfaces, such as a FIFO-backed /dev/initctl for SysV-compatible signaling and preservation of /wtmp logging formats for utilities querying user sessions. mounting from /etc/[fstab](/page/Fstab) is parsed directly, with options for systemd-managed automounters to replace legacy scripts handling . Despite these layers, compatibility has limitations: SysV scripts with non-standard actions (e.g., custom subcommands beyond start/stop/restart) lack direct equivalents and necessitate external wrappers or native unit rewrites. Some software assuming flat process trees or SysV-specific signal handling may fail under systemd's cgroup-based resource isolation, requiring adjustments for tracking via /proc. Distributions like sustain legacy initscript packages explicitly for phased transitions of vendor-provided services, underscoring that while operational for most cases, full seamlessness often demands eventual native adaptation.

Reception and Impact

Achievements and Empirical Benefits

Systemd's parallel service activation, which starts independent units concurrently based on dependency graphs rather than sequentially as in , has empirically reduced boot times in many configurations. This approach leverages modern multicore processors to overlap initialization tasks, enabling systems to reach operational readiness faster; for instance, distributions like reported boot time reductions upon initial adoption in 2011. Integration with Linux control groups (cgroups) provides systemd with hierarchical process organization, allowing precise resource allocation, limiting, and monitoring at the rather than individual processes. This facilitates better isolation and in resource-constrained or multi-service environments, such as servers hosting multiple applications, by preventing any single unit from monopolizing CPU, memory, or I/O. On-demand activation mechanisms, including socket and activation, defer service startup until actual demand, minimizing idle resource consumption and improving overall system responsiveness. These features contribute to lower baseline overhead, particularly beneficial for embedded or virtualized deployments where prompt scaling is critical. Widespread adoption across major distributions—including (default since version 15 in April 2011), (since 15.04 in April 2015), and (since version 8 in April 2015)—reflects systemd's role in standardizing service management, which has streamlined development and maintenance efforts for maintainers and upstream projects. This convergence has enabled consistent handling of modern features like container orchestration and hardware hotplugging, enhancing in enterprise and cloud ecosystems.

Criticisms and Technical Shortcomings

Critics of systemd have highlighted its architectural complexity as a key technical shortcoming, contending that the system's integration of numerous functionalities into a single framework—encompassing , , device management, and more—creates opacity and hinders troubleshooting compared to modular alternatives like SysV . This design, while aiming for efficiency, has been argued to amplify dependency issues and race conditions, as evidenced by reports of opaque modes where pinpointing root causes requires deep dives into proprietary tools rather than standard Unix utilities. A prominent concern involves systemd's consolidation of critical roles under PID 1, positioning it as a potential ; if the process encounters errors, it can precipitate system-wide , diverging from the of small, composable tools. Empirical instances include sporadic crashes in systemd-journal-upload, which have been documented to occur up to a dozen times daily in affected environments as of August 30, 2025, often tied to data handling failures during remote uploads. Similarly, systemd-timesyncd has exhibited startup failures following kernel updates, such as those in on October 2, 2024, necessitating package downgrades for resolution. Binary logging via journald has drawn criticism for reducing and ease of analysis, as logs are stored in an indexed binary format inaccessible to generic text processors like or without conversion tools, complicating forensic review and archival across diverse systems. This format, while optimized for querying, has been faulted for , as it favors systemd-specific utilities over portable standards. Additional reliability lapses include deviations from norms, such as systemd's 2016 behavior of abruptly terminating user processes on logout rather than issuing signals, which disrupted session persistence and required upstream adjustments. Scope creep has exacerbated vulnerabilities by expanding systemd's footprint to include (systemd-networkd) and resolved DNS handling, increasing the ; for instance, systemd-resolved has faced persistent bug reports for DNS resolution failures and leaks, contributing to boot delays or connectivity issues in distributions like as of December 2023. While proponents note that such components address gaps in legacy systems, detractors argue this violates principles, leading to forced API dependencies and integration hurdles for non-systemd software. Bugzilla entries, such as those tracking crashes in RHEL 8.4 environments persisting into 2023, underscore ongoing stability challenges in enterprise deployments. Additionally, user reports of system freezes or hangs during suspend operations have sometimes been attributed to systemd, but these are most frequently linked to hardware/driver incompatibilities (such as proprietary NVIDIA drivers, faulty kernel modules, USB devices, or firmware bugs) rather than defects in systemd's inhibition logic or core design. systemd-logind's inhibition mechanism blocks suspend-to-RAM (referred to as "sleep") only if an active inhibitor specifies "sleep" in the "What" field as shown by systemd-inhibit --list; if "sleep" is absent, suspend proceeds normally and is not inhibited.

Philosophical Debates and Ideological Resistance

Critics of systemd argue that it fundamentally departs from the , which emphasizes where programs perform a single task well and interface through simple, text-based protocols. Instead, systemd integrates diverse functionalities—including process management, logging via journald, device handling, and network configuration—into a cohesive suite, leading to accusations of monolithic bloat that complicates debugging and maintenance. This integration, proponents of traditional Unix principles contend, sacrifices the composability of small, independent tools in favor of centralized control, potentially increasing systemic fragility as failures in one component propagate more readily. Systemd's lead developer, , has countered that the , while historically valuable, presumes the perfection of tools developed decades ago and resists adaptation to contemporary computing demands like parallelization and resource containment via . He posits that rigid adherence to modularity ignores real-world complexities, such as the need for tight coordination between processes and modern hardware, rendering isolated tools insufficient for efficient system initialization observed in empirical boot time reductions post-adoption. Defenders further assert that Unix principles apply more aptly to user-space utilities than to core system infrastructure, where integration enhances reliability without violating underlying open-source ethos. Ideologically, resistance stems from a broader commitment to minimalist, decentralized systems engineering, exemplified by groups like , which decry systemd as a "menace" eroding Unix's emphasis on clarity and user sovereignty through opaque binaries and proprietary-like . This view frames systemd's rise—accelerated by corporate backing from since its 2010 inception—as emblematic of centralized power concentration in few maintainers, contrasting with the distributed, volunteer-driven evolution of prior init systems like SysV init. Such opposition has manifested in forks like , launched in 2014 to preserve init freedom, reflecting a purist stance prioritizing philosophical purity over pragmatic gains in performance metrics. Poettering attributes much backlash to cultural inertia rather than substantive flaws, noting that early criticisms often overlooked systemd's GPL licensing and verifiable improvements in areas like dependency resolution.

Alternatives and Forks

Partial Forks of Components

eudev emerged as a fork of systemd's udev component following the 2012 integration of into the systemd project, aiming to decouple device management from systemd's init system dependencies. The project, hosted on , isolates udev's core functionality—managing device nodes in /dev and handling kernel events for hotplugging—while removing build-time ties to systemd, enabling compatibility with alternative init systems like or sysvinit. As of 2023, eudev remains in use by distributions such as , , and , though it has faced deprecation in others like Gentoo due to maintenance challenges in syncing with upstream systemd changes. Recent efforts by systemd maintainers to alter libudev compatibility have prompted concerns among eudev users, potentially requiring further divergence or patches to preserve functionality. elogind represents another prominent partial fork, extracting systemd's logind daemon to operate independently for session and management on non-systemd systems. Introduced around 2015, it integrates with PAM to track logged-in users, manage multi-user sessions, and handle power events like suspend, providing features essential for desktop environments such as without requiring systemd's full suite. Maintained in parallel with upstream logind, elogind is employed by distributions including , antiX, and Gentoo (alongside alternatives like ConsoleKit2), allowing modular adoption where full systemd is avoided but logind's cgroup-based process organization and interfaces are desired. Unlike complete alternatives, elogind retains systemd's design paradigms, such as private for users, which has drawn criticism for indirectly propagating systemd dependencies into init-agnostic setups. These forks illustrate a strategy of selective extraction to leverage systemd's specialized components—device handling via eudev and session tracking via elogind—while mitigating broader concerns over systemd's monolithic scope, though long-term viability hinges on community efforts to track upstream evolution without runtime entanglements. Limited to these core utilities, partial forks have not extended significantly to other systemd elements like timedated or networkd, reflecting prioritization of broadly applicable features over comprehensive replication.

Complete Alternative Init Systems

OpenRC is a dependency-based init system originating from the project, developed by Roy Marples starting around 2007 as an evolution of SysV scripts. It manages services through portable shell scripts in /etc/init.d/, supports parallel execution via dependency graphs, and maintains with traditional runlevels while allowing custom init binaries since version 0.25 in 2017. is the default init in distributions including , (since 2009), and Artix Linux's OpenRC edition, where it handles boot processes, service supervision, and resource limits without systemd's socket activation or cgroups integration. Its design emphasizes script portability across systems, with reported boot times under 5 seconds on minimal installations as of 2023 benchmarks. Runit serves as a , supervision-focused scheme, authored by Gerrit Pape and initially released in 2001 as a daemontools-inspired replacement for SysV . It operates via directory-based service definitions—each containing run scripts for execution and supervision trees for process monitoring—replacing PID 1 with runit-init for cross-platform booting on , BSD, and others. is the standard in (adopted in 2010) and supports hybrid usage atop other inits for daemon management, prioritizing fault tolerance through automatic restarts and minimal resource use (typically under 1 MB RAM idle). Usage involves tools like runsv for per-service supervision and sv for control, enabling configurations without declarative files, as seen in derivatives and embedded systems where boot durations average 3-7 seconds on x86 hardware per 2024 reports. The s6 ecosystem, developed by Laurent Bercot from 2012 onward under skarnet.org, comprises modular components like s6 for , s6-rc for service dependency resolution, and s6-linux-init for PID 1 duties, forming a complete non-systemd stack. It enforces strict , readiness notifications, and failure recovery via scan directories and atomic state files, avoiding systemd's unit-file complexity in favor of Unix-tool chaining. S6 is employed in Adélie Linux and select Artix or Void variants, with s6-66 extensions for enhanced logging; benchmarks from indicate sub-4-second boots on lightweight setups due to its non-parallel but efficient sequential-with-deps model. Its emphasis on hygiene—treating init as a mere starter for independent supervisors—yields high reliability in long-running servers, though it requires manual assembly for full boot handling. Traditional SysV init, standardized in Release 3 around 1987, persists as a baseline alternative using sequential /etc/init.d/ scripts triggered by runlevels (0-6) and lacks inherent dependencies or parallelism, relying on external tools like update-rc.d for management. It underpins legacy modes in (forked from in 2014 to avoid systemd) and embedded environments, with boot times often exceeding 10 seconds on modern hardware due to linear execution, but offering unmatched simplicity and auditability via . These systems collectively enable systemd-free distributions, trading integrated features for reduced complexity and , as evidenced by ongoing maintenance in 2025 across niche but stable ecosystems.

Current Viability and Ecosystem Role

As of October 2025, systemd maintains dominant viability as the init system and service manager for the majority of distributions, powering desktops, servers, and embedded systems in production environments worldwide. Its adoption stems from empirical advantages in boot performance, parallel service startup, and via integration with v2, which enable efficient container orchestration and dependency resolution not matched by legacy SysV init or alternatives like . Major distributions, including (holding approximately 33.9% of the Linux desktop market share), , , , and Red Hat Enterprise Linux derivatives, default to systemd, reflecting its role as the that underpins over 90% of general-purpose deployments based on distro popularity metrics. Systemd's ongoing evolution underscores its technical robustness, with version 258 released on September 17, 2025, incorporating enhancements like systemd-factory-reset for automated system restoration and improved kernel baseline support up to Linux 5.7, ensuring compatibility with contemporary hardware and security requirements. In server contexts, systemd's unit file-based configuration and tools like systemctl provide granular control over service states, logging via journald, and socket activation, reducing administrative overhead compared to script-based init systems; benchmarks show faster cold boots and lower latency in service failures on systemd-enabled systems versus non-systemd equivalents. This has solidified its ecosystem role, as upstream projects like GNOME, KDE, and container runtimes (e.g., Podman) increasingly rely on systemd's APIs for seamless integration, creating a feedback loop where deviation incurs compatibility costs. Alternatives remain marginal, with partial implementations like or s6 confined to lightweight or anti-systemd forks such as (a variant) and , which collectively represent under 5% of active installations per community surveys and distro rankings. No comprehensive rival has achieved comparable feature parity in areas like native systemd-timesyncd for NTP or tmpfiles.d for ephemeral filesystem management, limiting their viability for enterprise-scale or multi-user environments. Systemd's entrenchment thus fosters a unified , though it demands adherence to its parallelized architecture, which prioritizes causal efficiency in service orchestration over modular purism.

References

  1. https://systemd.io/
  2. https://www.freedesktop.org/wiki/Software/systemd/
  3. https://docs.rockylinux.org/10/ko/books/admin_guide/16-about-sytemd/
  4. https://documentation.suse.com/smart/systems-management/html/systemd-basics/index.html
  5. https://www.pcworld.com/article/436149/meet-systemd-the-controversial-project-taking-over-a-linux-distro-near-you.html
  6. https://lwn.net/Articles/1008721/
  7. https://0pointer.de/blog/projects/the-biggest-myths.html
  8. https://0pointer.de/blog/projects/systemd.html
  9. https://unix.stackexchange.com/questions/278564/cron-vs-systemd-timers
  10. https://fedoraproject.org/wiki/Features/systemd
  11. https://arstechnica.com/information-technology/2011/05/first-look-fedora-15-arrives-with-gnome-30-and-systemd/
  12. https://linux-audit.com/systemd/faq/what-is-systemd/
  13. https://betterprogramming.pub/why-most-linux-users-hate-systemd-c591eef3d034
  14. https://wiki.debian.org/systemd
  15. https://www.debian.org/doc/manuals/project-history/detailed.en.html
  16. https://www.linux-magazine.com/Online/News/Ubuntu-Switches-to-systemd
  17. https://www.zdnet.com/article/after-linux-civil-war-ubuntu-to-adopt-systemd/
  18. https://docs.rockylinux.org/10/de/books/admin_guide/16-about-sytemd/
  19. https://blog.packagecloud.io/linux-distributions-and-the-timelines-of-their-systems/
  20. https://lwn.net/Articles/1001657/
  21. https://www.phoronix.com/news/systemd-258
  22. https://github.com/systemd/systemd/releases/tag/v258
  23. https://github.com/systemd/systemd/releases
  24. https://0pointer.de/blog/projects/why.html
  25. https://www.freedesktop.org/software/systemd/man/systemd.html
  26. https://systemd.io/ARCHITECTURE/
  27. https://www.freedesktop.org/software/systemd/man/systemd-inhibit.html
  28. https://www.freedesktop.org/software/systemd/man/systemd-logind.service.html
  29. https://www.freedesktop.org/software/systemd/man/systemd-suspend.service.html
  30. https://man7.org/linux/man-pages/man3/libsystemd.3.html
  31. https://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html
  32. https://www.freedesktop.org/software/systemd/man/sd-bus.html
  33. https://manpages.debian.org/experimental/libsystemd-dev/sd-bus.3.en.html
  34. https://www.freedesktop.org/software/systemd/man/systemd-analyze.html
  35. https://www.loggly.com/ultimate-guide/using-journalctl/
  36. https://notes.kodekloud.com/docs/Learning-Linux-Basics-Course-Labs/Service-management-with-SYSTEMD/SYSTEMD-Tools
  37. https://www.freedesktop.org/software/systemd/man/systemd.unit.html
  38. https://man7.org/linux/man-pages/man1/systemd.1.html
  39. https://www.freedesktop.org/software/systemd/man/systemd.service.html
  40. https://www.freedesktop.org/software/systemd/man/systemctl.html
  41. https://www.freedesktop.org/software/systemd/man/loginctl.html
  42. https://www.freedesktop.org/software/systemd/man/pam_systemd.html
  43. https://www.freedesktop.org/software/systemd/man/sd_bus.html
  44. https://blog.tjll.net/the-systemd-revolution-has-been-a-success/
  45. https://www.freedesktop.org/software/systemd/man/systemd.special.html
  46. https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html
  47. https://systemd.io/CONTROL_GROUP_INTERFACE/
  48. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/managing_monitoring_and_updating_the_kernel/assembly_configuring-resource-management-using-systemd_managing-monitoring-and-updating-the-kernel
  49. https://www.freedesktop.org/software/systemd/man/latest/systemd-journald.service.html
  50. https://www.freedesktop.org/software/systemd/man/latest/journalctl.html
  51. https://www.freedesktop.org/software/systemd/man/latest/systemd-analyze.html
  52. https://www.freedesktop.org/software/systemd/man/latest/systemd-cgtop.html
  53. https://www.freedesktop.org/software/systemd/man/systemd.syntax.html
  54. https://www.freedesktop.org/software/systemd/man/systemd-run.html
  55. https://www.freedesktop.org/software/systemd/man/systemd-cgtop.html
  56. https://access.redhat.com/articles/754933
  57. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/system_administrators_guide/chap-managing_services_with_systemd
  58. https://www.redhat.com/en/about/press-releases/fedora-15-advances-open-source-computing-and-innovation-with-powerful-features
  59. https://linuxdevices.org/fedora-15-takes-wing-with-gnome-3-and-systemd/index.html
  60. https://events.opensuse.org/conferences/oSC16/program/proposals/930
  61. https://bbs.archlinux.org/viewtopic.php?id=147272
  62. https://linuxiac.com/archlinux/
  63. https://wiki.debian.org/Init
  64. http://www.linux-magazine.com/Online/News/Ubuntu-Switches-to-systemd
  65. https://blog.packagecloud.io/ubuntu-a-journey-from-system-v-to-system-d/
  66. https://docs.rockylinux.org/8/books/admin_guide/16-about-sytemd/
  67. https://unix.stackexchange.com/questions/233468/how-does-systemd-use-etc-init-d-scripts
  68. https://fedoramagazine.org/systemd-converting-sysvinit-scripts/
  69. https://superuser.com/questions/1408123/translating-sysv-init-script-to-systemd
  70. https://www.turnkeylinux.org/blog/debugging-systemd-sysv-init-compat
  71. https://access.redhat.com/solutions/7030065
  72. https://cycle.io/learn/init-vs-systemd
  73. https://lwn.net/Articles/440636/
  74. https://opensource.com/article/20/10/cgroups
  75. https://unixdigest.com/articles/the-real-motivation-behind-systemd.html
  76. https://www.quora.com/What-are-the-criticisms-of-systemd-Why-was-it-created-if-earlier-versions-were-working-well-for-so-long
  77. https://itsfoss.com/systemd-init/
  78. https://github.com/systemd/systemd/issues/38775
  79. https://bbs.archlinux.org/viewtopic.php?id=299903
  80. https://news.ycombinator.com/item?id=19023232
  81. https://www.reddit.com/r/linux/comments/18kh1r5/im_shocked_that_almost_no_one_is_talking_about/
  82. https://suckless.org/sucks/systemd/
  83. https://bugzilla.redhat.com/show_bug.cgi?id=2084053
  84. https://lwn.net/Articles/440843/
  85. https://fossforce.com/2020/02/the-verdict-on-systemd-is-in/
  86. https://dev1galaxy.org/viewtopic.php?id=1637
  87. https://lobste.rs/s/0zxtur/lennart_poettering_on_systemd_s
  88. https://bashelton.com/2020/10/i-hate-systemd-and-other-ill-conceived-diatribes/
  89. https://www.reddit.com/r/linux/comments/5qh8nj/lennart_poettering_on_systemds_tumultuous/
  90. https://lwn.net/Articles/529314/
  91. https://github.com/eudev-project/eudev
  92. https://wiki.alpinelinux.org/wiki/Eudev
  93. https://sysdfree.wordpress.com/2023/07/08/372/
  94. https://www.linuxfromscratch.org/blfs/view/stable/general/elogind.html
  95. https://www.reddit.com/r/linux/comments/33cm4x/elogind_the_systemd_projects_logind_extracted_to/
  96. https://wiki.gentoo.org/wiki/Elogind
  97. https://github.com/antiX-Linux/elogind-antix
  98. https://news.ycombinator.com/item?id=27175960
  99. https://forums.gentoo.org/viewtopic-t-1149459.html
  100. https://wiki.artixlinux.org/Main/OpenRC
  101. http://www.linux-magazine.com/Online/Features/A-Survey-of-Init-Systems
  102. https://news.ycombinator.com/item?id=36495943
  103. https://smarden.org/runit/
  104. https://wiki.archlinux.org/title/Runit
  105. https://wiki.gentoo.org/wiki/Runit
  106. https://docs.slackware.com/howtos:slackware_admin:runit
  107. https://wiki.gentoo.org/wiki/Comparison_of_init_systems
  108. https://forums.gentoo.org/viewtopic-t-1105854.html
  109. https://forum.artixlinux.org/index.php/topic%2C3498.0.html
  110. https://dudemanguy.github.io/blog/posts/2019-12-19-s6-love/s6-love.html
  111. https://www.linuxjournal.com/content/embracing-future-transition-sysvinit-systemd-linux
  112. https://www.slant.co/options/12956/alternatives/~systemd-alternatives
  113. https://lwn.net/Articles/1028275/
  114. https://sqmagazine.co.uk/linux-statistics/
  115. https://softwarerecs.stackexchange.com/questions/36157/linux-distributions-which-do-not-default-to-using-systemd
Add your contribution
Related Hubs
User Avatar
No comments yet.