systemd
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.
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 in 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 is a message bus system, a simple way for applications to talk to one another. D-Bus supplies a system daemon and a session daemon.
The system daemon is launched at the system startup level and is used mainly for hardware events. The session daemon is launched when a user logs in to a desktop environment. Desktop applications use the session daemon to connect to each other.
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. You should 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.