15 systemd 守护程序 #

systemd 是适用于 Linux 的系统和会话管理器，它与 System V 及 LSB init 脚本兼容。主要功能包括：

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

有关 systemd.unit 的更多信息，请参见 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.3 节 “创建自定义目标”。

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 脚本启动的服务也会终止。要解决此问题，请执行以下步骤：

systemd 单元文件位于 /usr/lib/systemd/system 中。如果您要自定义服务文件，请执行下列步骤：

/etc/systemd 中修改过的文件优先于 /usr/lib/systemd/system 中的原始文件，前提是它们的文件名相同。

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
}

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

如果您只想在配置文件中添加几行或修改文件的一小部分，可以使用所谓的“插入式”文件。使用插入式文件，您无需编辑或覆盖单元文件本身，即可扩展单元文件的配置。

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

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 节 “内核控制组 (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 相似，也可以采用不同的格式显示日志讯息，是一个功能强大的调试工具。