15 systemd 守护程序 #

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

“单元文件”是 systemd 用于描述下列各项的通用术语：

有关 systemd 单元文件的详细信息，请参见 http://www.freedesktop.org/software/systemd/man/systemd.unit.html

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

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

tux > sudo systemctl start MY_1ST_SERVICE MY_2ND_SERVICE

要列出系统上所有可用的服务，请运行：

tux > 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 或在命令行上运行命令来实现此目的。

15.2.2.1 在命令行上启用/禁用服务 #

 

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

重要：服务启动

在命令行上启用服务时，服务不会自动启动。它会安排在下一次系统启动或运行级别/目标发生更改时启动。要在启用服务之后立即启动它，请显式运行 systemctl start MY_SERVICE 或 rc MY_SERVICE start。

表 15.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 不使用此配置。有关如何创建您自己的可引导目标的指导，请参考第 15.5.4 节 “创建自定义目标”。

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

root # 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'.

root # 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

tux > dmesg -T | less

systemd 与 System V 兼容，因此，您仍可以使用现有的 System V init 脚本。但是，至少有一个已知问题会导致 System V init 脚本不能立即与 systemd 配合使用：通过 init 脚本中的 su 或 sudo 以其他用户身份启动服务会导致脚本失败，生成“访问被拒绝”错误。

使用 su 或 sudo 更改用户时，会启动 PAM 会话。完成 init 脚本后会终止此会话。因此，init 脚本启动的服务也会终止。要解决此问题，请执行以下步骤：

建议使用 systemctl edit SERVICE 命令来自定义单元文件。此命令会启动默认的文本编辑器，并创建一个在 /etc/systemd/system/NAME.service.d/ 中包含 override.conf 文件的目录。该命令还确保会向正在运行的 systemd 进程通知这些更改。

或者，您可以通过运行 systemctl edit --full SERVICE 打开原始文件的副本进行编辑，而不是打开空白文件。编辑文件时，请确保未去除任何现有部分。

下面将练习如何更改系统等待 MariaDB 启动的时间。以 root 身份运行 systemctl edit --full mariadb.service。打开的文件如下所示：

[Unit]
Description=MySQL server
Wants=basic.target
Conflicts=mariadb.target
After=basic.target network.target

[Install]
WantedBy=multi-user.target
Alias=mysql.service

[Service]
Restart=on-abort
Type=notify
ExecStartPre=/usr/lib/mysql/mysql-systemd-helper  install
ExecStartPre=/usr/lib/mysql/mysql-systemd-helper  upgrade
ExecStart=/usr/lib/mysql/mysql-systemd-helper     start

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

# Prevent writes to /usr, /boot, and /etc
ProtectSystem=full

# Prevent accessing /home, /root and /run/user
ProtectHome=true

UMask=007

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

有关详细信息，请参考可使用 man 1 systemctl 命令调用的手册页。

要对配置文件进行细微更改，请使用所谓的插入式文件。使用插入式文件，您无需编辑或覆盖单元文件本身，即可扩展单元文件的配置。

例如，要更改位于 /usr/lib/systemd/system/FOOBAR.SERVICE 中 FOOBAR 服务的单个值，请按以下步骤操作：

注意：避免名称冲突

为避免插入式文件与 SUSE 自带的文件之间出现名称冲突，建议在所有插入式文件名前加上一个两位数和一个短划线：例如，80-override.conf。

以下范围为预留值范围：

• 0-19，为 systemd 上游预留

• 20-25，为 SUSE 自带的 systemd 预留

• 26-29，为 SUSE 软件包（systemd 除外）预留

• 50，为使用 systemctl set-property 创建的插入式文件预留

请使用大于此范围的两位数，以确保 SUSE 自带的任何插入式文件都不会覆盖您自己的插入式文件。

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

从 SUSE Linux Enterprise Server 15 版本开始，去除了 xinetd 基础架构。本节概述如何将现有的自定义 xinetd 服务文件转换为 systemd 套接字。

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

以下面的 xinetd 服务文件为例：

root # 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，需要下面两个配套的文件：

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

[Install]
WantedBy=sockets.target

root # 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 的“套接字”和“服务”文件选项的完整列表，请参见 systemd.socket 和 systemd.service 手册页（man 5 systemd.socket、man 5 systemd.service）。

System V init SUSE 系统上未使用运行级别 4，以便允许管理员创建自己的运行级别配置。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 计时器的状态：

tux > 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。

第 15.6.9 节 “调试服务” 介绍如何查看给定服务的日志消息。但可显示的日志消息并不仅限于服务日志。您还可以访问和查询 systemd 写入的完整日志，即所谓的“日志”。使用 journalctl 命令可显示完整的日志消息，从最早的项开始。有关诸如应用过滤器或更改输出格式的选项，请参考 man 1 journalctl。

您可以使用 isolate 子命令将 systemd 的当前状态保存到指定快照中，并在日后还原到该状态。此功能在测试服务或自定义目标时非常有用，因为它可让您随时回到定义的状态。快照仅在当前会话中可用，重引导时将自动删除。快照名称必须以 .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。因为非特权进程不允许“离开”它的 cgroup，这提供了一种行之有效的方式，可通过服务名称来标记该服务生成的所有进程。

要列出属于某个服务的所有进程，请使用命令 systemd-cgls。结果将如下所示（已精简）：

root # 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 的更多信息，请参见第 9 章 “内核控制组”。

如第 15.6.6 节 “内核控制组 (cgroup)”中所述，在 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 外壳脚本的计时器。

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

[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

您可以使用星号指定任何值，使用逗号列出可能的值。使用由 .. 分隔的两个值可表示一个连续的范围。下面的示例会在每个月的星期五下午 6 点触发服务：

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/ 目录中。要检查所创建的单元文件是否正确，请运行以下命令：

tux > 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。