单元配置文件包含有关服务、套接字、设备、挂载点、自动挂载点、交换文件或分区、启动目标、监视的文件系统路径、由 systemd 控制和监督的计时器、临时系统状态快照、资源管理切片或外部创建的进程组的信息。

“单元文件” 是 systemd 用于以下内容的通用术语

有关 systemd 单元文件的更多信息，请参阅 https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html

管理服务的子命令与使用 System V init 管理服务的命令相同（start、stop、...）。服务管理命令的一般语法如下

systemd 允许您一次管理多个服务。与 System V init 一样，逐个执行 init 脚本，而是执行如下命令

> sudo systemctl start MY_1ST_SERVICE MY_2ND_SERVICE

要列出系统上所有可用的服务

> sudo systemctl list-unit-files --type=service

下表列出了 systemd 和 System V init 的最重要服务管理命令

start

start

stop

stop

restart

restart

try-restart

try-restart

reload

reload

reload-or-restart

n/a

reload-or-try-restart

n/a

status

status

is-active

status

上一节中提到的服务管理命令允许您操作当前会话的服务。systemd 还允许您永久启用或禁用服务，以便在请求时自动启动或始终不可用。您可以通过 YaST 或命令行来执行此操作。

10.2.2.1 在命令行上启用/禁用服务 #编辑源文件

下表列出了 systemd 和 System V init 的启用和禁用命令

重要：服务启动

在命令行上启用服务时，不会自动启动它。它计划在下一次系统启动或 runlevel/target 更改时启动。要在启用服务后立即启动它，请显式运行 systemctl start MY_SERVICE 或 rc MY_SERVICE start。

表 10.2：启用和禁用服务的命令 #

任务	systemd 命令	System V init 命令
启用。	systemctl enable MY_SERVICE(S)	insserv MY_SERVICE(S)，chkconfig -a MY_SERVICE(S)
禁用。	systemctl disable MY_SERVICE(S).service	insserv -r MY_SERVICE(S)，chkconfig -d MY_SERVICE(S)
检查。 显示服务是否已启用。	systemctl is-enabled MY_SERVICE	chkconfig MY_SERVICE
重新启用。 类似于重新启动服务，此命令首先禁用然后启用服务。对于使用默认值重新启用服务很有用。	systemctl reenable MY_SERVICE	不可用
屏蔽。 在“禁用”服务后，仍然可以手动启动它。要禁用服务，需要屏蔽它。请谨慎使用。	systemctl mask MY_SERVICE	不可用
取消屏蔽。 屏蔽的服务只有在取消屏蔽后才能再次使用。	systemctl unmask MY_SERVICE	不可用

使用 System V init，系统启动到所谓的“运行级别”。运行级别定义了系统如何启动以及在运行系统中提供哪些服务。运行级别编号；最常用的编号是 0（关闭系统）、3（具有网络的单用户）和 5（具有网络和显示管理器的多用户）。

systemd 引入了一个新概念，即使用所谓的“目标单元”。但是，它仍然与运行级别概念完全兼容。目标单元是命名的，而不是编号的，并且具有特定的目的。例如，目标 local-fs.target 和 swap.target 挂载本地文件系统和交换空间。

目标 graphical.target 提供具有网络和显示管理器的多用户系统，相当于运行级别 5。复杂的目标，例如 graphical.target 作为“元”目标通过组合其他目标的子集来工作。由于 systemd 允许通过组合现有目标轻松创建自定义目标，因此它提供了很大的灵活性。

以下列表显示了最重要的 systemd 目标单元。有关完整列表，请参阅 man 7 systemd.special。

为了与 System V init 运行级别系统兼容，systemd 提供了名为 runlevelX.target 的特殊目标，它映射了编号为 X 的相应运行级别。

要检查当前目标，请使用命令：systemctl get-default

重要提示：systemd 忽略 /etc/inittab

在 System V init 系统中，运行级别在 /etc/inittab 中配置。 systemd 不使用此配置。有关如何创建自己的可启动目标的说明，请参阅 第 10.5.5 节，“创建自定义目标”。

systemd 提供了分析系统启动过程的手段。您可以查看所有服务及其状态的列表（而不必解析 /var/log/）。 systemd 还允许您扫描启动过程，以了解每个服务启动消耗的时间。

# systemctl
UNIT                        LOAD   ACTIVE SUB       JOB DESCRIPTION
[...]
iscsi.service               loaded active exited    Login and scanning of iSC+
kmod-static-nodes.service   loaded active exited    Create list of required s+
libvirtd.service            loaded active running   Virtualization daemon
nscd.service                loaded active running   Name Service Cache Daemon
chronyd.service             loaded active running   NTP Server Daemon
polkit.service              loaded active running   Authorization Manager
postfix.service             loaded active running   Postfix Mail Transport Ag+
rc-local.service            loaded active exited    /etc/init.d/boot.local Co+
rsyslog.service             loaded active running   System Logging Service
[...]
LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

161 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

# systemctl --failed
UNIT                   LOAD   ACTIVE SUB    JOB DESCRIPTION
apache2.service        loaded failed failed     apache
NetworkManager.service loaded failed failed     Network Manager
plymouth-start.service loaded failed failed     Show Plymouth Boot Screen

[...]

systemd.log_level=debug systemd.log_target=kmsg

> dmesg -T | less

systemd 与 System V 兼容，允许您继续使用现有的 System V init 脚本。但是，已知至少存在一个问题，即 System V init 脚本在不进行任何修改的情况下无法与 systemd 一起工作：通过 su 或 sudo 在 init 脚本中以不同用户身份启动服务会导致脚本失败，产生““访问被拒绝””错误。

在使用 su 或 sudo 更改用户时，将启动 PAM 会话。该会话将在 init 脚本完成后终止。因此，由 init 脚本启动的服务也会终止。要解决此错误，请按以下步骤操作

SUSE 提供的 systemd 单元文件存储在 /usr/lib/systemd/ 中。自定义单元文件和单元文件 drop-ins 存储在 /etc/systemd/ 中。

警告：防止您的自定义被覆盖

自定义 systemd 时，始终使用目录 /etc/systemd/ 而不是 /usr/lib/systemd/。否则，您的更改将在下一次更新 systemd 时被覆盖。

Drop-in 文件（或 drop-ins）是部分单元文件，仅覆盖单元文件的特定设置。Drop-in 具有比主配置文件更高的优先级。命令 systemctl edit SERVICE 启动默认文本编辑器，并在 /etc/systemd/system/NAME.service.d/ 中创建一个带有空 override.conf 文件的目录。该命令还会确保正在运行的 systemd 进程收到更改通知。

例如，要更改系统等待 MariaDB 启动的时间量，请运行 sudo systemctl edit mariadb.service 并编辑打开的文件以仅包含修改后的行

# Configures the time to wait for start-up/stop
TimeoutSec=300

调整 TimeoutSec 值并保存更改。要启用更改，请运行 sudo systemctl daemon-reload。

有关更多信息，请参阅可以使用命令 man 1 systemctl 调用的手册页。

警告：创建完整的单元文件副本

如果使用 --full 选项在 systemctl edit --full SERVICE 命令中，将创建原始单元文件的副本，您可以在其中修改特定选项。我们不建议进行此类自定义，因为当 SUSE 更新单元文件时，其更改会被 /etc/systemd/system/ 目录中的自定义副本覆盖。此外，如果 SUSE 提供对分发 drop-in 的更新，它们会覆盖使用 --full 创建的单元文件副本。为了防止混淆并始终使您的自定义有效，请使用 drop-in。

除了使用 systemctl edit 命令之外，您还可以手动创建 drop-in 文件以更好地控制其优先级。此类 drop-in 允许您扩展单元和守护程序配置文件，而无需编辑或覆盖文件本身。它们存储在以下目录中

提示

请参阅可以使用命令 man 5 systemd.unit 调用的手册页，以获取完整的单元搜索路径列表。

例如，要禁用默认设置强制执行的 systemd-journald 的速率限制，请执行以下步骤

注意：避免名称冲突

为了避免您的 drop-in 文件与 SUSE 提供的文件之间的名称冲突，建议将所有 drop-in 文件都以两位数字和破折号作为前缀，例如 80-override.conf。

以下范围已保留

• 0-19 保留给 systemd 上游。

• 20-29 保留给 SUSE 提供的 systemd。

• 30-39 保留给 SUSE 除了 systemd 之外的其他软件包。

• 40-49 保留给第三方软件包。

• 50 保留给使用 systemctl set-property 创建的单元 drop-in 文件。

使用高于此范围的两位数字，以确保 SUSE 提供的任何 drop-in 文件都无法覆盖您自己的 drop-in 文件。

提示

您可以使用 systemctl cat $UNIT 来列出并验证哪些文件被纳入单元配置中。

提示

由于 systemd 组件的配置可能分散在文件系统中的不同位置，因此很难获得全局概览。要检查 systemd 组件的配置，请使用以下命令

• systemctl cat UNIT_PATTERN 打印与一个或多个 systemd 单元相关的配置文件，例如

  > systemctl cat atd.service

• systemd-analyze cat-config DAEMON_NAME_OR_PATH 复制 systemd 守护进程的配置文件的内容和 drop-in 文件，例如

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

自 openSUSE Leap 15 发布以来，xinetd 基础设施已被移除。本节概述了如何将现有的自定义 xinetd 服务文件转换为 systemd sockets。

对于每个 xinetd 服务文件，您至少需要两个 systemd 单元文件：socket 文件 (*.socket) 和关联的服务文件 (*.service)。socket 文件告诉 systemd 创建哪个 socket，而服务文件告诉 systemd 启动哪个可执行文件。

考虑以下示例 xinetd 服务文件

# cat /etc/xinetd.d/example
service example
{
  socket_type = stream
  protocol = tcp
  port = 10085
  wait = no
  user = user
  group = users
  groups = yes
  server = /usr/libexec/example/exampled
  server_args = -auth=bsdtcp exampledump
  disable = no
}

要将其转换为 systemd，您需要以下两个匹配的文件

# cat /usr/lib/systemd/system/example.socket
[Socket]
ListenStream=0.0.0.0:10085
Accept=false

[Install]
WantedBy=sockets.target

# cat /usr/lib/systemd/system/example.service
[Unit]
Description=example

[Service]
ExecStart=/usr/libexec/example/exampled -auth=bsdtcp exampledump
User=user
Group=users
StandardInput=socket

有关 systemd “socket” 和 “service” 文件选项的完整列表，请参阅 systemd.socket 和 systemd.service 手册页 (man 5 systemd.socket, man 5 systemd.service)。

在 System V init SUSE 系统上，runlevel 4 未被使用，以允许管理员创建自己的 runlevel 配置。 systemd 允许您创建任意数量的自定义目标。建议从调整现有的目标开始，例如 graphical.target。

systemd 支持定期清理临时目录。以前版本的配置会自动迁移并处于活动状态。 tmpfiles.d—负责管理临时文件—从 /etc/tmpfiles.d/*.conf、/run/tmpfiles.d/*.conf 和 /usr/lib/tmpfiles.d/*.conf 文件读取其配置。放置在 /etc/tmpfiles.d/*.conf 中的配置会覆盖来自其他两个目录的相关配置（/usr/lib/tmpfiles.d/*.conf 是软件包存储其配置文件的地方）。

配置格式是每行一个路径，包含操作和路径，以及可选的模式、所有权、年龄和参数字段，具体取决于操作。以下示例取消链接 X11 锁文件

Type Path               Mode UID  GID  Age Argument
r    /tmp/.X[0-9]*-lock

要获取 tmpfile 定时器的状态

> sudo systemctl status systemd-tmpfiles-clean.timer
systemd-tmpfiles-clean.timer - Daily Cleanup of Temporary Directories
 Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.timer; static)
 Active: active (waiting) since Tue 2018-04-09 15:30:36 CEST; 1 weeks 6 days ago
   Docs: man:tmpfiles.d(5)
         man:systemd-tmpfiles(8)

Apr 09 15:30:36 jupiter systemd[1]: Starting Daily Cleanup of Temporary Directories.
Apr 09 15:30:36 jupiter systemd[1]: Started Daily Cleanup of Temporary Directories.

有关临时文件处理的更多信息，请参阅 man 5 tmpfiles.d。

第 10.6.9 节，“调试服务” 解释了如何查看给定服务的日志消息。但是，显示日志消息不限于服务日志。您还可以访问和查询 systemd 写入的完整日志消息—所谓的““Journal””。使用命令 journalctl 显示完整的日志消息，从最早的条目开始。有关应用过滤器或更改输出格式等选项，请参阅 man 1 journalctl。

您可以将 systemd 的当前状态保存到命名快照中，稍后可以使用 isolate 子命令恢复到它。这在测试服务或自定义目标时很有用，因为它允许您随时返回到定义的狀態。快照仅在当前会话中可用，并在重新启动时自动删除。快照名称必须以 .snapshot 结尾。

使用 systemd，内核模块可以在启动时通过 /etc/modules-load.d 中的配置文件自动加载。该文件应命名为 MODULE.conf 并且具有以下内容

# load module MODULE at boot time
MODULE

如果软件包安装了用于加载内核模块的配置文件，则该文件将安装到 /usr/lib/modules-load.d。如果存在两个名称相同的配置文件，则 /etc/modules-load.d 中的文件优先。

有关更多信息，请参阅 modules-load.d(5) 手册页。

使用 System V init，需要在 /etc/init.d/before.local 中指定的在加载服务之前需要执行的操作。此过程不再受 systemd 支持。如果您需要执行操作，请执行以下操作

在传统的 System V init 系统上，有时无法将进程与生成它的服务匹配。某些服务（例如 Apache）会生成许多第三方进程（例如 CGI 或 Java 进程），这些进程本身又会生成更多进程。这使得清晰的分配变得困难甚至不可能。此外，服务可能无法正确完成，留下某些子进程处于活动状态。

systemd 通过将每个服务放入自己的 cgroup 来解决此问题。cgroups 是内核功能，允许将进程及其所有子进程聚合到分层组织的组中。 systemd 根据其服务命名每个 cgroup。由于非特权进程不允许““离开””其 cgroup，因此这提供了一种有效地使用服务名称标记服务生成的所有进程的方法。

要列出属于服务的进程，请使用命令 systemd-cgls，例如

# systemd-cgls --no-pager
├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 20
├─user.slice
│ └─user-1000.slice
│   ├─session-102.scope
│   │ ├─12426 gdm-session-worker [pam/gdm-password]
│   │ ├─15831 gdm-session-worker [pam/gdm-password]
│   │ ├─15839 gdm-session-worker [pam/gdm-password]
│   │ ├─15858 /usr/lib/gnome-terminal-server

[...]

└─system.slice
  ├─systemd-hostnamed.service
  │ └─17616 /usr/lib/systemd/systemd-hostnamed
  ├─cron.service
  │ └─1689 /usr/sbin/cron -n
  ├─postfix.service
  │ ├─ 1676 /usr/lib/postfix/master -w
  │ ├─ 1679 qmgr -l -t fifo -u
  │ └─15590 pickup -l -t fifo -u
  ├─sshd.service
  │ └─1436 /usr/sbin/sshd -D

[...]

有关 cgroups 的更多信息，请参阅 “系统分析和调优指南”书籍，第 10 章“内核控制组”。

如 第 10.6.6 节，“内核控制组 (cgroups)” 所述，在 System V init 系统中，有时无法将进程分配给其父服务进程。这使得停止服务及其子进程变得困难。未终止的子进程仍然是僵尸进程。

systemd 将每个服务限制到 cgroup 的概念使得能够识别服务的子进程，因此允许您将信号发送到这些进程中的每一个。使用 systemctl kill 向服务发送信号。有关可用信号的列表，请参阅 man 7 signals。

D-Bus 服务是 systemd 客户端与作为 pid 1 运行的 systemd 管理器之间通信的消息总线。即使 dbus 是一个独立的守护进程，但它也是 init 基础设施不可或缺的一部分。

停止 dbus 或在运行系统中重新启动它类似于尝试停止或重新启动 PID 1。它破坏了 systemd 客户端/服务器通信，并使大多数 systemd 功能无法使用。

因此，不建议也不支持终止或重新启动 dbus。

更新 dbus 或 dbus 相关软件包需要重新启动。如果不确定是否需要重新启动，请运行 sudo zypper ps -s。如果 dbus 出现在列出的服务中，则需要重新启动系统。

请记住，即使自动更新配置为跳过需要重新启动的软件包，dbus 也会更新。

默认情况下，systemd 并非过于冗长。如果服务启动成功，则不会产生任何输出。如果发生故障，将显示一条简短的错误消息。但是，systemctl status 提供了一种调试服务启动和运行的方式。

systemd 带有自己的日志记录机制（““日志””），用于记录系统消息。这允许您将服务消息与状态消息一起显示。 status 命令的工作方式类似于 tail，并且还可以以不同的格式显示日志消息，使其成为一个强大的调试工具。

定时器单元可以使用单调和实时定时器。

每个定时器单元都必须有一个对应的 systemd 单元文件来控制它。换句话说，一个 .timer 文件激活和管理相应的 .service 文件。与定时器一起使用时，.service 文件不需要 [Install] 部分，因为服务由定时器管理。

要了解 systemd 定时器单元的基础知识，我们设置一个定时器来触发 foo.sh shell 脚本。

第一步是创建一个 systemd 服务单元来控制 shell 脚本。为此，打开一个新文本文件进行编辑，并添加以下服务单元定义

[Unit]
Description="Foo shell script"

[Service]
ExecStart=/usr/local/bin/foo.sh

将文件保存为 foo.service，并将其放在 /etc/systemd/system/ 目录中。

接下来，打开一个新文本文件进行编辑，并添加以下定时器定义

[Unit]
Description="Run foo shell script"

[Timer]
OnBootSec=5min
OnUnitActiveSec=24h
Unit=foo.service

[Install]
WantedBy=multi-user.target

上述示例中的 [Timer] 部分指定要触发的服务（foo.service）以及何时触发它。在这种情况下，OnBootSec 选项指定一个单调定时器，该定时器在系统启动后五分钟触发服务，而 OnUnitActiveSec 选项在服务激活后 24 小时触发服务（即，定时器每天触发服务一次）。最后，WantedBy 选项指定定时器应在系统达到多用户目标时启动。

您可以指定实时定时器，而不是使用 OnCalendar 选项。以下实时定时器定义每周触发一次相关服务，从周一中午 12:00 开始。

[Timer]
OnCalendar=weekly
Persistent=true

Persistent=true 选项指示如果定时器错过了上次启动时间（例如，因为系统已关机），则在定时器激活后立即触发服务。

OnCalendar 选项还可以用于使用以下格式定义触发服务的特定日期时间：DayOfWeek Year-Month-Day Hour:Minute:Second。以下示例每天凌晨 5 点触发服务

OnCalendar=*-*-* 5:00:00

您可以使用星号指定任何值，并使用逗号列出可能的值。使用两个值，用 .. 分隔，表示一个连续的范围。以下示例每月 19 点触发服务

OnCalendar=Fri *-*-1..7 18:00:00

要以不同的时间触发服务，您可以指定多个 OnCalendar 条目

OnCalendar=Mon..Fri 10:00
OnCalendar=Sat,Sun 22:00

在上面的示例中，服务在工作日早上 10 点触发，在周末晚上 10 点触发。

完成编辑定时器单元文件后，将其保存为 foo.timer，并将其放在 /etc/systemd/system/ 目录中。要检查创建的单元文件的正确性，请运行以下命令

> sudo  systemd-analyze verify /etc/systemd/system/foo.*

如果该命令没有返回任何输出，则文件已通过验证。

要启动定时器，请使用命令 sudo systemctl start foo.timer。要在启动时启用定时器，请运行命令 sudo systemctl enable foo.timer。

由于定时器被视为常规 systemd 单元，因此可以使用 systemctl 进行管理。可以使用 systemctl start 启动定时器，使用 systemctl enable 启用定时器，依此类推。此外，可以使用命令 systemctl list-timers 列出所有活动定时器。要列出所有定时器，包括非活动定时器，请运行命令 systemctl list-timers --all。