tencent cloud

TencentOS Server

ドキュメントTencentOS ServerUser GuideSystem ConfigurationSystem Service Management (systemd)

System Service Management (systemd)

ダウンロード
フォーカスモード
フォントサイズ
最終更新日: 2026-10-19 17:22:49
AI翻訳
This document describes the common tools, service types, unit configurations, and service startup order of systemd, helping you understand and use systemd for system service management.

Common systemd Tools

systemctl

systemctl is the most commonly used systemd management tool. Its main commands are as follows:
Command
Description
status
View unit status.
cat
View unit configuration.
start/restart/stop
Control the current status of the unit.
set-property
Set unit configurations, such as CPUAccounting and CPUShares.
daemon-reload
Reload the manager configuration.
list-units
List the units in the system and their statuses.
list-dependencies
Display the dependencies between units in a tree diagram.
enable/disable
Enable or disable unit startup on boot, which is equivalent to creating or deleting a symbolic link to the unit file under /etc/systemd/.
mask/unmask
Similar to disable, but a service after mask cannot be started (even if required by other units), which is equivalent to creating a link to the unit file at /dev/null.

journalctl

journalctl is used to query systemd logs. Its common parameters are as follows:
Parameter
Description
-u
Query by unit
-b
Display only logs from the current startup.
-k
Display kernel-related logs.
For example, to view logs related to the dbus service:
journalctl -u dbus.service
The journalctl -b command can only view logs from the current boot. To query logs from previous boots, switch journald logs to disk storage (see the log management documentation), and then query them in the following ways:
Use the --list-boots parameter to list all boot records on the system:
journalctl --list-boots
The result is as follows, where the IDX column indicates the boot sequence number. Negative numbers represent historical boot records, and 0 represents the current boot:
IDX BOOT ID                          FIRST ENTRY                 LAST ENTRY
-9 9d27b37bc8014865b0c20c957429dc31 Wed 2023-01-18 15:44:22 HKT Fri 2023-02-24 10:27:36 HKT
-8 aa28b72e95074434a4a81b623c400e7e Tue 2023-02-28 16:35:24 HKT Tue 2023-02-28 16:45:08 HKT
-7 12a71bb5bd9d4dec993d0e03e0cbe636 Mon 2023-03-06 10:46:43 HKT Mon 2023-03-06 11:07:43 HKT
...
Specify the IDX number to view logs from the corresponding boot. For example, to view logs from the boot with sequence number -8:
journalctl -b -8

systemd-analyze

systemd-analyze is a system startup time analysis tool. Its main subcommands are as follows:
Subcommand
Description
blame
Analyze the startup time of each service in the system.
plot
Graphically display the startup order of services in the system. The result can be opened through a web page or a graphical editor.
dump
View the status and cgroup mask of each service, providing more details than systemctl status.

blame

The blame command analyzes the startup time of each service during the current system boot. By default, it lists the services in descending order of startup time:
systemd-analyze blame
The result is as follows, sorted by startup time in descending order:
8.814s kdump.service
2.442s NetworkManager-wait-online.service
944ms dev-vda1.device
568ms sshd-keygen@rsa.service
295ms initrd-switch-root.service
214ms var-lib-nfs-rpc_pipefs.mount
206ms dnf-makecache.service
194ms dracut-initqueue.service
143ms user@0.service
135ms ipmi.service
118ms initrd-parse-etc.service
103ms chronyd.service
99ms NetworkManager.service
99ms systemd-logind.service
92ms avahi-daemon.service
88ms auditd.service
71ms lvm2-monitor.service
...
You can use blame to conveniently troubleshoot system startup time. After identifying the time-consuming service, analyze the cause by examining its logs or using other troubleshooting methods. For example, in the output above, the kdump service has the longest startup time. The strace tool shows that its most time-consuming process is loading the kdump kernel.

systemd-cgls

systemd-cgls is used to view the cgroup hierarchy on the system. Compared with viewing the cgroup directories directly, systemd-cgls lists the processes in each cgroup and presents the relationships between hierarchy levels more clearly:
systemd-cgls
The result is as follows, displaying each cgroup and its processes in a tree structure:
├─user.slice
│ └─user-0.slice
│   → user.invocation_id: 183a492473c94efe8e3c4b1e1745f0b0
│   → trusted.invocation_id: 183a492473c94efe8e3c4b1e1745f0b0
│   ├─33878 sshd: root [priv]
│   ├─33892 sshd: root@pts/0
│   ├─33893 -bash
│   ├─35517 systemd-cgls
│   └─35518 less
│   └─user@0.service
│     └─init.scope
│       ├─33882 /usr/lib/systemd/systemd --user
│       └─33885 (sd-pam)
├─init.scope
│ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 31
└─system.slice
  ├─rngd.service
  │ └─685 /usr/sbin/rngd -f -x pkcs11 -x nist
  ├─irqbalance.service
  │ └─683 /usr/sbin/irqbalance --foreground

systemd-nspawn

The usage of systemd-nspawn is similar to that of chroot, but the directory to enter must be in the form of an OS tree. If the directory is in the correct OS tree form, first view the directory contents to confirm:
ls rootfs/
The result is as follows, indicating that the directory contains a complete OS file system structure:
bin  boot  data  dev  etc  home  lib  lib64  lost+found  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
After confirmation, create a lightweight container using systemd-nspawn:
Note:
If the directory does not meet the OS tree requirements, running the following command returns an error similar to Directory /root/rootfs doesn't look like it has an OS tree (/usr/ directory is missing). Refusing.:
systemd-nspawn -D ./rootfs
After successfully entering the container, the result is as follows:
Spawning container rootfs on /root/rootfs.
Press ^] three times within 1s to kill container.
If you need to simulate a real environment, you can also add the -b option to start systemd in the container.

systemd Services

Enabling Services at Boot

During startup, systemd determines which services start at boot based on the preset files in /usr/lib/systemd/system-preset/ and /usr/lib/systemd/user-preset/. The current system mainly has the following configuration files by default:
File Name
Function
90-default.preset
Control system services that start by default
99-default-disable.preset
Disable all services by default
85-display-manager.preset
Control whether desktop-related services require autostart
preset files determine the execution order by their file names. A smaller leading number indicates a higher priority and later execution. Therefore, even if all services are disabled in 99-default-disable.preset, you can still enable the required services in 90-default.preset and 85-display-manager.preset.

Types of systemd Units

service

service is the most commonly used unit type. It controls the running of processes on the system, including daemon processes, such as dbus.service and docker.service. Typically, ExecStart= specifies the action to start a program, ExecReload= specifies the action for systemctl reload, and ExecStop= specifies the action to stop the unit.
Use systemctl cat to view the unit file configuration of dbus.service:
systemctl cat dbus.service
The result is as follows. You can see the complete configuration of the service, including three sections: [Unit], [Service], and [Install]:
# /usr/lib/systemd/system/dbus-broker.service
[Unit]
Description=D-Bus System Message Bus
Documentation=man:dbus-broker-launch(1)
DefaultDependencies=false
After=dbus.socket
Before=basic.target shutdown.target
Requires=dbus.socket
Conflicts=shutdown.target
[Service]
Type=notify
Sockets=dbus.socket
OOMScoreAdjust=-900
LimitNOFILE=16384
ProtectSystem=full
PrivateTmp=true
PrivateDevices=true
ExecStart=/usr/bin/dbus-broker-launch --scope system --audit
ExecReload=/usr/bin/busctl call org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus ReloadConfig
[Install]
Alias=dbus.service
You can use systemctl status to view the status information of a service and print the journal logs related to the service. The following uses the sshd service as an example:
systemctl status sshd
The result is as follows, including the service load status, running status, main process PID, memory usage, and other information:
● sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2023-04-21 11:52:56 CST; 2 weeks 4 days ago
     Docs: man:sshd(8)
           man:sshd_config(5)
   Main PID: 1208 (sshd)
   Tasks: 1 (limit: 9183)
   Memory: 8.7M
      CPU: 199ms
   CGroup: /system.slice/sshd.service
           └─1208 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"
The meanings of the fields in the status output are as follows:
The dot before the service name ("●"): indicates the current status of the service with different colors and shapes.
Dot Color and Shape
Indicated Status
"○"
inactive or maintenance
"●" (green)
active
"●" (white)
deactivating
"×"
failed or error
"↻"
reloading
Loaded: indicates whether the service is loaded into memory. loaded means the service is loaded, error means loading failed, not-found means the unit file was not found, bad-setting means the unit file configuration is incorrect, and masked means the service is masked. The path that follows is the path of the loaded unit file, and the next field indicates whether the service is enabled to start at boot (enabled). vendor preset indicates whether the distribution vendor presets the service to start at boot.
Active: shows the running status of the service. The text before the parentheses is the current status, and the text inside the parentheses is the substatus.
The possible values of the current status are as follows:
Status
Description
active
The unit is running.
inactive
The unit has stopped running.
activating
The unit is starting.
deactivating
The unit is stopping.
failed
unit failed to start.
The possible values of the substatus are as follows:
Substatus
Description
running
The unit is running.
exited
The unit has stopped running.
waiting
The unit is waiting for certain conditions to occur, such as network connections and file system mounts.
start-pre
Pre-start preparation for the unit.
start-post
Post-start tasks for the unit.
stop-pre
Pre-stop preparation for the unit.
stop-post
Post-stop tasks for the unit.
The time that follows is the last time the service was started.

timer

timer is a timer that triggers and activates other units at fixed times (by default, the service with the same name). The trigger time is usually controlled by configuration items such as OnActiveSec=/OnCalendar= in the [Timer] section. For details, run man systemd.timer.
For example, *:00/10 configured in sysstat-collect means that the timer starts at the top of the hour and triggers every 10 minutes. Use systemctl cat to view its timer configuration:
systemctl cat sysstat-collect.timer
The result is as follows. You can see that the trigger interval is configured with OnCalendar=*:00/10 in the [Timer] section:
# /usr/lib/systemd/system/sysstat-collect.timer
# Activates activity collector every 10 minutes
[Unit]
Description=Run system activity accounting tool every 10 minutes
[Timer]
OnCalendar=*:00/10
[Install]
WantedBy=sysstat.service
With systemctl status, you can see that a timer has two additional fields compared to a service: Trigger and Triggers. Trigger indicates the next trigger time and the remaining time, and Triggers shows the services activated by the timer. Check the status of sysstat-collect.timer:
systemctl status sysstat-collect.timer
The result is as follows. In this example, the service triggered by the timer is sysstat-collect.service, and it will be triggered again in 8 minutes.
● sysstat-collect.timer - Run system activity accounting tool every 10 minutes
   Loaded: loaded (/usr/lib/systemd/system/sysstat-collect.timer; enabled; vendor preset: disabled)
   Active: active (waiting) since Thu 2023-05-11 20:04:47 CST; 1 week 0 days ago
   Until: Thu 2023-05-11 20:04:47 CST; 1 week 0 days ago
  Trigger: Thu 2023-05-18 20:40:00 CST; 8min left
 Triggers: ● sysstat-collect.service

mount

mount is used to control mount points in the system. It usually controls the mount location, device, and type through Where=/What=/Type= in the [Mount] section. Under normal circumstances, you only need to configure /etc/fstab, and systemd-fstab-generator automatically generates the corresponding mount units from the mount points in fstab.
Use systemctl cat to view the generated mnt.mount configuration:
systemctl cat mnt.mount
The result is as follows. This mount unit is automatically generated by systemd-fstab-generator, and its configuration corresponds to the mount entry in /etc/fstab:
# /run/systemd/generator/mnt.mount
# Automatically generated by systemd-fstab-generator
[Unit]
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
SourcePath=/etc/fstab
Before=local-fs.target
Requires=systemd-fsck@dev-vdb1.service
After=systemd-fsck@dev-vdb1.service
After=blockdev@dev-vdb1.target
[Mount]
What=/dev/vdb1
Where=/mnt
Type=ext4
Options=noatime,acl,user_xattr
For example, configure the following mount entry in /etc/fstab:
cat /etc/fstab
The result is as follows, which shows that /dev/vdc1 is mounted to the /data/ directory:
/dev/vdc1 /data/ ext4 noatime,acl,user_xattr 1 1
After a reboot, when systemd-fstab-generator runs at startup, the corresponding mount service is generated in the system, and its configuration corresponds to the entry in fstab. First, use systemctl list-units to confirm that the mount service has been generated:
systemctl list-units -a | grep data
The result is as follows. You can see that data.mount has been loaded and is in the active state:
data.mount    loaded    active   mounted   /data
Then run the following command to view its configuration:
systemctl cat data.mount
The result is as follows. The What, Where, Type, and Options in the configuration are consistent with those in /etc/fstab:
# /run/systemd/generator/data.mount
# Automatically generated by systemd-fstab-generator
[Unit]
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
SourcePath=/etc/fstab
Before=local-fs.target
Requires=systemd-fsck@dev-vdc1.service
After=systemd-fsck@dev-vdc1.service
After=blockdev@dev-vdc1.target
[Mount]
What=/dev/vdc1
Where=/data
Type=ext4
Options=noatime,acl,user_xattr

automount

automount is similar to mount. The difference is that automount mounts a directory only when a user accesses it, rather than remaining mounted since startup like mount. You can use the automount capability through autofs. The following example describes how to use the automount service.
1. Install the autofs service.
dnf install -y autofs
2. Configure the automount service in the /etc/auto.master file.
vim /etc/auto.master
Add the following content to the end of the file:
/mnt/ /etc/auto.devices --timeout=10
Here, /mnt/ is the path where the mount point resides (not the device mount point), /etc/auto.devices is the path to the device mount configuration file, and --timeout=10 indicates that the device mount timeout is 10 seconds.
3. Configure the devices to be mounted in the /etc/auto.devices file.
vim /etc/auto.devices
Add the device information to be mounted to the file:
mymnt -fstype=auto :/dev/vdb
Here, mymnt is the mounted directory, -fstype=auto indicates automatic detection of the device file system type, and :/dev/vdb is the device path.
4. Restart the autofs service.
systemctl restart autofs
5. Verify the automount feature.
When you need to access the mymnt device, access the mymnt directory under /mnt/, and the automount service automatically mounts the /dev/vdb device to that directory.
Attention: When the /mnt directory is entered, the mymnt directory is not visible and cannot be auto-completed with Tab, but it can still be accessed directly.
cd /mnt/mymnt
After you access the /mnt/mymnt directory, the automount service automatically mounts the /dev/vdb device to that directory. Use the lsblk command to check the mount status:
lsblk
The result is as follows, showing that /dev/vdb has been mounted to /mnt/mymnt:
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sr0     11:0    1 18.8M  0 rom
zram0  251:0    0    8G  0 disk [SWAP]
vda    252:0    0  100G  0 disk
└─vda1 252:1    0  100G  0 part /
vdb    252:16   0  200G  0 disk /mnt/mymnt
vdc    252:32   0  300G  0 disk
└─vdc1 252:33   0  300G  0 part /data
If the directory is not accessed for a period of time, the automount service automatically unmounts the device to release system resources.

target

Unlike other units, a target unit does not perform any operations itself but represents a group of units. A target controls the dependencies and startup order of each unit in the group through unit dependency configurations such as Requires=/After=, which can be viewed using systemctl list-dependencies. Take multi-user.target as an example:
systemctl list-dependencies multi-user.target
The result is as follows, displaying all units that the target depends on in a tree structure:
multi-user.target
● ├─acpid.service
● ├─arpwatch.service
● ├─atd.service
● ├─auditd.service
● ├─avahi-daemon.service
● ├─chrony-wait.service
● ├─chronyd.service
● ├─crond.service
● ├─gssproxy.service
During system startup, the specific services that each subsystem depends on are started sequentially through individual target services. For example, only default.target (multi-user.target or graphical.target in this system) needs to be started at startup, and the other targets only need to be specified in their unit files:
[Install]
WantedBy=multi-user.target
This enables the service to start before multi-user.target starts.

path

A path unit is similar to a timer unit. Its main purpose is to trigger the service with the same name when the monitored path changes. The monitored path and corresponding mode are controlled by configuration items such as DirectoryNotEmpty=/PathChanged= in the [Path] section.
Use systemctl cat to view the built-in systemd-ask-password-console.path configuration:
systemctl cat systemd-ask-password-console.path
The result is as follows, showing that the /run/systemd/ask-password directory is monitored through DirectoryNotEmpty= in the [Path] section:
# /usr/lib/systemd/system/systemd-ask-password-console.path
[Unit]
Description=Dispatch Password Requests to Console Directory Watch
Documentation=man:systemd-ask-password-console.path(8)
DefaultDependencies=no
Conflicts=shutdown.target emergency.service
After=plymouth-start.service
Before=paths.target shutdown.target cryptsetup.target
ConditionPathExists=!/run/plymouth/pid
[Path]
DirectoryNotEmpty=/run/systemd/ask-password
MakeDirectory=yes
The following example describes how to use the path service.
1. Create a .path unit file.
Create the my-path-monitor.path file in the /etc/systemd/system directory, and define the path to monitor and the trigger condition:
[Unit]
Description=Monitor changes in /data/testpath directory
[Path]
PathModified=/data/testpath
Unit=my-triggered-service.service
[Install]
WantedBy=multi-user.target
This .path unit file monitors changes in the /data/testpath directory. When the directory changes, the service named my-triggered-service.service is triggered.
2. Create the associated service unit file.
Create the my-triggered-service.service file in the /etc/systemd/system directory, and define the service behavior:
[Unit]
Description=Service triggered by path changes
[Service]
Type=oneshot
ExecStart=/usr/bin/echo "123"
The service executes echo 123 when the .path unit is triggered.
3. Reload the systemd configuration.
systemctl daemon-reload
4. Start the .path unit.
systemctl start my-path-monitor.path
5. Trigger a path change.
rm -r /data/testpath
6. Verify whether the service is triggered.
Check the logs of my-triggered-service.service. The service has been triggered by the path service:
systemctl status my-triggered-service.service
The result is as follows. You can see that the service has been triggered and executed, and the status inactive (dead) indicates that execution is complete:
○ my-triggered-service.service - Service triggered by path changes
   Loaded: loaded (/etc/systemd/system/my-triggered-service.service; static)
   Active: inactive (dead) since Mon 2023-05-29 03:09:15 UTC; 9s ago
TriggeredBy: ● my-path-monitor.path
   Process: 1227670 ExecStart=/usr/bin/echo 123 (code=exited, status=0/SUCCESS)
  Main PID: 1227670 (code=exited, status=0/SUCCESS)
     CPU: 1ms
May 29 03:09:15 localhost.localdomain systemd[1]: Starting my-triggered-service.service - Service triggered by path changes...
May 29 03:09:15 localhost.localdomain echo[1227670]: 123
May 29 03:09:15 localhost.localdomain systemd[1]: my-triggered-service.service: Deactivated successfully.
May 29 03:09:15 localhost.localdomain systemd[1]: Finished my-triggered-service.service - Service triggered by path changes.

socket

A socket unit, like timer/path units, is used together with a service unit. You can use a socket unit to specify the socket that systemd listens on. When data is written to the socket, systemd wakes up the corresponding service unit.
Use systemctl cat to view the configuration of the acpid service and its socket:
systemctl cat acpid acpid.socket
The result is as follows. You can see that the service depends on the corresponding socket unit through Requires=acpid.socket, and the socket unit specifies the listening address through ListenStream=/run/acpid.socket:
# /usr/lib/systemd/system/acpid.service
[Unit]
Description=ACPI Event Daemon
Documentation=man:acpid(8)
Requires=acpid.socket
[Service]
StandardInput=socket
EnvironmentFile=/etc/sysconfig/acpid
ExecStart=/usr/sbin/acpid -f $OPTIONS
[Install]
Also=acpid.socket
WantedBy=multi-user.target

# /usr/lib/systemd/system/acpid.socket
[Unit]
Description=ACPID Listen Socket
Documentation=man:acpid(8)
[Socket]
ListenStream=/run/acpid.socket
[Install]
WantedBy=sockets.target
The following example describes how to use the socket service.
1. Install the nc tool.
dnf install nc -y
2. Create a service unit file.
Create the socket_server.service file in the /etc/systemd/system directory:
[Unit]
Description=Socket Server
[Service]
ExecStart=nc -l 12345
User=nobody
Group=nobody
3. Create a socket unit file.
Create the socket_server.socket file in the /etc/systemd/system directory:
[Unit]
Description=Socket Server Socket
[Socket]
ListenStream=12345
Accept=yes
[Install]
WantedBy=sockets.target
This .socket unit file creates a TCP socket on port 12345 and activates socket_server.service when a connection request is received.
4. Reload the systemd configuration.
systemctl daemon-reload
5. Start the .socket unit.
systemctl start socket_server.socket
The socket has been created and is listening for connections. When a client connects to port 12345, socket_server.service is activated and runs nc -l 12345.
6. Verifying a Connection
Use telnet or nc (netcat) to connect to port 12345:
telnet localhost 12345

swap

The swap unit manages swap partition mounting. Similar to mount, it is usually configured through /etc/fstab and automatically generated by systemd-fstab-generator.
1. Create a swap file.
fallocate -l 1G /swapfile
2. Set the file as swap.
mkswap /swapfile
3. Add the swap configuration to the /etc/fstab file.
Add a line to the end of the /etc/fstab file to specify the path to the swap partition or file, the mount point (use none), the file system type (use swap), and the mount options (use sw). Finally, add two numbers 0 0 to indicate that no file system check is required:
/swapfile none swap sw 0 0
After a reboot, the swap partition or file is automatically enabled, and the system has automatically created the corresponding swap service. Use systemctl list-units to check the swap service status:
systemctl list-units -a | grep swap
The result is as follows. You can see that swapfile.swap has been loaded and is in the active state:
swapfile.swap    loaded    active   active    /swapfile
You can use the free -h or swapon --show command to check the swap status:
free -h
The result is as follows. You can see that the total Swap is 1.0Gi and is currently unused:
total          used        free      shared          buff/cache   available
Mem:           7.5Gi       195Mi       7.1Gi         9Mi          210Mi       7.1Gi
Swap:          1.0Gi          0B       1.0Gi

device

A device unit is created by systemd-udevd based on devices under /sys/ and /dev/. Its primary purpose is to control dependencies between devices and between devices and other units.
Use systemctl list-dependencies to view the dependencies of mnt.mount. You can see that it includes dev-vdb1.device:
systemctl list-dependencies mnt.mount
The result is as follows. mnt.mount depends on the corresponding block device unit dev-vdb1.device:
mnt.mount
● ├─-.mount
● ├─dev-vdb1.device
● ├─system.slice
○ └─systemd-fsck@dev-vdb1.service

slice

A slice is similar to a target and also represents a group of units, but a slice is used for resource control in cgroups. By default, the system divides units into user.slice (user sessions), system.slice (system processes), and machine.slice (container and virtual machine processes).
Use the tree command to view the cgroup hierarchy on the system:
tree -d /sys/fs/cgroup/
The result is as follows. You can see that each service belongs to system.slice and user.slice respectively:
/sys/fs/cgroup/
├── dev-hugepages.mount
├── dev-mqueue.mount
├── init.scope
├── proc-fs-nfsd.mount
├── proc-sys-fs-binfmt_misc.mount
├── sys-fs-fuse-connections.mount
├── sys-kernel-config.mount
├── sys-kernel-debug.mount
├── sys-kernel-tracing.mount
├── system.slice
│   ├── NetworkManager.service
│   ├── acpid.service
│   ├── arpwatch.service
│   ├── atd.service
│   ├── auditd.service
│   ├── avahi-daemon.service
│   ├── chronyd.service
│   ├── systemd-logind.service
│   ├── systemd-udevd.service
│   │   └── udev
│   ├── systemd-userdbd.service
│   ├── tmp.mount
│   └── var-lib-nfs-rpc_pipefs.mount
└── user.slice
  └─user-0.slice
      ├── session-1702.scope
      ├── session-22304.scope

scope

A scope is similar to a slice/target, but a scope unit can only be created through the systemd dbus interface, and processes in a scope unit do not create child processes on their own.

unit Configuration

systemd supports a large number of unit configuration parameters, and most issues are configuration-related. This section uses CPU resource control configuration as an example. CPU resource control configuration is mainly determined by the following methods:

default Configuration

systemd has a unit configuration table ConfigTableItem, and all configuration items in the table have default initial values. If no manual configuration is performed later, these properties will use the initial values from the code. For example, CPUAccounting defaults to false. You can view them in the src/core/main.c file:
static int parse_config_file(void) {
  const ConfigTableItem items[] = {
          { "Manager", "LogLevel",                     config_parse_level2,                0,                        NULL                              },
          { "Manager", "LogTarget",                    config_parse_target,                0,                        NULL                              },
          .....

manager Configuration File

The manager configuration file is located at the following path:
/etc/systemd/system.conf
/etc/systemd/user.conf
/etc/systemd/system.conf.d/
/etc/systemd/user.conf.d/

unit file

A unit's own configuration file is generally located under /usr/lib/systemd/system/. You can use systemctl cat a.service to view its specific content. When you manually set properties using the systemctl set-property command, an additional configuration file for the corresponding unit is eventually generated under /etc/systemd/.
Taking rsyslog.service as an example, use systemctl set-property to set the CPU quota to 50%:
systemctl set-property rsyslog.service CPUQuota=50%
Then use systemctl show to view the configuration path of this property:
systemctl show rsyslog.service | grep CPUQuota
The result is as follows. You can see that DropInPaths points to the path of the automatically generated configuration file:
DropInPaths=/etc/systemd/system.control/rsyslog.service.d/50-CPUQuota.conf
You can see that an additional configuration file is eventually generated at /etc/systemd/system.control/rsyslog.service.d/50-CPUQuota.conf. View the content of this file:
cat /etc/systemd/system.control/rsyslog.service.d/50-CPUQuota.conf
The result is as follows. The file records the CPUQuota=50% configuration that was set through set-property:
# This is a drop-in unit file extension, created via "systemctl set-property"
# or an equivalent operation. Do not edit.
[Service]
CPUQuota=50%

Service Startup Order

The startup order of systemd services is achieved by configuring dependencies between units. Dependencies between units fall into several categories, including automatically generated dependencies and explicitly configured dependencies.

Automatically Generating Dependencies

Automatically generated dependencies fall into two types: implicit dependencies and default dependencies.
Implicit dependencies: determined by the unit Type and Unit configuration. For example, dbus.service with Type=dbus implicitly depends on dbus.socket (equivalent to Requires= and After=dbus.socket).
Default dependencies: similar to implicit dependencies, but can be controlled by the DefaultDependencies= option. For example, if Wants= or Requires=B is configured in A.target, A is configured with an After=B by default. All targets are configured with Conflicts=shutdown.target and Before=shutdown.target by default to ensure that all targets have exited before shutdown. Triggers/TriggeredBy are configured by default in the corresponding services such as socket/path/mount.

Explicitly Configuring Dependencies

There are mainly six types of explicitly configured dependencies (paired in twos, with the same logic but opposite behaviors):
Dependencies
Description
Wants/WantedBy
Weak dependency. If A Wants= B, A attempts to start B when A starts. If B fails to start, A continues to start. The same effect can also be achieved by creating a .wants directory outside the unit file.
Requires/RequiredBy
Strong dependency. If A Requires= B, A attempts to start B when A starts. If B fails to start, A will not start. The same effect can also be achieved by creating a .requires/ directory.
BindsTo/BoundBy
Stronger dependency. Unlike Requires, if A BindsTo= B and A is stopped, B is also stopped, whereas with Requires, B is not affected.
Before/After
Startup order. If A Before= B, B can start only after A starts. The shutdown process is reversed: if A Before= B and both A and B need to be shut down, B shuts down first, and only then does A shut down.
PartOf/ConsistsOf
Similar to Requires, but PartOf only affects shutdown and restart operations. If A PartOf= B, when B is shut down or restarted, A is also shut down or restarted.
Conflicts/ConflictedBy
If A Conflicts= B, starting A stops B.
For example, to see what started the rsyslog service, use the --reverse option of the list-dependencies command to view reverse dependencies:
systemctl list-dependencies rsyslog --reverse
The result is as follows. You can see that rsyslog.service is started by multi-user.target, and multi-user.target is in turn started by graphical.target:
rsyslog.service
● └─multi-user.target
○   └─graphical.target
This dependency exists because the unit file of the rsyslog service contains the following configuration. Use systemctl cat to view its configuration:
systemctl cat rsyslog.service
The result is as follows. You can see that the dependency is specified in the [Install] section through WantedBy=multi-user.target:
# /usr/lib/systemd/system/rsyslog.service
[Unit]
...
[Install]
WantedBy=multi-user.target
...

前の記事へ: GRUB Management (grubby)次の記事へ: cgroup Resource Limits

ヘルプとサポート

この記事はお役に立ちましたか？

フィードバック

キーワードで検索
    Enter keywords to search documentation