knowledge/technology/linux/systemd/Systemd.md

website	arch-wiki	wiki	repo	obj
https://systemd.io	https://wiki.archlinux.org/title/systemd	https://en.wikipedia.org/wiki/Systemd	https://github.com/systemd/systemd	application

Systemd

systemd is a suite of basic building blocks for a Linux system. It provides a system and service manager that runs as PID 1 and starts the rest of the system. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, maintains mount and automount points, and implements an elaborate transactional dependency-based service control logic. systemd supports SysV and LSB init scripts and works as a replacement for sysvinit. Other parts include a logging daemon, utilities to control basic system configuration like the hostname, date, locale, maintain a list of logged-in users and running containers and virtual machines, system accounts, runtime directories and settings, and daemons to manage simple network configuration, network time synchronization, log forwarding, and name resolution.

See also:

• Systemd-Timers
• systemd-boot
• systemd-cryptenroll

Using Units

Units commonly include, but are not limited to, services (.service), mount points (.mount), devices (.device) and sockets (.socket).

Show Status:

systemctl status
systemctl status unit

List running units:

systemctl list-units

List failed units:

systemctl --failed

Start unit:

systemctl start unit

Stop unit:

systemctl stop unit

Restart unit:

systemctl restart unit

Reload units:

systemctl daemon-reload

Enable/Disable (Start at boot) unit:

systemctl enable unit
systemctl disable unit

Mask (forbid running) unit:

systemctl mask unit
systemctl unmask unit

Power Management

Shut down and reboot the system
systemctl reboot

Shut down and power-off the system
systemctl poweroff

Suspend the system
systemctl suspend

Put the system into hibernation
systemctl hibernate

Put the system into hybrid-sleep state (or suspend-to-both)
systemctl hybrid-sleep

Unit Files

Stored in:

• /usr/lib/systemd/system/: units provided by installed packages
• /etc/systemd/system/: units installed by the system administrator
• ~/.config/systemd/user/: units used by local users

Service types

There are several different start-up types to consider when writing a custom service file. This is set with the Type= parameter in the [Service] section:

• Type=simple (default): systemd considers the service to be started up immediately. The process must not fork. Do not use this type if other services need to be ordered on this service, unless it is socket activated.
• Type=forking: systemd considers the service started up once the process forks and the parent has exited. For classic daemons use this type unless you know that it is not necessary. You should specify PIDFile= as well so systemd can keep track of the main process.
• Type=oneshot: this is useful for scripts that do a single job and then exit. You may want to set RemainAfterExit=yes as well so that systemd still considers the service as active after the process has exited.
• Type=notify: identical to Type=simple, but with the stipulation that the daemon will send a signal to systemd when it is ready. The reference implementation for this notification is provided by libsystemd-daemon.so.
• Type=dbus: the service is considered ready when the specified BusName appears on DBus's system bus.
• Type=idle: systemd will delay execution of the service binary until all jobs are dispatched. Other than that behavior is very similar to Type=simple.

Example

[Unit]
Description=Description
After=network.target

[Service]
User=user
Environment="ONE=one" 'TWO=two two'
ExecStart=/bin
WorkingDirectory=/
ExecReload=/bin/sh -c "kill -HUP $MAINPID"
KillSignal=SIGTERM
TimeoutStopSec=30s
SendSIGKILL=yes
LimitNOFILE=4096

[Install]
WantedBy=multi-user.target

The [Unit] section

The Unit sectoin contains details and description about the unit itself. In our case, it contains details about the service. Details like 'what is it's description', 'what are it's dependencies' and more.

Below are the fields the Unit section has:

• Description: Human-readable title of the systemd service.
• After: Set dependency on a service. For example, if you are configuring Apache web server, you want the server to start after the network is online. This typically includes targets or other services.
• Before: Start current service before specified service. This too, like After, includes targets or other services.

The [Service] section

The Service section contains details about the execution and termination of service.

Below are the fields the Service section can have:

• ExecStart: The command that needs to be executed when the service starts.
• ExecReload: This is an optional field. It specifies how a service is restarted. For services that perform disk I/O (especially writing to disk, like a database), it is best to gracefully kill them and start again. Use this field in case you wish to have a specific restart mechanism.
• Type: The process start-up type for this systemd service. Options are simple, exec, forking, oneshot, dbus, notify and idle.
• Restart: This is another optional field but one that you will very likely use. This specifies if a service should be restarted--depending on circumstances--or not. The available options are no, on-success, on-failure, on-abnormal, on-watchdog, on-abort and always.
• Environment: Environment Variables
• User: The user that should run the process
• WorkingDirectory: Working directory of the process

The [Install] section

The Install section, as the name says, handles the installation of a systemd service/unit file. This is used when you run either systemctl enable and systemctl disable command for enable/disable a service.

Below are the fields the Install section has:

• WantedBy: This is similar to the After and Before fields, but the main difference is that this is used to specify systemd-equivalent "runlevels". The default.target is when all the system initialization is complete--when the user is asked to log in. Most user-facing services (like Apache, cron, GNOME-stuff, etc) use this target.
• RequiredBy: This field might feel very similar to WantedBy, but the main difference is that this field specifies hard dependencies. Meaning, if a dependency, this service will fail.

Other Unit Types

Systemd supports other unit types than .service.
Some include:

• Systemd-Timers
• Systemd-Mounts