systemd

systemd [OPTIONS...]
(Note: systemd is primarily the PID 1 daemon; direct user invocation is rare for system management.)

--system
    Tells systemd to run as the system-wide manager, which is its default role (PID 1).

--user
    Tells systemd to run as a user-specific manager, handling user sessions and services.

--test
    Runs systemd in a test mode, useful for debugging configuration files without affecting the running system.

--log-level=level
    Sets the maximum log level for messages written to the journal, e.g., info, debug, warning.

--log-target=target
    Sets the destination for log messages, e.g., console, journal, syslog.

--version
    Displays the version of systemd.

--help
    Shows a help message with available command-line options.

systemd is the foundational building block of many modern Linux distributions, acting as the primary init system and service manager. It is the first user-space process started during boot (PID 1) and is responsible for bringing up and maintaining the entire operating system. Its core responsibilities include initializing the system, managing system services, handling mount points, devices, and sockets, and shutting down the system gracefully. systemd employs a dependency-based boot process, allowing services to start in parallel, significantly speeding up boot times compared to older SysVinit or Upstart systems. It uses "unit" files (e.g., service, socket, device, mount, target, timer) to define and manage system resources, providing a consistent and declarative way to configure system behavior. While systemd itself is the daemon, users typically interact with it via the systemctl command to manage services, inspect status, and control the system state.

systemd is a comprehensive and deeply integrated system, which has led to some controversy. Its extensive scope, replacing functionalities previously handled by separate tools (e.g., networking, logging, DNS resolution), can make it complex to understand for newcomers. Troubleshooting often requires familiarity with its unit-based structure and specific tools like systemctl and journalctl. Its binary journal logging can also be a point of contention for those accustomed to plain text logs.

systemd manages system resources and services using configuration files called "unit files." These plain-text files describe various types of resources, such as service units (.service) for daemons, socket units (.socket) for socket-activated services, mount units (.mount) for filesystems, and target units (.target) for grouping other units and defining system states (e.g., `multi-user.target`, `graphical.target`). Unit files enable declarative and powerful dependency management.

systemd includes its own logging system, known as the systemd Journal. It collects log data from various sources—kernel, initrd, services, standard output/error—into a centralized, indexed, binary database. This allows for powerful querying and filtering of logs using the journalctl command, providing a more structured and efficient way to analyze system events compared to traditional plain-text log files.

Development of systemd began in 2010 by Lennart Poettering and Kay Sievers at Red Hat, aiming to provide a more modern, efficient, and integrated replacement for the traditional SysVinit system. It was designed to address limitations such as slow, sequential boot processes and lack of robust dependency management. systemd was first adopted by Fedora in 2011 and quickly gained traction, becoming the default init system for most major Linux distributions, including Arch Linux, openSUSE, Debian, and Ubuntu, by the mid-2010s. Its adoption sparked significant debate within the Linux community due to its design philosophy and broad scope.

systemctl(1), journalctl(1), bootctl(1), loginctl(1), hostnamectl(1), timedatectl(1), localectl(1), networkctl(1)