systemd

Jump to: navigation, search

systemd is the init system and service manager used by openSUSE.

The program systemd is the process with process ID 1. It is responsible for initializing the system in the required way. systemd is started directly by the kernel and resists signal 9, which normally terminates processes. All other programs are either started directly by systemd or by one of its child processes.

Systemd is a replacement for the System V init daemon. systemd is fully compatible with System V init (by supporting init scripts). One of the main advantages of systemd is that it considerably speeds up boot time by aggressively paralleling service starts. Furthermore, systemd only starts a service when it is really needed. Daemons are not started unconditionally at boot time, but rather when being required for the first time. systemd also supports Kernel Control Groups (cgroups), snapshotting and restoring the system state and more. See http://www.freedesktop.org/wiki/Software/systemd/ for details.

see openSUSE:Systemd_tips and the openSUSE systemd documentation

Configuration

All systemd daemons including PID1 can have theirs default settings tuned. The way to configure these various daemons is similar and is described in the relevant man pages.

For example, for a detailed description of PID1 configuration, you can refer to systemd-system.conf(5) man page.

Main Configuration files

Each systemd daemon comes with a main configuration file.

The default configuration files, which reflect the settings established during compilation, are located in /usr/lib/systemd/.

Administrators can override them by creating their own versions in /etc/. However, this approach is not recommended because main configuration files always have lower precedence than drop-in files, regardless of whether these drop-ins were created by the administrator (in /etc/) or provided by a package (in /usr/).

Therefore, it is recommended to use drop-in configuration snippets in /etc/systemd/*.conf.d/ for customizing the configuration.

Drop-in snippets

Drop-ins are configuration snippets that have higher precedence over main configuration files. They are usually stored in /etc/systemd/*.conf.d/ for drop-ins created by sysadmins or installed in /usr/lib/systemd/*.conf.d/ by packages when downstream needs to customize specific parts of a configuration.

For example if a sysadmin wants to disable the rate limiting enforced by systemd-journald by default, he can run the following commands:

   $ mkdir /etc/systemd/journald.conf.d
   $ cat >/etc/systemd/journald.conf.d/60-rate-limit.conf<<EOF
   # Disable rate limiting
   RateLimitIntervalSec=0
   EOF
   $ systemctl restart systemd-journald

Getting a configuration overview

Since the configuration of a systemd component might be scattered into different places, it might be tricky to get a global overview.

Fortunately systemd-analyze cat-config can be used to inspect the configuration of one systemd component. For example to inspect the configuration files affecting systemd-journald, one can execute:

   $ systemd-analyze cat-config systemd/journald.conf

See systemd-analyze(1) man page for more examples.

Avoiding drop-in conflicts

To avoid conflict between drop-ins shipped by downstream and those created by users, it is recommended to prefix all filenames in those sub-directories with a two-digit number and a dash, e.g. 60-rate-limit.conf.

Moreover by using a prefix number >= 60, users are guaranteed that theirs drop-in snippets won't be overridden by those shipped by downstream. Or to say this differently: the available user range is [60-90] while the range [0-49] is reserved for package drop-ins.

Please note that the same reasoning also applies when overriding (part of) unit files. Only the names of drop-ins subdirectories differ in this case, please consult systemd.unit(5) man page. Also for units, systemctl cat should be used instead of systemd-analyze cat-config.