systemd
来自项目网页
- systemd 是一套构建 Linux 系统的基础组件。它提供了一个系统和服务管理器，以 PID 1 运行并启动系统的其余部分。 systemd 提供了强大的并行处理能力，使用套接字和 D-Bus 激活来启动服务，提供按需启动守护进程，使用 Linux 控制组跟踪进程，维护挂载点和自动挂载点，并实现了精细的、基于事务的依赖关系的服务控制逻辑。 systemd 支持 SysV 和 LSB init 脚本，可以作为 sysvinit 的替代品。 其他组件包括日志守护进程，用于控制基本系统配置（如主机名、日期、区域设置）的实用程序，维护已登录用户以及正在运行的容器和虚拟机列表，系统账户，运行时目录和设置，以及用于管理简单网络配置、网络时间同步、日志转发和域名解析的守护进程。
从历史上看，systemd 称之为“服务”的概念，以前被称为守护进程（daemon）：指任何作为“后台”进程（没有终端或用户界面）运行的程序，通常等待事件发生并提供服务。 一个典型的例子是 Web 服务器，它等待请求来提供网页；或者 SSH 服务器，它等待用户尝试登录。 虽然这些是功能完整的应用程序，但有些守护进程的工作并不那么显眼。 守护进程用于执行诸如将消息写入日志文件（例如 syslog, metalog）或保持系统时间准确（例如 ntpd）之类的任务。 更多信息请参考 daemon(7)。
systemctl 的基本用法
用于内省和控制 systemd 的主要命令是 systemctl。 它的一些用途包括检查系统状态以及管理系统和服务。 有关更多详细信息，请参见 systemctl(1)。
- 您可以将以下所有 systemctl 命令与
-H user@host开关一起使用，以控制远程计算机上的 systemd 实例。 这将使用 SSH 连接到远程 systemd 实例。 - Plasma 用户可以安装 systemdgenie 作为 systemctl 的图形前端。 安装后，该模块将添加到“系统”下。
使用单元
单元通常包括但不限于服务 (.service)、挂载点 (.mount)、设备 (.device) 和套接字 (.socket)。
使用 systemctl 时，您通常必须指定单元文件的完整名称，包括其后缀，例如 sshd.socket。 但是，在以下 systemctl 命令中指定单元时，有一些简写形式
- 如果您不指定后缀，systemctl 将假定为 .service。 例如，
netctl和netctl.service是等效的。 - 挂载点将自动转换为相应的 .mount 单元。 例如，指定
/home等效于home.mount。 - 与挂载点类似，设备也会自动转换为相应的 .device 单元，因此指定
/dev/sda2等效于dev-sda2.device。
有关详细信息，请参见 systemd.unit(5)。
name@string.service）：这意味着它们是模板单元的实例，其实际文件名不包含 string 部分（例如 name@.service）。 string 称为实例标识符，类似于在使用 systemctl 命令调用模板单元时传递给模板单元的参数：在单元文件中，它将替换 %i 说明符。 更准确地说，在尝试实例化 name@.suffix 模板单元之前，systemd 实际上会查找具有完全匹配的 name@string.suffix 文件名的单元，尽管按照惯例，这种“冲突”很少发生，即大多数包含 @ 符号的单元文件都旨在成为模板。 此外，如果调用模板单元时没有实例标识符，则通常会失败（某些 systemctl 命令（如 cat）除外）。下表中的命令对系统单元进行操作，因为 --system 是 systemctl 的默认隐含选项。 要改为对用户单元（对于调用用户）进行操作，请使用 systemctl --user，无需 root 权限。 另请参阅 systemd/User#Basic setup 以启用/禁用所有用户的用户单元。
- 如果指定了多个单元，大多数命令也有效，有关更多信息，请参见 systemctl(1)。
--now开关可以与enable、disable和mask结合使用，以便分别立即启动、停止或屏蔽单元，而不是在重启后才操作。- 一个软件包可能提供用于不同目的的单元。 如果您刚刚安装了一个软件包，则可以使用
pacman -Qql package | grep -Fe .service -e .socket来检查并找到它们。 - 在可用时，启用
unit.socket而不是unit.service可能是有益的，因为套接字会在必要时启动服务。 有关更多详细信息，请参见 #套接字激活。
| 操作 | 命令 | 注意 |
|---|---|---|
| 分析系统状态 | ||
| 显示系统状态 | systemctl status |
|
| 列出正在运行的单元 | systemctl 或systemctl list-units |
|
| 列出失败的单元 | systemctl --failed |
|
| 列出已安装的单元文件1 | systemctl list-unit-files |
|
| 显示 PID 的进程状态 | systemctl status pid |
cgroup 切片、内存和父进程 |
| 检查单元状态 | ||
| 显示与单元关联的手册页 | systemctl help unit |
由单元支持 |
| 单元状态 | systemctl status unit |
包括它是否正在运行 |
| 检查单元是否已启用 | systemctl is-enabled unit |
|
| 启动、重启、重载单元 | ||
| 立即启动单元 | systemctl start unit 以 root 身份 |
|
| 立即停止单元 | systemctl stop unit 以 root 身份 |
|
| 重启单元 | systemctl restart unit 以 root 身份 |
|
| 重载单元及其配置 | systemctl reload unit 以 root 身份 |
|
| 重载 systemd 管理器配置2 | systemctl daemon-reload 以 root 身份 |
扫描新的或已更改的单元 |
| 启用单元 | ||
| 启用单元以便在启动时自动启动 | systemctl enable unit 以 root 身份 |
|
| 启用单元以便在启动时自动启动并立即启动它 | systemctl enable --now unit 以 root 身份 |
|
| 禁用单元以便不再在启动时启动 | systemctl disable unit 以 root 身份 |
|
| 重新启用单元3 | systemctl reenable unit 以 root 身份 |
即禁用并重新启用 |
| 屏蔽单元 | ||
| 屏蔽单元使其无法启动4 | systemctl mask unit 以 root 身份 |
|
| 取消屏蔽单元 | systemctl unmask unit 以 root 身份 |
|
- 有关可以找到可用单元文件的目录，请参见 systemd.unit(5) § UNIT FILE LOAD PATH。
- 这不会要求已更改的单元重新加载其自身的配置（请参见“重载”操作）。
- 例如，如果自上次启用以来，其
[Install]部分已更改。 - 手动和作为依赖项，这使得屏蔽操作很危险。 使用以下命令检查现有屏蔽单元
$ systemctl list-unit-files --state=masked
电源管理
polkit 对于以非特权用户进行电源管理是必要的。 如果您在本地 systemd-logind 用户会话中且没有其他会话处于活动状态，则以下命令无需 root 权限即可工作。 如果不是（例如，因为另一个用户已登录到 tty），systemd 将自动要求您输入 root 密码。
| 操作 | 命令 |
|---|---|
| 关闭并重启系统 | systemctl reboot
|
| 关闭并断电系统 | systemctl poweroff
|
| 挂起系统 | systemctl suspend
|
| 使系统进入休眠状态（将 RAM 写入磁盘） | systemctl hibernate
|
| 使系统进入混合睡眠状态（也称为挂起到内存和磁盘，它将 RAM 保存到磁盘，然后挂起） | systemctl hybrid-sleep
|
| 首先挂起系统，然后在配置的时间后唤醒，以便仅使系统休眠 | systemctl suspend-then-hibernate
|
| 使用#软重启执行仅用户空间的重启。 | systemctl soft-reboot
|
软重启
软重启是一种特殊类型的仅用户空间的重启操作，不涉及内核。 它由 systemd-soft-reboot.service(8) 实现，可以通过 systemctl soft-reboot 调用。 与 kexec 类似，它跳过固件重新初始化，但此外，系统不会经历内核初始化和 initramfs，并且未锁定的 dm-crypt 设备仍然连接。
当 /run/nextroot/ 包含有效的根文件系统层次结构（例如，是另一个发行版或另一个快照的根挂载点）时，软重启会将系统根切换到其中，从而允许切换到另一个安装，而不会丢失由内核管理的状态，例如网络。
/run/nextroot/ 不一定是挂载点或由物理设备支持。 例如，它可以驻留在 /run/ tmpfs 中。 systemd 将在软重启时自动将 /run/nextroot/ 转换为挂载点。systemctl soft-reboot。编写单元文件
systemd 单元文件 (systemd.unit(5)) 的语法灵感来自 XDG Desktop Entry Specification .desktop 文件，后者又受到 Microsoft Windows .ini 文件的启发。 单元文件从多个位置加载（要查看完整列表，请运行 systemctl show --property=UnitPath），但主要位置是（从最低到最高优先级列出）
/usr/lib/systemd/system/：已安装软件包提供的单元/etc/systemd/system/：系统管理员安装的单元
- 在用户模式下运行 systemd 时，加载路径完全不同。
- systemd 单元名称只能包含 ASCII 字母数字字符、下划线和句点。 所有其他字符必须替换为 C 风格的 “\x2d” 转义符，或使用其预定义的语义（'@'、'-'）。 有关更多信息，请参见 systemd.unit(5) 和 systemd-escape(1)。
查看您的软件包安装的单元以获取示例，以及 systemd.service(5) § EXAMPLES。
# 开头的注释也可以在单元文件中使用，但只能在新行中使用。 请勿在 systemd 参数后使用行尾注释，否则单元将无法激活。systemd-analyze(1) 可以帮助验证工作。 请参阅该页面的 systemd-analyze verify FILE... 部分。
处理依赖关系
使用 systemd，可以通过正确设计单元文件来解决依赖关系。 最典型的情况是当单元 A 需要单元 B 在 A 启动之前运行。 在这种情况下，将 Requires=B 和 After=B 添加到 A 的 [Unit] 部分。 如果依赖项是可选的，则添加 Wants=B 和 After=B。 请注意，Wants= 和 Requires= 并不意味着 After=，这意味着如果未指定 After=，则两个单元将并行启动。
依赖项通常放在服务上，而不是#目标上。 例如，network.target 由配置网络接口的任何服务拉入，因此将您的自定义单元排序在其之后就足够了，因为 network.target 无论如何都会启动。
服务类型
在编写自定义服务文件时，需要考虑几种不同的启动类型。 这是通过 [Service] 部分中的 Type= 参数设置的
Type=simple（默认）：systemd 认为服务已立即启动。 该进程不得 fork。 如果其他服务需要在此服务上排序，请勿使用此类型，除非它是套接字激活的。Type=forking：systemd 认为服务在进程 fork 并且父进程退出后启动。 对于经典守护进程，请使用此类型，除非您知道没有必要。 您还应该指定PIDFile=，以便 systemd 可以跟踪主进程。Type=oneshot：这对于执行单个作业然后退出的脚本很有用。 您可能还想设置RemainAfterExit=yes，以便 systemd 在进程退出后仍将服务视为活动状态。 设置RemainAfterExit=yes适用于更改系统状态的单元（例如，挂载某些分区）。 另请参见 [1]，了解 simple 和 oneshot 的区别。Type=notify：与Type=simple相同，但规定守护程序在准备就绪时将向 systemd 发送信号。 此通知的参考实现由 libsystemd-daemon.so 提供。Type=dbus：当指定的BusName出现在 DBus 的系统总线上时，服务被认为是准备就绪的。Type=idle：systemd 将延迟服务二进制文件的执行，直到所有作业都已分派。 除此之外，行为与Type=simple非常相似。
有关 Type 值的更详细说明，请参见 systemd.service(5) § OPTIONS 手册页。
编辑提供的单元
为避免与 pacman 冲突，不应直接编辑软件包提供的单元文件。 有两种安全的方法可以修改单元，而无需触摸原始文件：创建新的单元文件，该文件覆盖原始单元或创建 drop-in 片段，这些片段应用于原始单元之上。 对于这两种方法，您都必须在之后重新加载单元才能应用更改。 这可以通过使用 systemctl edit 编辑单元（这将自动重新加载单元）或通过使用
# systemctl daemon-reload
- 您可以使用 systemd-delta 来查看哪些单元文件已被覆盖或扩展，以及具体更改了什么。
- 使用
systemctl cat unit查看单元文件的内容和所有关联的 drop-in 片段。
替换单元文件
要替换单元文件 /usr/lib/systemd/system/unit，请创建文件 /etc/systemd/system/unit 并重新启用单元以更新符号链接。
或者，运行
# systemctl edit --full unit
这将打开 /etc/systemd/system/unit 在您的编辑器中（如果尚不存在，则复制已安装的版本），并在您完成编辑后自动重新加载它。
Drop-in 文件
要为单元文件 /usr/lib/systemd/system/unit 创建 drop-in 文件，请创建目录 /etc/systemd/system/unit.d/ 并在其中放置 .conf 文件以覆盖或添加新选项。 systemd 将解析这些文件并将其应用于原始单元之上。
最简单的方法是运行
# systemctl edit unit --drop-in=drop_in_name
这将在您的文本编辑器中打开文件 /etc/systemd/system/unit.d/drop_in_name.conf（必要时创建），并在您完成编辑后自动重新加载单元。 省略 --drop-in= 选项将导致 systemd 使用默认文件名 override.conf 。
- 密钥仍必须放在覆盖文件中的相应部分。
- 并非所有密钥都可以使用 drop-in 文件覆盖。 例如，对于更改
Conflicts=，需要替换文件。 - 您可以使用顶级 drop-in 文件来影响所有相同类型的单元。 例如，
/etc/systemd/system/service.d/中的 drop-in 文件会影响所有 .service 单元。 您可以在 #通知有关失败的服务 中看到一个示例
恢复到厂商版本
要恢复对使用 systemctl edit 所做的单元的任何更改，请执行
# systemctl revert unit
示例
例如，如果您只想向单元添加额外的依赖项，则可以创建以下文件
/etc/systemd/system/unit.d/customdependency.conf
[Unit] Requires=new dependency After=new dependency
作为另一个示例，为了替换 ExecStart 指令，请创建以下文件
/etc/systemd/system/unit.d/customexec.conf
[Service] ExecStart= ExecStart=new command
请注意， ExecStart 必须在重新分配之前清除 [2]。 对于可以多次指定的每个项目，例如定时器的 OnCalendar，也是如此。
自动重启服务的另一个示例
/etc/systemd/system/unit.d/restart.conf
[Service] Restart=always RestartSec=30
服务日志级别
对于直接将日志发送到 journald 或 syslog 的服务，您可以使用上述方法通过在 [Service] 部分中为 LogLevelMax= 参数设置介于 0 和 6 之间的数值来控制其详细程度。 例如
/etc/systemd/system/unit.d/override.conf
[Service] LogLevelMax=3
标准日志级别与用于过滤 Journal 的级别相同。 设置较低的数字会将所有更高和不太重要的日志消息从您的日志中排除。
抑制服务的标准输出
如果服务正在回显 stdout 和/或 stderr 输出，则默认情况下，这也会最终出现在日志中。 可以通过在 [Service] 部分中设置 StandardOutput=null 和/或 StandardError=null 来抑制此行为。 可以使用除 null 以外的其他值来进一步调整此行为。 请参见 systemd.exec(5) § LOGGING_AND_STANDARD_INPUT/OUTPUT。
目标
systemd 使用目标通过依赖关系将单元组合在一起，并作为标准化的同步点。 它们的作用类似于运行级别，但行为略有不同。 每个目标都已命名而不是编号，旨在服务于特定目的，并且可以同时激活多个目标。 某些目标通过继承另一个目标的所有服务并向其添加其他服务来实现。 有一些 systemd 目标模仿常见的 SystemVinit 运行级别。
获取当前目标
在 systemd 下，应使用以下命令代替运行 runlevel
$ systemctl list-units --type=target
创建自定义目标
在 sysvinit 下具有明确含义的运行级别（即 0、1、3、5 和 6）； 与特定的 systemd 目标具有 1:1 的映射。 遗憾的是，对于用户定义的运行级别（如 2 和 4），没有好的方法可以做到这一点。 如果您使用这些运行级别，建议您创建一个新的命名 systemd 目标，如 /etc/systemd/system/your target，它以现有运行级别之一作为基础（您可以查看 /usr/lib/systemd/system/graphical.target 作为示例），创建一个目录 /etc/systemd/system/your target.wants，然后从 /usr/lib/systemd/system/ 链接您希望启用的其他服务。
SysV 运行级别和 systemd 目标之间的映射
| SysV 运行级别 | systemd 目标 | 注释 |
|---|---|---|
| 0 | poweroff.target | 停止系统。 |
| 1、s、single | rescue.target | 单用户模式。 |
| 2, 4 | multi-user.target | 用户定义/站点特定运行级别。 默认情况下，与级别 3 相同。 |
| 3 | multi-user.target | 多用户，非图形界面。用户通常可以通过多个控制台或网络登录。 |
| 5 | graphical.target | 多用户，图形界面。通常具有 runlevel 3 的所有服务以及图形登录界面。 |
| 6 | reboot.target | 重启 |
| emergency | emergency.target | 紧急 Shell |
更改当前 target
在 systemd 中，target 通过 target units 公开。你可以像这样更改它们
# systemctl isolate graphical.target
这只会更改当前的 target，对下次启动没有影响。这相当于 Sysvinit 中的 telinit 3 或 telinit 5 等命令。
更改默认启动 target
标准 target 是 default.target，它是 graphical.target 的符号链接。这大致对应于旧的 runlevel 5。
使用 systemctl 验证当前 target
$ systemctl get-default
要更改默认启动 target，请更改 default.target 符号链接。使用 systemctl
# systemctl set-default multi-user.target
Removed /etc/systemd/system/default.target. Created symlink /etc/systemd/system/default.target -> /usr/lib/systemd/system/multi-user.target.
或者，将以下 内核参数 之一附加到你的引导加载程序
systemd.unit=multi-user.target（大致对应于旧的 runlevel 3），systemd.unit=rescue.target（大致对应于旧的 runlevel 1）。
默认 target 顺序
systemd 按照以下顺序选择 default.target
- 上面显示的内核参数
/etc/systemd/system/default.target的符号链接/usr/lib/systemd/system/default.target的符号链接
systemd 组件
systemd 的一些（非详尽）组件包括
- kernel-install — 用于自动将 内核 及其各自的 initramfs 镜像移动到启动分区；
- systemd-analyze(1) — 可用于确定启动性能、统计信息和检索其他状态和跟踪信息，并验证单元文件的正确性。它也用于访问对高级调试有用的特殊功能。
- systemd-boot — 简单的 UEFI 启动管理器；
- systemd-creds — 用于安全地存储和检索 systemd 单元使用的凭据；
- systemd-cryptenroll — 将 PKCS#11、FIDO2、TPM2 令牌/设备注册到 LUKS2 加密卷；
- systemd-firstboot — 首次启动前的基本系统设置初始化；
- systemd-homed — 便携式人类用户 帐户；
- systemd-logind(8) — 会话管理；
- systemd-networkd — 网络配置 管理；
- systemd-nspawn — 轻量级命名空间容器；
- systemd-repart — 创建分区表，添加或扩展分区；
- systemd-resolved — 网络 域名解析；
- systemd-run(1) / run0(1) — 临时和交互式地获取提升的或不同的权限。
- systemd-stub(7) — 用于创建 统一内核镜像 的 UEFI 启动存根；
- systemd-sysusers(8) — 在软件包安装或启动时创建系统用户和组，并将用户添加到组；
- systemd-timesyncd — 跨网络的 系统时间 同步；
- systemd/Journal — 系统日志记录；
- systemd/Timers — 用于控制 .service 文件或事件的单调或实时定时器，是 cron 的合理替代品。
systemd.mount - 挂载
systemd 负责挂载 /etc/fstab 中指定的分区和文件系统。systemd-fstab-generator(8) 将 /etc/fstab 中的所有条目转换为 systemd 单元；这在启动时以及系统管理器配置重新加载时执行。
systemd 扩展了常用的 fstab 功能，并提供了额外的挂载选项。这些选项影响挂载单元的依赖关系。例如，它们可以确保仅在网络启动后或仅在另一个分区挂载后才执行挂载。特定的 systemd 挂载选项的完整列表，通常以 x-systemd. 为前缀，在 systemd.mount(5) § FSTAB 中详细说明。
这些挂载选项的一个示例是自动挂载，这意味着仅在需要资源时才挂载，而不是在启动时自动挂载。这在 fstab#使用 systemd 自动挂载 中提供。
GPT 分区自动挂载
在 UEFI 启动的系统上，GPT 分区（如 root、home、swap 等）可以按照 可发现分区规范 自动挂载。因此，这些分区可以从 fstab 中省略，如果 root 分区是自动挂载的，则可以从内核命令行中省略 root=。请参阅 systemd-gpt-auto-generator(8)。
先决条件是
- 当使用 mkinitcpio 时，需要 systemd hook。
- 所有自动挂载的分区必须与 ESP 位于同一物理磁盘上。
- 必须设置正确的 GPT 分区类型。请参阅 分区#分区方案。
- 引导加载程序必须设置 LoaderDevicePartUUID EFI 变量，以便可以识别使用的 EFI 系统分区。 systemd-boot、systemd-stub(7)、GRUB（使用 grub-mkconfig 生成的
grub.cfg；自定义grub.cfg需要 加载 bli 模块）和 rEFInd (默认未启用) 支持此功能。可以通过运行bootctl并检查Boot loader sets ESP information的状态或通过 统一内核镜像 启动时Stub sets ESP information的状态来验证这一点。
udev 将创建一个指向 root 卷块设备的 /dev/gpt-auto-root 符号链接。如果 root 分区使用 LUKS 加密，则 /dev/gpt-auto-root 将指向解锁/映射的卷，而 /dev/gpt-auto-root-luks 指向加密分区。
/var
为了使 /var 自动挂载工作，PARTUUID 必须与由机器 ID 键控的分区类型 UUID 的 SHA256 HMAC 哈希匹配。所需的 PARTUUID 可以使用以下命令获得
$ systemd-id128 -u var-partition-uuid
/etc/machine-id 读取机器 ID，这使得在系统安装之前不可能知道所需的 PARTUUID。systemd-sysvcompat
systemd-sysvcompat（base 需要）的主要作用是提供传统的 Linux init 二进制文件。对于 systemd 控制的系统，init 只是其 systemd 可执行文件的符号链接。
此外，它还提供了 SysVinit 用户可能习惯的四个便捷快捷方式。便捷快捷方式是 halt(8)、poweroff(8)、reboot(8) 和 shutdown(8)。这四个命令中的每一个都是 systemctl 的符号链接，并受 systemd 行为的约束。因此，#电源管理 中的讨论适用。
基于 systemd 的系统可以通过使用 init= 引导参数（例如，参见 /bin/init is in systemd-sysvcompat ?）和 systemd 原生 systemctl 命令参数来放弃这些 System V 兼容性方法。
systemd-tmpfiles - 临时文件
systemd-tmpfiles 创建、删除和清理易失性和临时文件和目录。它读取 /etc/tmpfiles.d/ 和 /usr/lib/tmpfiles.d/ 中的配置文件，以发现要执行的操作。前一个目录中的配置文件优先于后一个目录中的配置文件。
配置文件通常与服务文件一起提供，它们的命名风格为 /usr/lib/tmpfiles.d/program.conf。例如，Samba 守护程序期望目录 /run/samba 存在并具有正确的权限。因此，samba 软件包附带此配置
/usr/lib/tmpfiles.d/samba.conf
D /run/samba 0755 root root
配置文件也可以用于在启动时将值写入某些文件。例如，如果你使用 /etc/rc.local 通过 echo USBE > /proc/acpi/wakeup 禁用从 USB 设备唤醒，你可以使用以下 tmpfile 代替
/etc/tmpfiles.d/disable-usb-wake.conf
# Path Mode UID GID Age Argument w /proc/acpi/wakeup - - - - USBE
可以向同一文件写入多行，可以使用参数中的 \n，也可以在多行（包括第一行）上使用 w+ 类型进行追加
/etc/tmpfiles.d/disable-usb-wake.conf
# Path Mode UID GID Age Argument w+ /proc/acpi/wakeup - - - - USBE w+ /proc/acpi/wakeup - - - - LID0
有关详细信息，请参见 systemd-tmpfiles(8) 和 tmpfiles.d(5) 手册页。
/sys 中设置选项，因为 systemd-tmpfiles-setup 服务可能在加载适当的设备模块之前运行。在这种情况下，你可以检查模块是否具有要使用 modinfo module 设置的选项的参数，并使用 /etc/modprobe.d 中的配置文件 设置此选项。否则，你将必须编写一个 udev 规则 以在设备出现时立即设置相应的属性。
Drop-in 配置文件
不应直接编辑软件包提供的配置文件，以避免与 pacman 更新冲突。为此，许多（但不是全部）systemd 软件包提供了一种修改配置的方法，但无需通过创建 drop-in 代码片段来修改原始文件。查看软件包手册以了解是否支持 drop-in 配置文件。
要为单元文件 /etc/systemd/unit.conf 创建 drop-in 配置文件，请创建目录 /etc/systemd/unit.conf.d/ 并在其中放置 .conf 文件以覆盖或添加新选项。systemd 将解析这些文件并将它们应用于原始单元之上。
检查整体配置
$ systemd-analyze cat-config systemd/unit.conf
应用的 drop-in 代码片段文件和内容将在末尾列出。 重启 服务以使更改生效。
技巧和窍门
套接字激活
某些软件包提供 .socket 单元。例如，cups 提供了一个 cups.socket 单元[3]。如果 cups.socket 被 启用（并且 cups.service 保持禁用状态），systemd 不会立即启动 CUPS；它只会监听适当的套接字。然后，每当程序尝试连接到这些 CUPS 套接字之一时，systemd 将启动 cups.service 并将这些端口的控制权透明地移交给 CUPS 进程。
GUI 配置工具
- systemadm — systemd 单元的图形浏览器。它可以显示单元列表，可以按类型过滤。
- SystemdGenie — 基于 KDE 技术的 systemd 管理实用程序。
在网络启动后运行服务
要延迟服务直到网络启动后，请在 .service 文件中包含以下依赖项
/etc/systemd/system/foo.service
[Unit] ... Wants=network-online.target After=network-online.target ...
还必须启用正在使用的 网络管理器 的网络等待服务，以便 network-online.target 正确反映网络状态。
- 如果使用 NetworkManager，则应同时启用
NetworkManager-wait-online.service和NetworkManager.service。使用systemctl is-enabled NetworkManager-wait-online.service检查是否是这种情况。如果未启用，则 重新启用NetworkManager.service。 - 对于 netctl，启用
netctl-wait-online.service（除非你正在使用 netctl-auto；请参阅 FS#75836）。 - 如果使用 systemd-networkd，则应同时启用
systemd-networkd-wait-online.service和systemd-networkd.service。使用systemctl is-enabled systemd-networkd-wait-online.service检查是否是这种情况。如果未启用，则 重新启用systemd-networkd.service。
有关更详细的说明，请参阅 网络配置同步点 中的讨论。
如果服务需要执行 DNS 查询，则还应将其排序在 nss-lookup.target 之后
/etc/systemd/system/foo.service
[Unit] ... Wants=network-online.target After=network-online.target nss-lookup.target ...
请参阅 systemd.special(7) § 特殊被动系统单元。
为了使 nss-lookup.target 生效，它需要一个通过 Wants=nss-lookup.target 拉入它并通过 Before=nss-lookup.target 将自身排序在其之前的服务。通常，这是由本地 DNS 解析器 完成的。
使用以下命令检查哪个活动服务（如果有）正在拉入 nss-lookup.target
$ systemctl list-dependencies --reverse nss-lookup.target
默认启用已安装的单元
Arch Linux 附带 /usr/lib/systemd/system-preset/99-default.preset，其中包含 disable *。这会导致 systemctl preset 默认禁用所有单元，这样，当安装新软件包时，用户必须手动启用该单元。
如果不需要此行为，只需从 /etc/systemd/system-preset/99-default.preset 创建一个到 /dev/null 的符号链接，以覆盖配置文件。这将导致 systemctl preset 启用所有已安装的单元（无论单元类型如何），除非在 systemctl preset 的配置目录之一的另一个文件中指定。用户单元不受影响。有关更多信息，请参见 systemd.preset(5)。
沙盒化应用程序环境
可以创建一个单元文件作为沙盒，以将应用程序及其进程隔离在强化的虚拟环境中。systemd 利用 命名空间、允许/拒绝的 capabilities 列表和 控制组，通过广泛的执行环境配置来容器化进程—systemd.exec(5)。
使用应用程序沙盒增强现有 systemd 单元文件通常需要反复试验测试，并慷慨地使用 strace、stderr 和 journalctl(1) 错误日志记录和输出工具。你可能需要首先搜索上游文档以查找已完成的测试，以作为试验的基础。要获得可能的强化选项的起点，请运行
$ systemd-analyze security unit
一些关于如何使用 systemd 部署沙盒的示例
CapabilityBoundingSet定义了单元允许或拒绝的 capabilities(7) 列表。请参阅 systemd.exec(5) § CAPABILITIES。- 例如，
CAP_SYS_ADMcapability，它应该是 安全沙盒的目标之一：CapabilityBoundingSet=~ CAP_SYS_ADM
- 例如，
通知有关失败的服务
为了通知有关服务失败，需要将 OnFailure= 指令添加到相应的服务文件中，例如使用 drop-in 配置文件。可以使用顶层 drop-in 配置文件将此指令添加到每个服务单元。有关顶层 drop-in 的详细信息，请参见 systemd.unit(5)。
为服务创建顶层 drop-in
/etc/systemd/system/service.d/toplevel-override.conf
[Unit] OnFailure=failure-notification@%n.service
这会将 OnFailure=failure-notification@%n.service 添加到每个服务文件。如果 some_service_unit 失败，将启动 failure-notification@some_service_unit.service 来处理通知传递（或配置为执行的任何任务）。
创建 failure-notification@.service 模板单元
/etc/systemd/system/failure-notification@.service
[Unit] Description=Send a notification about a failed systemd unit [Service] Type=oneshot ExecStart=/path/to/failure-notification.sh %i # runs as a temporary user/group and enables several other security precautions DynamicUser=true
你可以创建 failure-notification.sh 脚本并定义要执行的操作或如何通知。示例包括 发送电子邮件、显示桌面通知、使用 gotify、XMPP 等。%i 将是失败的服务单元的名称，并将作为参数传递给脚本。
为了防止再次反复启动 failure-notification@.service 实例的递归（如果启动失败），请创建一个与顶层 drop-in 同名的空 drop-in 配置文件（空的服务级 drop-in 配置文件优先于顶层 drop-in 并覆盖后者）
# mkdir -p /etc/systemd/system/failure-notification@.service.d # touch /etc/systemd/system/failure-notification@.service.d/toplevel-override.conf
通过电子邮件通知
你可以设置 systemd 在单元失败时发送电子邮件。如果作业输出到 stdout 或 stderr，Cron 会将邮件发送到 MAILTO，但许多作业都设置为仅在出错时输出。首先，你需要两个文件：一个用于发送邮件的可执行文件和一个用于启动可执行文件的 .service 文件。对于此示例，可执行文件只是一个使用 sendmail 的 shell 脚本，它位于提供 smtp-forwarder 的软件包中。
/usr/local/bin/systemd-email
#!/bin/sh /usr/bin/sendmail -t <<ERRMAIL To: $1 From: systemd <root@$HOSTNAME> Subject: $2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 $(systemctl status --full "$2") ERRMAIL
无论你使用什么可执行文件，它都可能应该至少接受两个参数，就像这个 shell 脚本一样：要发送到的地址和要获取其状态的单元文件。我们创建的 .service 将传递这些参数
/etc/systemd/system/status_email_user@.service
[Unit] Description=status email for %i to user [Service] Type=oneshot ExecStart=/usr/local/bin/systemd-email address %i User=nobody Group=systemd-journal
其中 user 是被电子邮件的用户，而 address 是该用户的电子邮件地址。尽管收件人是硬编码的，但要报告的单元文件作为实例参数传递，因此这项服务可以为许多其他单元发送电子邮件。此时，你可以 启动 status_email_user@dbus.service 以验证你是否可以收到电子邮件。
然后只需 编辑 你想要接收电子邮件的服务，并将 OnFailure=status_email_user@%n.service 添加到 [Unit] 部分。%n 将单元的名称传递给模板。
- 如果你根据 sSMTP#安全 设置了 sSMTP 安全性，则用户
nobody将无法访问/etc/ssmtp/ssmtp.conf，并且systemctl start status_email_user@dbus.service命令将失败。一种解决方案是在status_email_user@.service单元中使用root作为用户。 - 如果你尝试在电子邮件脚本中使用
mail -s somelogs address，mail将 fork，并且当 systemd 看到你的脚本退出时，它将杀死 mail 进程。通过执行mail -Ssendwait -s somelogs address使 mail 不 fork。
在关机时自动关闭外部 HDD
故障排除
调查失败的服务
要查找未能启动的 systemd 服务
$ systemctl --state=failed
要找出它们失败的原因，请检查它们的日志输出。有关详细信息，请参见 systemd/Journal#过滤输出。
诊断启动问题
systemd 有几个选项用于诊断启动过程中的问题。有关更通用的说明和在 systemd 接管 启动过程 之前捕获启动消息的选项，请参见 启动调试。另请参阅 systemd 调试文档。
诊断服务
如果某些 systemd 服务行为不端，或者你想获得有关正在发生的事情的更多信息，请将 SYSTEMD_LOG_LEVEL 环境变量 设置为 debug。例如，以调试模式运行 systemd-networkd 守护程序
为服务添加一个 drop-in 文件，添加以下两行
[Service] Environment=SYSTEMD_LOG_LEVEL=debug
或者，等效地，手动设置环境变量
# SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd
然后 重启 systemd-networkd 并使用 -f/--follow 选项监视服务的日志。
关机/重启花费的时间太长
如果关机过程花费的时间很长（或似乎冻结），则很可能是某个服务未退出造成的。systemd 会等待一段时间让每个服务退出，然后再尝试杀死它。要查明你是否受到影响，请参阅 systemd 文档中的 Shutdown completes eventually。
一个常见的问题是关机或挂起过程停滞。要验证是否是这种情况，你可以运行以下任一命令并检查输出
# systemctl poweroff
Failed to power off system via logind: There's already a shutdown or sleep operation in progress
# systemctl list-jobs
JOB UNIT TYPE STATE ... 21593 systemd-suspend.service start running 21592 suspend.target start waiting ..
解决方案 是通过运行以下命令取消这些作业
# systemctl cancel # systemctl stop systemd-suspend.service
然后再次尝试关机或重启。
短暂运行的进程似乎没有记录任何输出
如果以 root 身份运行 journalctl -u foounit 没有显示短暂运行的服务的任何输出，请查看 PID。例如，如果 systemd-modules-load.service 失败，并且 systemctl status systemd-modules-load 显示它以 PID 123 运行，那么你可能能够在日志中看到该 PID 的输出，即以 root 身份运行 journalctl -b _PID=123。日志的元数据字段（例如 _SYSTEMD_UNIT 和 _COMM）是异步收集的，并且依赖于 /proc 目录来获取进程的存在。修复此问题需要修复内核以通过套接字连接提供此数据，类似于 SCM_CREDENTIALS。简而言之，这是一个 bug。请记住，根据 systemd 的设计，立即失败的服务可能不会向日志打印任何内容。
启动时间随时间推移而增加
在使用 systemd-analyze 后，许多用户注意到他们的启动时间与过去相比显着增加。在使用 systemd-analyze blame 后，NetworkManager 被报告为花费异常长的时间启动。
某些用户的问题是由于 /var/log/journal 变得太大。这可能会对性能产生其他影响，例如对于 systemctl status 或 journalctl。因此，解决方案是删除文件夹中的每个文件（理想情况下在某处备份它，至少是临时的），然后按照 Systemd/Journal#日志大小限制 中的描述设置日志文件大小限制。
systemd-tmpfiles-setup.service 启动时启动失败
从 systemd 219 开始，/usr/lib/tmpfiles.d/systemd.conf 为 /var/log/journal 下的目录指定 ACL 属性，因此，需要为日志所在的文件系统启用 ACL 支持。
有关如何为容纳 /var/log/journal 的文件系统启用 ACL 的说明，请参见 访问控制列表#启用 ACL。
禁用远程计算机上的紧急模式
你可能想要禁用远程计算机上的紧急模式，例如，Azure 或 Google Cloud 上托管的虚拟机。这是因为如果触发紧急模式，计算机将被阻止连接到网络。
要禁用它，屏蔽 emergency.service 和 emergency.target。
错误“Unit xxx.service not found”，但服务确实存在
你可能正在尝试将用户单元作为系统单元启动或启用。systemd.unit(5) 指示哪些单元位于何处。默认情况下，systemctl 对系统服务进行操作。
有关更多详细信息，请参见 Systemd/User。