Systemd Concepts: Difference between revisions
| Line 13: | Line 13: | ||
<code>systemd</code> is run as the first process at boot (PID 1) and acts as the init system that brings up and maintains the userspace services. | <code>systemd</code> is run as the first process at boot (PID 1) and acts as the init system that brings up and maintains the userspace services. | ||
Unlike [[System V#init|System V init]], which starts services one at a time, moving to the next after running dependency checks and waiting on the daemon to start, < | Unlike [[System V#init|System V init]], which starts services one at a time, moving to the next after running dependency checks and waiting on the daemon to start, <code>systemd</code> can start services in parallel. It takes advantage of the daemon to daemon relationship in that dependent daemons do not actually need to be running, they only need the correct domain sockets to be available. <tt>systemd</tt> creates all sockets first, all the daemons second and any client requests to daemons not yet running are cached in the socket buffer and filled when the daemons come online. | ||
<tt>systemd</tt> interprets the configuration file <tt>system.conf</tt> and the files in <tt>system.conf.d</tt> directories. | <tt>systemd</tt> interprets the configuration file <tt>system.conf</tt> and the files in <tt>system.conf.d</tt> directories. | ||
Revision as of 21:03, 19 August 2023
External
- man systemd.service
Internal
Overview
systemd is a init system, a system and user space service manager for the Linux operating system. The purpose of an init system is to manage (initialize, start, stop) components in the user space - programs that run after the kernel has booted. Some of those components are services and daemons for the server.
systemd is run as the first process at boot (PID 1) and acts as the init system that brings up and maintains the userspace services.
Unlike System V init, which starts services one at a time, moving to the next after running dependency checks and waiting on the daemon to start, systemd can start services in parallel. It takes advantage of the daemon to daemon relationship in that dependent daemons do not actually need to be running, they only need the correct domain sockets to be available. systemd creates all sockets first, all the daemons second and any client requests to daemons not yet running are cached in the socket buffer and filled when the daemons come online.
systemd interprets the configuration file system.conf and the files in system.conf.d directories.
Differences between System V and systemd
systemctl
systemctl is the central management tool for systemd. More operational details:
Units
The resources managed by systemd are known as units. systemd provides a dependency system between units.
Units represent different types of resources. The units are defined in files known as unit files. The unit type is given the suffix of the corresponding unit file. There are 12 types of resources:
.service: A service unit describes how to manage a service or an application. This including starting and stopping the service, under which circumstance it should be automatically started and its dependencies..socket: A socket unit describes a network or IPC socket, or a FIFO buffer systemd uses for socket-based activation..device: A device unit describes a device that needs systemd management..mount: A mount unit defines a systemd-managed mountpoint..automount: Units that configure a mountpoint to be automatically mounted..swap: Units that describe the swap space on the system..target: A unit that provides a synchronization point for other units when booting up or changing state..path: Units defining paths that can be used for path-based activation..timer: A timer unit defines a timer managed by systemd, similar to a cron job for delayed or scheduled activation..snapshot.slice.scope
Unit Files
The type of each unit can be inferred from the suffix at the end of the file, as described in the Units section.
Unit File Location
The package maintainer unit files reside in /usr/lib/systemd/system (or /lib/systemd/system, as /lib is a symbolic link to /usr/lib).
The user-created unit files conventionally reside in /etc/systemd/system.
If a user wants to modify one of the default unit files, they should copy them in /etc/systemd/system, because systemd will give priority to /etc.
For more details see
man systemd-user.conf
Unit File Structure
A typical unit file is similar to:
[Unit]
Description=My Service
After=network.target
[Service]
Type=forking
ExecStart=/usr/local/bin/myserviced
PIDFile=/var/run/myservice.pid
[Install]
WantedBy=multi-user.target[Unit] Section
The [Unit] section contains a description of the service and its dependency declarations. In the example above, we declare that systemd must not attempt to start the service until the network is not running on the host. For more details on dependencies, see the Dependencies section, below. For more practical details on how to declare dependencies, see systemd Declaring a Service Dependency.
[Service] Section
Type= can be set to one of "simple", "forking", "oneshot", "dbus", "notify" or "idle"
Type=forking
ExecStart= represents the path to the binary to execute when the service is started. The binary is expected to fork.
If set to "forking", it is expected that the process configured with ExecStart= will call fork() as part of its start-up. The parent process is expected to exit when start-up is complete and all communication channels are set up. The child continues to run as the main daemon process. This is the behavior of traditional UNIX daemons. If this setting is used, it is recommended to also use the PIDFile= option, so that systemd can identify the main process of the daemon. systemd will proceed with starting follow-up units as soon as the parent process exits.
PIDFile= takes an absolute file name pointing to the PID file of the service's daemon. PIDFile=is recommended for services where Type= is set to forking. systemd will read the PID of the main process of the daemon after start-up of the service. systemd will not write to the file configured here, although it will remove the file after the service has shut down if it still exists. systemd uses this file to identify the main process of the daemon, but the file will need to be written by other means.
Type=oneshot
If the Type is set to "oneshot", it is expected that the process configured with ExecStart= is the main process of the service and will exit before systemd starts follow-up units. However, if RemainAfterExit= is configured with "true", systemd will consider the service active even after the "ExecStart=" process had exited. You may want to specify the pair "ExecStop=" wrapper so systemd knows how to cleanly shut down the process. This is a typical pattern for a Java server started by a wrapper script.
Typical "oneshot" Service section:
... [Service] Type=oneshot ExecStart=/usr/lib/systemd/scripts/activemq start ExecStop=/usr/lib/systemd/scripts/activemq stop RemainAfterExit=true ...
Environment=
Environment variables can be declared with Environment="variable_name=variable_value" as follows:
[Service] ... Environment="JAVA_HOME=/opt/java"
[Install] Section
WantedBy=multi-user.target means that the service should be started while in multi-user mode (equivalent with System V run level 3).
Environment
Query the Units Known to systemd
To list all units known to systemd, use:
systemctl list-units
The command will list the units and their state.
To query units matching a certain pattern, use:
systemctl list-units PATTERN
Services
For service management tasks, the target unit is a service unit, and their unit file have a .service suffix.
Start (Enable) a Service Automatically at Boot
To configure a service to start automatically at boot it must be enabled:
systemctl enable <application>.service
This command creates a symbolic link from the service unit file, which is usually maintained in /lib/systemd/system into a location on disk where systemd looks for autostart files. This is usually a /etc/systemd/system/<some-target>.target.wants directory. See Target.
Example:
[root@openshift-master1 system]# systemctl enable docker ln -s '/usr/lib/systemd/system/docker.service' '/etc/systemd/system/multi-user.target.wants/docker.service'
More:
Starting a Service
Starting a service means using systemctl to execute instructions in the service's unit file. It must be executed as root:
systemctl start <application>.service
The short form
systemctl start <application>
also works.
More:
Reload Configuration without a Restart
If the service supports reloading configuration without actually restarting the service, use:
systemctl reload <application>.service
Restart a Service
systemctl restart <application>.service
Reload or Restart a Service
If you are unsure whether the service has the configuration reload functionality, use reload-or-restart:
systemctl reload-or-restart <application>.service
Stop (Disable) a Service
systemctl disable <application>.service
Status of a Service
Status Report
To check the status of a service run:
systemctl status <application>.service
Active
A service can be active (running) or not active. To check whether a service is active (running), execute:
systemctl is-active <application>.service
This will return the current unit state as a string ("active" or "inactive"). The exit code will be "0" if it is active.
Enabled
A service can be configured to start at boot (enabled) or not enabled. To check whether a service is enabled, execute:
systemctl is-enabled <application>.service
This will return the current unit enabled state as a string ("enabled" or "disabled"). The exit code will be "0" if it is enabled.
Failed
systemctl can be used to check to see whether the service is in a failed state:
systemctl is-failed <application>.service
This will return "active" if it is running properly or "failed" if an error occurred. If the unit was intentionally stopped, it may return "unknown" or "inactive". An exit status of "0" indicates that a failure occurred and an exit status of "1" indicates any other status.
Service Unit File
Service unit files contain information about a process controlled and supervised by systemd. Service units installed by the system administrator are typically stored in /etc/systemd/system/ directory, but this may vary depending on the Linux distribution.
Loaded Unit
A unit is in a "loaded" state if the unit's configuration has been parsed by systemd. The configuration of loaded units is kept in memory.
Target
A unit configuration file whose name ends in " .target " encodes information about a target unit of systemd, which is used for grouping units and as well-known synchronization points during start-up.
Dependencies
See
After
TODO
Before
TODO
Wants
TODO
Requires
TODO
systemd and network status
journald
Timers
systemctl list-timers
Timer Unit File
Timer unit files contain information about a timer controlled and supervised by systemd. By default, a service with the same name as the timer is activated. Also see service unit file.
For an example, see: