systemd

ByAodha21

systemd is a suite of system management daemons, libraries and utilities designed to unify service configuration and behavior across Linux platforms. It’s a system configuration and service management platform that Linux uses to bootstrap user space and manage user processes.

systemd is intended to replace the traditional sysVinit. It depends on a lot of Linux kernel features, so it will probably never be ported to other variants of UNIX, such as OS-X or BSD.

UEFI starts the kernel. The kernel starts systemd. systemd runs as PID 1 and starts the rest of the system user-space. It provides parallel processing capabilities, uses socket and D-Bus activation for starting services and starts daemons on-demand.

systemd manages entities called units, including:

  • service
  • socket
  • device
  • mount point
  • automount point
  • swap file or partition
  • startup target
  • watched filesystem path
  • timer
  • resource management slice
  • group of externally created processes

Source: Wikipedia

Services, Scopes, Slices, etc.

Services encapsulate a number of processes that are started and stopped by systemd, based on configuration. Services are named in the style of abc.service.

Scopes encapsulate a number of processes that are started and stopped by arbitrary processes via fork(), and then, registered at runtime with PID1. Scopes are named in the style of xyz.scope.

Slices may be used to group a number of services and scopes together into a hierarchical tree. Slices do not contain processes themselves, but the services and scopes contained in them do. Slices are named in the style of abc-xyz.slice, where the path to the location of the slice in the tree, is encoded in the name with “-” as a separator for the path components (abc-xyz.slice is a subslice of abc.slice).

There’s one special slice defined, -.slice, which is the root slice of all slices (abc.slice is a subslice of -.slice). This is similar to how, “/” denotes the root directory in regular file paths.

Understanding and Using systemd

  • systemd utilities
    • systemctl
    • journalctl
    • notify
    • analyze
    • cgls
    • cgtop
    • loginctl
    • nspawn
  • systemd daemons
    • systemd
    • journald
    • networkd
    • logind
    • user session
  • systemd targets
    • bootmode
    • basic
    • shutdown
    • reboot
    • multiuser
    • graphical
    • user-session
  • systemd core
    • manager
    • systemd
    • unit
    • login
    • namespace
    • log
    • cgroup
    • dbus
  • systemd libraries
    • dbus-1
    • libpam
    • libcap
    • libcryptsetup
    • tcpwrapper
    • libaudit
    • libnotify
  • linux kernel
    • cgroups
    • autofs
    • kdbus

Source: Carla Shroder @ Linux.com

systemctl

systemctl is the all-purpose command for managing systemd. List units with the systemctl list units and the systemctl list-units-files commands. List the status of Units with the systemctl status unitname` command.

$ systemctl status unit

returns

    bad : a problem within systemd, usually a bad unit file
disabled : present, not configured for autonomous start
enabled : installed and usable, will start autonomously
indirect : disabled, but it has peers in ALSO clauses that may be enabled
linked : unit file available through a symlink
masked : hidden from systemd
static : has no install requirements, depended on by another unit

    D-Bus

    D-Bus (Desktop Bus) is a message-oriented middleware mechanism that enables inter-process communication (IPC) between multiple processes running concurrently on the same machine. It provides a standardized way for applications to communicate with each other and the kernel, allowing them to exchange data and trigger actions.

    D-Bus operates on a virtual bus, which is a shared communication channel.

    There are two types of buses:

    • System bus: A single bus available to all users and processes on the system, providing access to system services.
    • Session bus: A bus for each user login session, providing desktop services to user applications.

    Namespaces: Each process connected to the bus is assigned a unique name, called a connection name, which starts with a colon (:) character. The name is used to identify the process and its services.

    Applications export objects, which provide interfaces to access specific functionality. These objects are identified by a path, similar to a file system path. Objects can implement multiple interfaces, which define the methods and signals they can send and receive. Interfaces define methods, which are functions that can be called by other processes to trigger actions or retrieve data.

    Interfaces can also define signals, which are notifications sent by an object to other processes when a specific event occurs. D-Bus sends messages between processes, containing the destination address (service name, object path, interface and method) and the data being transmitted. The bus daemon (dbus-daemon) manages the bus, assigning names, maintaining the bus topology and routing messages between processes.

    A D-Bus address consists of a service name, object path, interface and method. This address is used to route messages to the correct application, object and method.
    Bus name, interface and method are optional components of a D-Bus address. If not provided, the bus daemon will use default values or omit them.

    The bus daemon routes messages based on the address, ensuring that messages are delivered to the intended recipient. D-Bus provides a set of libraries and tools for developers to integrate D-Bus into their applications. These include:

    • libdbus: A C library for interacting with the D-Bus daemon.
    • dbus-python: A Python binding for libdbus.
    • busctl: A command-line tool for managing and inspecting the bus.

    Overall, D-Bus provides a standardized, platform-agnostic mechanism for inter-process communication, enabling applications to seamlessly interact with each other in a Linux desktop environment.

    Unit Files

    Each unit is defined and configured using a unit file. For example, a unit file may specify the location of an executable file for a service, tell systemd how to start and stop the service and identify any other units that the service depends on.

    Packages typically print their unit files into /usr/lib/systemd/system during installation. Do not modify these files. Local unit files go in /etc/systemd/system. Transient units are written into /run/systemd/system while programs are running. Unit files typically use file extensions like .service or .timer, which depend on the kind of unit it is.

    Files located in the /etc/systemd/system directory have the highest priority. It’s the best place to modify the way a unit functions. Unit files found in this directory take precedence over any of the other locations on the filesystem. It is the safest and most flexible place to modify your system’s copy of a unit file.

    Rather than editing a system unit file directly, you can add a subdirectory to the file, with unit file snippets in it, which appends or modifies the instructions of the system’s unit file, allowing you to specify only the changes. Do so by creating a directory named after the unit file with .d appended on the end.

    So, for a unit called example.service, mkdir a subdirectory called example.service.d. Override or extend the attributes of the system’s example.service unit file, by creating a file ending with .conf within example.service.d.

    Units are organized into sections indicated by the name of the section in square brackets, like this: [section]. Within these sections, unit behavior and metadata is defined through the use of simple directives using a key-value format with assignment indicated by an equal sign, like this:

    Instruction1=value
Instruction2=value

    [Unit] is usually the first section. It describes the unit. It defines metadata for the unit and configures its relationships with other units.

    The [Service] section provides configuration for services.

    The [Socket] section describes socket units, which are very common in systemd configurations. Many services implement socket-based activation for better parallelization and flexibility. Each socket unit must have a matching service unit, which will be activated when the socket receives activity.

    The [Mount] section describes mount units. Mount units enable systemd to manage mount points.

    The [Automount] section allows an associated .mount unit to be automatically mounted at boot. As with the .mount unit, these units must be named after the translated mount point’s path.

    The [Swap] section is used to configure swap space on the system. The units must be named after the swap file or the swap device.

    The [Path] section defines a filesystem path that systemd can monitor for changes. Another unit must exist that will be activated when certain activity is detected at the path location. Path activity is determined through inotify events.

    The [Timer] section is used to schedule tasks to operate at a specific time or after a certain delay. This unit type replaces or supplements some of the functionality of the cron and at daemons. An associated unit must be provided, which will be activated when the timer is reached.

    The [Slice] section of a unit file does not have any .slice unit specific configuration. It can contain resource management instructions that are available to some of the other units.

    [Install] is often the last section. It is only used for units that can be enabled to start during boot.

    Template Unit Files

    Template unit files can be used to create multiple instances of units. Template unit files are not much different than regular unit files. However, they provide flexibility in configuring units, by allowing certain parts of the file to utilize dynamic information that will be available at runtime.

    Template unit files can be recognized because they contain an @ symbol after the base unit name and before the unit type suffix, like this:

    example@.service

    When instances of units are created from a template, an instance identifier is placed between the @ symbol and the period, like this:

    example@instance1.service

    Instance files are usually created as a symbolic link to the template file, with the instance identifier included in the link name. This way, multiple links with unique identifiers can link to a single template file. systemd will look for a file with the exact instance name that you enter at your command line interface. If it does not find one, it will look for an associated template file.

    Targets are groups of units. Targets call units to put the system together. For instance, graphical.target calls all units necessary to start a workstation with a graphical user interface. Targets can build on top of one another or depend on other targets. At boot time, systemd activates the target default.target, which is an alias for another target such as graphical.target.

    Targets are used for grouping and ordering units. They are similar to runlevels in that they determine the order that different targets, different services, sockets and other units are started. Unlike runlevels, they are much more free-form and you can easily make your own targets for ordering units.

    Targets also have dependencies among themselves. For instance, most daemons are grouped under multi-user.target, which requires basic.target to be activated, which means that all services grouped under basic.target will be started before the ones in multi-user.target.

    Sources