命令行手册

Man » systemd 手册在线 - systemd man 页面的详细在线文档

🌍
systemd,init - systemd 系统和服务管理器

概要

/usr/lib/systemd/systemd [选项...]

init [选项...]

描述

systemd 是 Linux 操作系统的系统和服务管理器。当作为启动时运行的第一个进程(PID 1)时,它充当 init 系统,用于启动和维护用户空间服务。会启动单独的实例以供登录的用户启动他们的服务。

通常,用户不会直接调用 systemd,而是将其安装为 /sbin/init 符号链接,并在早期启动期间启动。用户管理器实例通过 [email protected](5) 服务自动启动。

当作为系统实例运行时,systemd 会解释配置文件 system.conf 和 system.conf.d 目录中的文件;当作为用户实例运行时,systemd 会解释配置文件 user.conf 和 user.conf.d 目录中的文件。有关更多信息,请参见 systemd-system.conf(5)。

systemd 包含各种任务的本机实现,这些任务需要作为启动过程的一部分执行。例如,它设置主机名或配置环回网络设备。它还会设置和挂载各种 API 文件系统,例如 /sys/、/proc/ 和 /dev/。

systemd 还会重置系统时钟,如果它在早期启动期间出现配置不正确的情况。请参见下面的“系统时钟纪元”部分。

请注意,systemd 提供的并非所有接口都受接口可移植性和稳定性承诺[1]的约束。

systemd 的 D-Bus API 在 org.freedesktop.systemd1(5) 和 org.freedesktop.LogControl1(5) 中描述。

在容器或 initrd 环境中调用 systemd 的系统应实现容器接口[2]或 initrd 接口[3]规范。

单元

systemd 提供了不同实体之间的依赖关系系统,这些实体被称为 11 种不同类型的“单元”。单元封装了与系统启动和维护相关的各种对象。大多数单元都在单元配置文件中配置,这些配置文件的语法和基本选项在 systemd.unit(5) 中描述,但有些是从其他配置文件、从系统状态动态地或在运行时以编程方式创建的。单元可以处于多种状态,如下表所述。请注意,各种单元类型可能有许多其他子状态,这些子状态映射到此处描述的通用单元状态。

表 1. 单元 ACTIVE 状态

┌──────────────┬─────────────────────────────────────┐
│ 状态        │ 描述                                  │
├──────────────┼─────────────────────────────────────┤
│ active       │ 已启动,已绑定,已插入,...,具体取决于单元类型。 │
│              │                                       │
├──────────────┼─────────────────────────────────────┤
│ inactive     │ 已停止,已解绑定,已拔出,...,具体取决于单元类型。 │
│              │                                       │
├──────────────┼─────────────────────────────────────┤
│ failed       │ 与 inactive 类似,但单元以某种方式失败(进程在退出时返回错误代码、崩溃、操作超时或在重新启动太多次后)。 │
│              │                                       │
├──────────────┼─────────────────────────────────────┤
│ activating   │ 从 inactive 变为 active。             │
├──────────────┼─────────────────────────────────────┤
│ deactivating │ 从 active 变为 inactive。             │
├──────────────┼─────────────────────────────────────┤
│ maintenance  │ 单元处于 inactive 状态,并且正在进行维护操作。 │
├──────────────┼─────────────────────────────────────┤
│ reloading    │ 单元处于 active 状态,并且正在重新加载其配置。 │
├──────────────┼─────────────────────────────────────┤
│ refreshing   │ 单元处于 active 状态,并且新的挂载正在其命名空间中激活。 │
└──────────────┴─────────────────────────────────────┘

以下是可用的单元类型:

服务单元,用于启动和控制守护进程以及它们所包含的进程。有关详细信息,请参阅 systemd.service(5)。

套接字单元,封装系统中的本地 IPC 或网络套接字,适用于基于套接字的激活。有关套接字单元的详细信息,请参阅 systemd.socket(5),有关基于套接字的激活和其他形式的激活,请参阅 daemon(7)。

    目标单元对于分组单元或在启动过程中提供已知的同步点很有用,请参阅 systemd.target(5)。

    设备单元在 systemd 中公开内核设备,并且可用于实现基于设备的激活。有关详细信息,请参阅 systemd.device(5)。

    挂载单元控制文件系统中的挂载点,有关详细信息,请参阅 systemd.mount(5)。

    自动挂载单元提供自动挂载功能,可按需挂载文件系统以及实现并行启动。请参阅 systemd.automount(5)。

    计时器单元可用于基于计时器触发其他单元的激活。您可以在 systemd.timer(5) 中找到详细信息。

    交换单元与挂载单元非常相似,并且封装了操作系统的内存交换分区或文件。它们在 systemd.swap(5) 中进行了描述。

    路径单元可用于在文件系统对象发生更改或修改时激活其他服务。请参阅 systemd.path(5)。

    切片单元可用于对管理系统进程(如服务和作用域单元)的单元进行分组,以便在层次结构树中进行资源管理。请参阅 systemd.slice(5)。

    作用域单元类似于服务单元,但管理的是外部进程,而不是启动它们。请参阅 systemd.scope(5)。

单元的名称与其配置文件相同。某些单元具有特殊的语义。有关详细列表,请参阅 systemd.special(7)。

    systemd 知道各种类型的依赖关系,包括正向和负向需求依赖关系(即 Requires= 和 Conflicts=)以及排序依赖关系(After= 和 Before=)。注意:排序依赖关系和需求依赖关系是正交的。如果两个单元之间仅存在需求依赖关系(例如,foo.service 需要 bar.service),但没有排序依赖关系(例如,foo.service 在 bar.service 之后),并且两者都请求启动,它们将并行启动。通常的做法是在两个单元之间同时放置需求依赖关系和排序依赖关系。另请注意,大多数依赖关系都是由 systemd 隐式创建和维护的。在大多数情况下,无需手动声明其他依赖关系,但这是可以的。

应用程序和单元(通过依赖关系)可以请求单元的状态更改。在 systemd 中,这些请求被封装为“作业”并保存在作业队列中。作业可以成功或失败,它们的执行顺序基于它们被安排的单元的排序依赖关系。

在启动时,systemd 激活目标单元 default.target,其任务是通过依赖关系来激活启动服务和其他启动单元。通常,该单元名称只是指向以下单元的别名(符号链接):graphical.target(用于完全启动到 UI)或 multi-user.target(用于有限的控制台启动,用于嵌入式或服务器环境,或类似情况;它是 graphical.target 的子集)。但是,管理员可以根据需要将其配置为指向任何其他目标单元的别名。有关这些目标单元的详细信息,请参阅 systemd.special(7)。

首次启动时,systemd 将根据预设策略启用或禁用单元。请参阅 systemd.preset(5) 和 machine-id(5) 中的“首次启动语义”。

systemd 仅将少量单元加载到内存中。具体来说,只有满足以下条件之一的单元才会保留在内存中:

    它处于活动、激活、停用或失败状态(即,处于除“非活动”以外的任何单元状态)。

    它有已排队的作业。

    它是至少一个已加载到内存中的其他单元的依赖项。

    它仍然分配了某种资源(例如,一个非活动的服务单元,但仍然有一个忽略终止请求的进程)。

    它已通过 D-Bus 调用以编程方式固定在内存中。

systemd 将自动且隐式地从磁盘加载单元(如果它们尚未加载),只要对其执行操作时就会这样做。因此,在许多方面,单元是否已加载对客户端来说是不可见的。使用 systemctl list-units --all 可以全面列出当前加载的所有单元。如果某个单元不满足上述任何条件,则会立即从内存中卸载。请注意,当单元从内存中卸载时,其会计数据也会被清除。但是,这些数据通常不会丢失,因为会在单元关闭时生成一个日志记录,声明消耗的资源。

systemd 启动的进程被放置在私有 systemd 层次结构中,其 Linux 控制组以它们所属的单元命名。(有关控制组的更多信息,请参阅 Control Groups v2[4],或简称“cgroups”)。systemd 使用它来有效地跟踪进程。控制组信息保存在内核中,可以通过文件系统层次结构(位于 /sys/fs/cgroup/ 下)或通过诸如 systemd-cgls(1) 或 ps(1)(ps xawf -eo pid,user,cgroup,args 对于列出所有进程及其所属的 systemd 单元特别有用)之类的工具进行访问。

systemd 与各种已建立的 Unix 功能兼容,例如 /etc/fstab 或 utmp 数据库。

systemd 具有一个最小的事务系统:如果请求启动或关闭一个单元,它会将该单元及其所有依赖项添加到临时事务中。然后,它将验证事务是否一致(即,所有单元的顺序是否没有循环)。如果事务不一致,systemd 将尝试修复它,并删除可能消除循环的非必要作业。此外,systemd 还会尝试抑制事务中可能停止正在运行的服务中的非必要作业。最后,它会检查事务中的作业是否与已排队的作业相矛盾,并可以选择性地中止事务。如果一切顺利,并且事务一致且对其影响最小化,则将其与所有已排队的作业合并,并添加到运行队列中。实际上,这意味着在执行请求的操作之前,systemd 会验证该操作是否合理,如果可能的话进行修复,并且只有在它真的无法执行时才会失败。


请注意,事务的生成与单元在运行时状态无关,因此,例如,如果在已经启动的单元上请求启动作业,它仍然会生成一个事务并唤醒任何非活动依赖项(并根据定义的关联关系触发其他作业的传播)。这是因为排队的作业在执行时与目标单元的状态进行比较,并在两者都满足时标记为成功和完成。但是,此作业还会引入其他依赖项,因为存在定义的关联关系,因此,在我们的示例中,任何这些非活动单元的启动作业也会被排队。

单元可以在启动时和系统管理器重新加载时动态生成,例如,基于其他配置文件或传递到内核命令行中的参数。有关详细信息,请参阅 systemd.generator(7)。

目录

系统单元目录 systemd 系统管理器从各种目录读取单元配置文件。希望安装单元文件的软件包应将其放置在 pkg-config systemd --variable=systemdsystemunitdir 返回的目录中。还会检查其他目录,即 /usr/local/lib/systemd/system 和 /usr/lib/systemd/system。用户配置始终优先。pkg-config systemd --variable=systemdsystemconfdir 返回系统配置目录的路径。软件包应仅使用 systemctl(1) 工具的 enable 和 disable 命令来更改这些目录的内容。完整的目录列表在 systemd.unit(5) 中提供。

用户单元目录 类似的规则适用于用户单元目录。但是,此处遵循 XDG 基础目录规范[5] 来查找单元。应用程序应将其单元文件放置在 pkg-config systemd --variable=systemduserunitdir 返回的目录中。全局配置在 pkg-config systemd --variable=systemduserconfdir 报告的目录中完成。systemctl(1) 工具的 enable 和 disable 命令可以处理全局(即,适用于所有用户)和私有(适用于单个用户)的单元启用/禁用。完整的目录列表在 systemd.unit(5) 中提供。

信号

该服务侦听各种 UNIX 进程信号,这些信号可用于异步请求各种操作。信号处理在启动期间很早启用,在调用任何其他进程之前。但是,打算通过此机制请求这些操作的监督容器管理器或其他类似管理器必须考虑到,在此最早的初始化阶段,此功能不可用。一旦启用信号处理程序,就会发出带有 X_SYSTEMD_SIGNALS_LEVEL=2 字段的 sd_notify() 通知消息,请参见下文。这可用于正确安排这些信号的提交。


SIGTERM
收到此信号后,systemd 系统管理器会序列化其状态,重新执行自身,然后再次反序列化保存的状态。这在很大程度上等同于 `systemctl daemon-reexec`。

systemd 用户管理器在收到此信号时,会启动 `exit.target` 单元。这在很大程度上等同于 `systemctl --user start exit.target --job-mode=replace-irreversibly`。

SIGINT
收到此信号后,systemd 系统管理器会启动 `ctrl-alt-del.target` 单元。这在很大程度上等同于 `systemctl start ctrl-alt-del.target --job-mode=replace-irreversibly`。如果此信号在 2 秒内收到超过 7 次,则会立即触发重新启动。请注意,按下控制台上的 Ctrl+Alt+Del 会触发此信号。因此,如果重新启动卡住,在 2 秒内按下 Ctrl+Alt+Del 多于 7 次是一种相对安全的方法来触发立即重新启动。

systemd 用户管理器对 SIGTERM 和 SIGINT 信号的处理方式相同。

SIGWINCH
收到此信号后,systemd 系统管理器会启动 `kbrequest.target` 单元。这在很大程度上等同于 `systemctl start kbrequest.target`。

此信号被 systemd 用户管理器忽略。

SIGPWR
收到此信号后,systemd 管理器会启动 `sigpwr.target` 单元。这在很大程度上等同于 `systemctl start sigpwr.target`。

SIGUSR1
收到此信号后,systemd 管理器会尝试重新连接到 D-Bus 总线。

SIGUSR2
收到此信号后,systemd 管理器会以人类可读的形式记录其完整状态。记录的数据与 `systemd-analyze dump` 打印的数据相同。

SIGHUP
重新加载完整的守护程序配置。这在很大程度上等同于 `systemctl daemon-reload`。

SIGRTMIN+0
进入默认模式,启动 `default.target` 单元。这在很大程度上等同于 `systemctl isolate default.target`。

SIGRTMIN+1
进入救援模式,启动 `rescue.target` 单元。这在很大程度上等同于 `systemctl isolate rescue.target`。

SIGRTMIN+2
进入紧急模式,启动 `emergency.service` 单元。这在很大程度上等同于 `systemctl isolate emergency.service`。

SIGRTMIN+3
停止机器,启动 `halt.target` 单元。这在很大程度上等同于 `systemctl start halt.target --job-mode=replace-irreversibly`。

SIGRTMIN+4
关闭机器,启动 `poweroff.target` 单元。这在很大程度上等同于 `systemctl start poweroff.target --job-mode=replace-irreversibly`。

SIGRTMIN+5
重新启动机器,启动 `reboot.target` 单元。这在很大程度上等同于 `systemctl start reboot.target --job-mode=replace-irreversibly`。

SIGRTMIN+6
通过 kexec 重新启动机器,启动 `kexec.target` 单元。这在很大程度上等同于 `systemctl start kexec.target --job-mode=replace-irreversibly`。

SIGRTMIN+7

重启用户空间,启动 soft-reboot.target 单元。 这基本上等同于 systemctl start soft-reboot.target --job-mode=replace-irreversibly

新增于版本 254。

SIGRTMIN+13

立即停止机器。

SIGRTMIN+14

立即关闭机器。

SIGRTMIN+15

立即重启机器。

SIGRTMIN+16

立即使用 kexec 重启机器。

SIGRTMIN+17

立即重启用户空间。

新增于版本 254。

SIGRTMIN+20

启用控制台上的状态消息显示,由 systemd.show_status=1 内核命令行控制。

您可以使用 SetShowStatus() 代替 SIGRTMIN+20,以防止出现竞态条件。 请参阅 org.freedesktop.systemd1(5)

SIGRTMIN+21

禁用控制台上的状态消息显示,由 systemd.show_status=0 内核命令行控制。

您可以使用 SetShowStatus() 代替 SIGRTMIN+21,以防止出现竞态条件。 请参阅 org.freedesktop.systemd1(5)

SIGRTMIN+22

将服务管理器的日志级别设置为“debug”,其方式等同于在内核命令行中使用 systemd.log_level=debug

SIGRTMIN+23

将日志级别恢复为其配置值。 配置值按优先级顺序确定:首先是使用 systemd.log-level= 在内核命令行中指定的值,然后是使用 LogLevel= 在配置文件中指定的值,最后是内置的默认值“info”。

新增于版本 239。

SIGRTMIN+24

立即退出管理器(仅适用于 --user 实例)。

新增于版本 195。

SIGRTMIN+25

收到此信号后,systemd 管理器将重新执行自身。 这基本上等同于 systemctl daemon-reexec,但它是异步完成的。

systemd 系统管理器以与 SIGTERM 相同的方式处理此信号。

新增于版本 250。

SIGRTMIN+26

将日志目标恢复为其配置值。 配置值按优先级顺序确定:首先是使用 systemd.log-target= 在内核命令行中指定的值,然后是使用 LogTarget= 在配置文件中指定的值,最后是内置的默认值。

新增于版本 239。

SIGRTMIN+27, SIGRTMIN+28

将日志目标设置为“console”(对于 SIGRTMIN+27)或“kmsg”(对于 SIGRTMIN+28),其方式等同于在内核命令行中使用 systemd.log_target=console(或 systemd.log_target=kmsg 对于 SIGRTMIN+28)。

新增于版本 239。

环境

系统管理器的环境块最初由内核设置。(特别是,内核命令行中的“key=value”赋值会转换为 PID 1 的环境变量。对于用户管理器,系统管理器如 systemd.exec(5) 中的“在生成的进程中的环境变量”部分中所述设置环境。 DefaultEnvironment= 设置应用于系统管理器中的所有服务,包括 [email protected]。 还可以通过 [email protected]Environment=EnvironmentFile= 设置(请参阅 systemd.exec(5))配置额外的条目。 此外,还可以通过 systemd-system.conf(5)systemd-user.conf(5) 中的 ManagerEnvironment= 设置来设置额外的环境变量。


systemd 理解的一些变量:

$SYSTEMD_LOG_LEVEL
发出的消息的最大日志级别(具有更高日志级别(即不太重要的级别)的消息将被抑制)。 接受逗号分隔的值列表。 一个值可以是以下值之一(按重要性递减的顺序排列):emerg、alert、crit、err、warning、notice、info、debug,或者在 0 到 7 之间的整数。 有关更多信息,请参见 syslog(3)。 每个值都可以选择性地以 console、syslog、kmsg 或 journal 开头,后跟一个冒号,以设置特定日志目标的最高日志级别(例如,SYSTEMD_LOG_LEVEL=debug,console:info 指定将以调试级别记录日志,但当记录到控制台时,应以信息级别记录)。 请注意,全局最大日志级别优先于任何每个目标的最高日志级别。

可以使用 --log-level= 进行覆盖。

$SYSTEMD_LOG_COLOR
一个布尔值。 如果为 true,则写入 tty 的消息将根据优先级进行颜色编码。

可以使用 --log-color= 进行覆盖。

$SYSTEMD_LOG_TIME
一个布尔值。 如果为 true,则控制台日志消息将以时间戳为前缀。

可以使用 --log-time= 进行覆盖。

自 246 版本添加。

$SYSTEMD_LOG_LOCATION
一个布尔值。 如果为 true,则消息将以文件名和源代码中消息的行号为前缀。

可以使用 --log-location= 进行覆盖。

$SYSTEMD_LOG_TID
一个布尔值。 如果为 true,则消息将以当前数值线程 ID(TID)为前缀。

自 247 版本添加。

$SYSTEMD_LOG_TARGET
日志消息的目标。 可能是 console(记录到附加的 tty)、console-prefixed(记录到附加的 tty,但带有编码日志级别和“设施”的前缀,请参见 syslog(3))、kmsg(记录到内核循环日志缓冲区)、journal(记录到 journal)、journal-or-kmsg(如果可用,则记录到 journal,否则记录到 kmsg)、auto(自动确定适当的日志目标,默认值)或 null(禁用日志输出)。

可以使用 --log-target= 进行覆盖。

$SYSTEMD_LOG_RATELIMIT_KMSG
是否对 kmsg 进行速率限制。 接受一个布尔值。 默认为“true”。 如果禁用,systemd 将不会对写入 kmsg 的消息进行速率限制。

自 254 版本添加。

$XDG_CONFIG_HOME、$XDG_CONFIG_DIRS、$XDG_DATA_HOME、$XDG_DATA_DIRS
systemd 用户管理器根据 XDG 基础目录规范[5]使用这些变量来查找其配置。

$SYSTEMD_UNIT_PATH、$SYSTEMD_GENERATOR_PATH、$SYSTEMD_ENVIRONMENT_GENERATOR_PATH
控制 systemd 查找单元文件和生成器的位置。

这些变量可以包含一个路径列表,用冒号 (":") 分隔。 如果设置了这些变量,并且列表以空组件 ("...") 结尾,则此列表将添加到通常的路径集的前面。 否则,指定的列表将替换通常的路径集。

$SYSTEMD_PAGER, $PAGER
当未提供 `--no-pager` 时,要使用的分页器。如果设置了 `$SYSTEMD_PAGER`,则使用它;否则使用 `$PAGER`。如果 `$SYSTEMD_PAGER` 和 `$PAGER` 都未设置,则会依次尝试一系列已知的分页器实现,包括 [less]({filename}../../less)(1) 和 more(1),直到找到一个。如果未发现任何分页器实现,则不会调用任何分页器。将这些环境变量设置为一个空字符串或值 "cat" 等同于传递 `--no-pager`。

请注意:如果未设置 `$SYSTEMD_PAGERSECURE`,则只能使用 `$SYSTEMD_PAGER` 和 `$PAGER` 来禁用分页器(使用 "cat" 或 ""),否则它们将被忽略。

$SYSTEMD_LESS
覆盖传递给 less 的选项(默认值为 "FRSXMK")。

用户可能希望更改两个特定选项:

    K
    此选项指示分页器在按下 Ctrl+C 时立即退出。要允许 less 本身处理 Ctrl+C 以返回分页器命令提示符,请取消设置此选项。

如果 `$SYSTEMD_LESS` 的值不包含 "K",并且调用的分页器是 less,则 Ctrl+C 将被可执行文件忽略,需要由分页器处理。

    X
    此选项指示分页器不要向终端发送 termcap 初始化和反初始化字符串。默认设置为允许命令输出在分页器退出后仍然显示在终端中。但是,这会阻止某些分页器功能起作用,特别是不能使用鼠标滚动分页输出。

请注意,设置常规的 `$LESS` 环境变量对 systemd 工具的 less 调用没有影响。

请参阅 [less]({filename}../../less)(1) 以获取更多讨论。

$SYSTEMD_LESSCHARSET
覆盖传递给 less 的字符集(默认值为 "utf-8",如果确定调用的终端与 UTF-8 兼容)。

请注意,设置常规的 `$LESSCHARSET` 环境变量对 systemd 工具的 less 调用没有影响。

$SYSTEMD_PAGERSECURE
像 [less]({filename}../../less)(1) 这样常见的分页器命令,除了“分页”,即滚动输出外,还支持打开或写入其他文件以及运行任意 shell 命令。当命令以提升的权限调用时,例如在 [sudo]({filename}../../sudo)(8) 或 pkexec(1) 下,分页器会成为一个安全边界。必须小心使用仅具有严格限制功能的程序作为分页器,并且不允许使用未经授权的交互功能,例如打开或创建新文件或启动子进程。如果分页器支持,可以启用分页器的“安全模式”,如下所述。建议显式启用“安全模式”,或者使用 `--no-pager` 或 `PAGER=cat` 完全禁用分页器,从而允许不受信任的用户以提升的权限执行命令。

此选项接受一个布尔值参数。当设置为 true 时,将启用分页器的“安全模式”。在“安全模式”下,调用分页器时将设置 LESSSECURE=1,指示分页器禁用打开或创建新文件或启动新子进程的命令。目前,只有 less(1) 才知道并实现了“安全模式”。

当设置为 false 时,不会对分页器施加任何限制。将 $SYSTEMD_PAGERSECURE 设置为 0 或不从继承的环境中删除它,可能会允许用户调用任意命令。

当未设置 $SYSTEMD_PAGERSECURE 时,systemd 工具会尝试自动确定是否应启用“安全模式”以及分页器是否支持它。“安全模式”将在以下情况下启用:有效 UID 与登录会话的所有者 UID 不同,请参阅 geteuid(2) 和 sd_pid_get_owner_uid(3),或者在运行 [sudo]({filename}../../sudo)(8) 或类似工具(设置了 $SUDO_UID [6])时。在这种情况下,将设置 SYSTEMD_PAGERSECURE=1,并且不使用不支持“安全模式”的分页器。请注意,此自动检测仅涵盖最常见的特权提升机制,旨在提供便利。建议显式设置 $SYSTEMD_PAGERSECURE 或禁用分页器。

请注意,如果希望使用 $SYSTEMD_PAGER 或 $PAGER 变量(除了禁用分页器之外),则必须同时设置 $SYSTEMD_PAGERSECURE。

$SYSTEMD_COLORS

接受一个布尔值参数。当为 true 时,systemd 及其相关实用程序将在其输出中使用颜色,否则输出将为单色。此外,变量可以采用以下特殊值:“16”、“256”,以将颜色使用限制为基本的 16 种或 256 种 ANSI 颜色。这可以用来覆盖基于 $TERM 以及控制台连接方式所做的自动决策。

$SYSTEMD_URLIFY

该值必须是布尔值。控制是否应为支持此功能的终端模拟器生成输出中的可点击链接。这可以用来覆盖 systemd 基于 $TERM 和其他条件所做的决策。

$LISTEN_PID、$LISTEN_PIDFDID、$LISTEN_FDS、$LISTEN_FDNAMES

由 systemd 为基于套接字的激活期间的受监督进程设置。有关更多信息,请参阅 sd_listen_fds(3)。

$NOTIFY_SOCKET

由服务管理器为其服务设置,用于状态和就绪通知。服务管理器还会将其传递给上层容器管理器或服务管理器,以通知其自身的进度。有关更多信息,请参阅 sd_notify(3) 和下面的相关部分。

有关 systemd 及其各种组件理解的其他环境变量,请参阅已知环境变量[7]。

内核命令行

当作为系统实例运行时,systemd 会解析以下一些选项。它们可以作为内核命令行参数指定,这些参数将从多个来源解析,具体取决于 systemd 运行的环境。如果运行在 Linux 容器内,除了“选项”部分中列出的命令行选项之外,这些选项还将从传递给 systemd 本身的命令行参数中解析。如果运行在 Linux 容器之外,则这些参数将从 /proc/cmdline 中解析。


以下变量将被理解:

systemd.unit=, rd.systemd.unit=
覆盖启动时激活的单元。默认值为 default.target。这可用于临时启动到不同的启动单元,例如 rescue.target 或 emergency.service。
有关这些单元的更多信息,请参阅 systemd.special(7)。带有 "rd." 前缀的选项仅在 initrd 中有效,而不带前缀的选项仅在主系统中有效。

systemd.dump_core
接受一个布尔值参数,或者在指定参数时启用该选项。如果启用,systemd 管理器(PID 1)将在崩溃时生成核心转储。否则,将不会创建核心转储。
默认值为启用。

新增于版本 233。

systemd.crash_chvt
接受一个正整数或一个布尔值参数。也可以在不带参数的情况下指定,效果与正布尔值相同。如果指定一个正整数(范围为 1-63),则系统管理器(PID 1)将在崩溃时激活指定的虚拟终端。默认值为禁用,这意味着不会尝试切换终端。如果设置为启用,则将使用内核消息写入的虚拟终端。

新增于版本 233。

systemd.crash_shell
接受一个布尔值参数,或者在指定参数时启用该选项。如果启用,systemd 管理器(PID 1)将在崩溃时生成一个 shell。否则,不会生成 shell。
默认值为禁用,出于安全原因,因为该 shell 没有受到密码身份验证的保护。

新增于版本 233。

systemd.crash_action=
接受以下值之一:"freeze"、"reboot" 或 "poweroff"。默认值为 "freeze"。如果设置为 "freeze",则系统将在 systemd 管理器(PID 1)崩溃时无限期地挂起。如果设置为 "reboot",systemd 管理器(PID 1)将在 10 秒延迟后自动重新启动机器。如果设置为 "poweroff",systemd 管理器(PID 1)将在崩溃时立即关闭机器。如果与 systemd.crash_shell 结合使用,则配置的崩溃操作将在 shell 退出后执行。

新增于版本 256。

systemd.confirm_spawn
接受一个布尔值参数或指向应发出确认消息的虚拟控制台的路径。也可以在不带参数的情况下指定,效果与正布尔值相同。如果启用,systemd 管理器(PID 1)将在使用 /dev/console 生成进程时询问确认。如果提供路径或控制台名称(例如 "ttyS0"),则将使用指向该路径或由给定名称描述的虚拟控制台。
默认值为禁用。

在版本 233 中添加。

systemd.service_watchdogs=

接受一个布尔值参数。如果禁用,所有服务运行时看门狗(WatchdogSec=)和紧急操作(例如 OnFailure= 或 StartLimitAction=)都将被系统管理器(PID 1)忽略;请参阅 systemd.service(5)。默认启用,即看门狗和故障操作按正常方式处理。硬件看门狗不受此选项的影响。

在版本 237 中添加。

systemd.show_status

接受一个布尔值参数或常量 error 和 auto。也可以在不带参数的情况下指定,效果与正布尔值相同。如果启用,systemd 管理器(PID 1)将在启动期间在控制台上显示简洁的服务状态更新。如果设置为 error,则仅显示有关故障的消息,但启动过程除外,启动过程将保持静默。auto 的行为类似于 false,直到启动过程中出现明显的延迟。默认情况下启用,除非在内核命令行选项中传递了 quiet,在这种情况下,默认设置为 error。如果指定,则会覆盖系统管理器配置文件选项 ShowStatus=,请参阅 systemd-system.conf(5)。

在版本 233 中添加。

systemd.status_unit_format=

接受 name、description 或 combined 作为值。如果设置为 name,系统管理器将在状态消息中使用单元名称。如果设置为 combined,系统管理器将在状态消息中使用单元名称和描述。如果指定,则会覆盖系统管理器配置文件选项 StatusUnitFormat=,请参阅 systemd-system.conf(5)。

在版本 243 中添加。

systemd.log_color、systemd.log_level=、systemd.log_location、systemd.log_target=、
systemd.log_time、systemd.log_tid、systemd.log_ratelimit_kmsg
控制日志输出,效果与上述环境变量 $SYSTEMD_LOG_COLOR、$SYSTEMD_LOG_LEVEL、$SYSTEMD_LOG_LOCATION、$SYSTEMD_LOG_TARGET、$SYSTEMD_LOG_TIME、$SYSTEMD_LOG_TID 和 $SYSTEMD_LOG_RATELIMIT_KMSG 相同。systemd.log_color、systemd.log_location、systemd.log_time、systemd.log_tid 和 systemd.log_ratelimit_kmsg 可以不带参数指定,效果与正布尔值相同。

systemd.default_standard_output=、systemd.default_standard_error=

控制服务和套接字的默认标准输出和错误输出。也就是说,控制 StandardOutput= 和 StandardError= 的默认值(有关详细信息,请参阅 systemd.exec(5))。接受以下值:inherit、null、tty、journal、journal+console、kmsg、kmsg+console。如果省略参数,systemd.default-standard-output= 的默认值为 journal,systemd.default-standard-error= 的默认值为 inherit。

systemd.setenv=

接受形式为 VARIABLE=VALUE 的字符串参数。可用于设置默认环境变量,以便添加到分叉的子进程中。可以多次使用,以设置多个变量。

systemd.machine_id=

接受一个 32 个字符的十六进制值,用于设置 machine-id。主要用于网络引导,以便在每次引导时使用相同的 machine-id。


在版本 229 中添加。

systemd.set_credential=, systemd.set_credential_binary=

设置系统凭据,然后可以使用 ImportCredential=LoadCredential= 设置将其传播到系统服务中,有关详细信息,请参阅 systemd.exec(5)。它接受一个凭据名称和值对,以冒号分隔。systemd.set_credential= 参数期望凭据值以文字形式提供,systemd.set_credential_binary= 参数接受以 Base64 编码的二进制数据。请注意,内核命令行通常可以被未授权程序访问,位于 /proc/cmdline 中。因此,这种机制不适合用于传输敏感数据。仅将其用于非敏感数据(例如公共密钥/证书,而不是私钥),或在测试/调试环境中。

有关更多信息,请参阅 [System and Service Credentials] 文档。

在版本 251 中添加。

systemd.import_credentials=

接受一个布尔值参数。如果为 false,则禁用从内核命令行、DMI/SMBIOS OEM 字符串表、qemu_fw_cfg 子系统或 EFI 内核存根导入凭据。

在版本 251 中添加。

quiet

关闭启动时的状态输出,类似于 systemd.show_status=no。请注意,此选项也由内核本身读取,并禁用内核日志输出。因此,传递此选项会关闭系统管理器和内核的常规输出。

在版本 186 中添加。

debug

启用调试输出。这等效于 systemd.log_level=debug。请注意,此选项也由内核本身读取,并启用内核调试输出。因此,传递此选项会启用系统管理器和内核的调试输出。

在版本 205 中添加。

emergency, rd.emergency, -b

引导进入紧急模式。这等效于 systemd.unit=emergency.targetrd.systemd.unit=emergency.target,分别用于兼容性和更易于输入。

在版本 186 中添加。

rescue, rd.rescue, single, s, S, 1

引导进入救援模式。这等效于 systemd.unit=rescue.targetrd.systemd.unit=rescue.target,分别用于兼容性和更易于输入。

在版本 186 中添加。

2 3, 4, 5

引导到指定的传统 SysV 运行级别。2、3 和 4 等效于 systemd.unit=multi-user.target;5 等效于 systemd.unit=graphical.target,这些都是为了兼容性而提供的,并且更易于输入。

在版本 186 中添加。

locale.LANG=, locale.LANGUAGE=, locale.LC_CTYPE=, locale.LC_NUMERIC=, locale.LC_TIME=,
locale.LC_COLLATE=, locale.LC_MONETARY=, locale.LC_MESSAGES=, locale.LC_PAPER=, locale.LC_NAME=,
locale.LC_ADDRESS=, locale.LC_TELEPHONE=, locale.LC_MEASUREMENT=, locale.LC_IDENTIFICATION=

设置要使用的系统区域设置。这将覆盖 /etc/locale.conf 中的设置。有关更多信息,请参阅 locale.conf(5)locale(7)

在版本 186 中添加。

对于核心操作系统组件理解的其他内核命令行参数,请参阅 kernel-command-line(7)


系统凭据

在初始化期间,服务管理器将从各种来源导入凭据到系统的凭据集中,然后可以将这些凭据传播到服务中,并由生成器使用:

当服务管理器首次初始化时,它将从 SMBIOS Type 11 供应商字符串 io.systemd.credential:name=value 和 io.systemd.credential.binary:name=value 中读取系统凭据。

同时,它还将从 QEMU “fw_cfg” 中导入凭据。(请注意,通常更喜欢 SMBIOS 机制,因为它更快且更通用。)

可以使用内核命令行通过 systemd.set-credential= 参数传递凭据,如上所述。

可以从 UEFI 环境通过 systemd-stub(7) 传递凭据。

当服务管理器在 initrd → 主机转换期间被调用时,它将把 /run/credentials/@initrd/ 中的所有文件作为系统凭据导入。

使用以下命令调用 systemd-creds(1) 以查看传递到系统中的凭据列表:

# systemd-creds --system list

有关更多信息,请参阅 System and Service Credentials[8] 文档。

当作为 PID 1 运行时,服务管理器会使用以下系统凭据:

vmm.notify_socket

包含一个 AF_VSOCK 或 AF_UNIX 地址,用于在服务管理器完成启动后发送 READY=1 通知消息。请参阅 sd_notify(3) 和下一节以获取更多信息。请注意,如果虚拟机管理程序不支持 AF_VSOCK 上的 SOCK_DGRAM,则会尝试使用 SOCK_SEQPACKET。对于 AF_VSOCK,凭据负载应为 "vsock:CID:PORT" 形式的字符串。可以使用 "vsock-stream"、"vsock-dgram" 和 "vsock-seqpacket" 代替 "vsock" 以强制使用相应的套接字类型。

此功能对于虚拟机管理器或其他主机上的进程接收 VM 启动完成后的 VSOCK 通知非常有用。

在版本 254 中添加。

system.machine_id

获取一个 128 位十六进制 ID,以初始化 /etc/machine-id(如果该文件尚未设置)。有关详细信息,请参阅 machine-id(5)。

在版本 254 中添加。

有关 systemd 的各种其他组件使用的系统凭据列表,请参阅 systemd.systemcredentials(7)。

就绪协议

服务管理器实现了一种就绪通知协议,既用于管理器与其服务之间(即向下传递),也用于管理器与可能的上层主管之间(后者可能是虚拟机管理器或容器管理器,或者对于每个用户服务管理器,是系统服务管理器实例)。基本协议(以及建议的 API)在 sd_notify(3) 中描述。

服务管理器(包括 PID 1)用于向其主管报告就绪状态的通知套接字通过通常的 $NOTIFY_SOCKET 环境变量设置(如上所述)。由于只能为容器管理器和用户实例服务管理器直接设置此变量,因此还提供了一种额外的机制来配置它,特别是用于在 VM 环境中使用:vmm.notify_socket 系统凭据(如上所述)可以设置为合适的套接字(通常是 AF_VSOCK),通过 SMBIOS Type 11 供应商字符串。有关详细信息,请参阅上文。


从服务管理器向上传递到主管的通知协议支持许多扩展字段,允许主管了解系统的特定属性并跟踪其启动进度。具体来说,将发送以下字段:

当系统初始主机名确定时,将发送一条 X_SYSTEMD_HOSTNAME=... 消息。请注意,在后续运行时,主机名可能会以编程方式再次更改,并且(目前)在这种情况下不会发送进一步的通知。

添加于版本 256。

当系统的机器 ID 确定时,将发送一条 X_SYSTEMD_MACHINE_ID=... 消息。有关详细信息,请参阅 machine-id(5)。

添加于版本 256。

当服务管理器安装上述各种 UNIX 进程信号处理程序时,将发送一条 X_SYSTEMD_SIGNALS_LEVEL=... 消息。该字段的值是一个格式化的十进制字符串的无符号整数,并指示服务管理器支持的 UNIX 进程信号特征级别。当前,仅定义了一个特征级别:

X_SYSTEMD_SIGNALS_LEVEL=2 涵盖了上述各种 UNIX 进程信号——这些信号是历史 SysV init 系统支持信号的超集。

在发送此消息之前发送到 PID 1 的信号可能无法正确处理。应该解析这些消息的消费者,将其值解析为指示支持级别的无符号整数。现在,仅定义了上述级别 2,但以后可能会定义具有更高整数的附加级别,这些级别将实现当前定义的行为的超集。

添加于版本 256。

对于每个目标单元,当它变为活动状态或停止活动状态时,将发送 X_SYSTEMD_UNIT_ACTIVE=... 和 X_SYSTEMD_UNIT_INACTIVE=... 消息。这对于跟踪启动进度和功能非常有用。例如,一旦报告 ssh-access.target 单元已启动,通常 SSH 访问是可用的,请参阅 systemd.special(7) 以获取详细信息。

添加于版本 256。

在系统关闭之前,将发送一条 X_SYSTEMD_SHUTDOWN=... 消息。该值为以下字符串之一:“reboot”、“halt”、“poweroff”、“kexec”,并指示正在执行哪种类型的关闭。

添加于版本 256。

还将发送一条 X_SYSTEMD_REBOOT_PARAMETER=... 消息,就在系统关闭之前。其值为使用 systemctl --reboot-argument=... 配置的重启参数。

添加于版本 256。

请注意,这些扩展字段除了常规的“READY=1”和“RELOADING=1”通知之外,还会发送。

选项

systemd 很少被直接调用,因为它很早就启动,并且在用户可能与之交互时已经运行。通常,使用诸如 systemctl(1) 之类的工具向管理器发送命令。由于通常不直接调用 systemd,因此下面列出的选项主要用于调试和特殊目的。


内省和调试选项

这些选项用于测试和内省,并且 systemd 可以在任何时候使用它们进行调用:

--dump-configuration-items

转储已理解的单元配置项。这将输出一个简洁但完整的单元定义文件中所理解的配置项列表。

--dump-bus-properties

转储公开的 D-Bus 属性。这将输出一个简洁但完整的公开在 D-Bus 上的属性列表。

添加于版本 239。

--test

确定初始启动事务(即在启动时排队的作业列表),转储它并退出——而不实际执行任何确定的作业。此选项仅用于调试。请注意,在常规服务管理器启动期间,可能会启动其他未在此操作中显示的单元,因为硬件、套接字、总线或其他类型的激活可能会在事务执行时添加额外的作业。使用 --system 请求系统服务管理器的初始事务(这也是默认设置),并结合 --user 请求每个用户服务管理器的初始事务。

--system、--user

与 --test 结合使用时,选择是计算系统实例的初始事务还是每个用户实例的初始事务。在没有 --test 的情况下调用时,这些选项无效,因为在常规(即非 --test)调用期间,服务管理器将自动检测它是否应以系统模式或每个用户模式运行,方法是检查它运行的 PID 是否为 1。请注意,不支持以系统模式运行服务管理器,但 PID 不为 1。

-h、--help

打印简短的帮助文本并退出。

--version

打印简短的版本字符串并退出。

与内核命令行设置重复的选项

这些选项直接对应于上面“内核命令行”中列出的选项。两种形式都可以等效地用于系统管理器,但建议在此上下文中使用上面列出的形式,因为它们被正确地命名了。如果在内核命令行和作为普通命令行参数中指定了某个选项,则后者具有更高的优先级。

当 systemd 用作用户管理器时,将忽略内核命令行,并且仅理解以下选项。但是,systemd 通常以 [email protected](5) 服务形式启动,该服务在所有用户之间共享。使用配置文件来修改设置(请参阅 systemd-user.conf(5))或环境变量可能更方便。请参阅上面的“环境”部分,了解有关如何设置环境块的讨论。


--unit=
设置启动时要激活的默认单元。如果未指定,则默认为 default.target。请参阅 systemd.unit=。

--dump-core
启用崩溃时生成核心转储。此选项在作为用户实例运行时无效。与 systemd.dump_core= 相同。

--crash-vt=VT
崩溃时切换到特定的虚拟控制台 (VT)。此选项在作为用户实例运行时无效。与 systemd.crash_chvt= 相同(但拼写不同!)。

自版本 227 起添加。

--crash-shell
崩溃时运行 shell。此选项在作为用户实例运行时无效。请参阅 systemd.crash_shell=。

--crash-action=
指定系统管理器(PID 1)崩溃时要执行的操作。此选项在 systemd 作为用户实例运行时无效。请参阅 systemd.crash_action=。

自版本 256 起添加。

--confirm-spawn
在生成进程时请求确认。此选项在作为用户实例运行时无效。请参阅 systemd.confirm_spawn。

--show-status
在启动和关闭期间在控制台上显示简洁的单元状态信息。请参阅 systemd.show_status。

自版本 244 起添加。

--log-color
突出显示重要的日志消息。请参阅 systemd.log\_color。

自版本 244 起添加。

--log-level=
设置日志级别。请参阅 systemd.log\_level。

--log-location
在日志消息中包含代码位置。请参阅 systemd.log\_location。

自版本 244 起添加。

--log-target=
设置日志目标。请参阅 systemd.log\_target。

--log-time=
在控制台消息前附加时间戳。请参阅 systemd.log\_time。

自版本 246 起添加。

--machine-id=
覆盖硬盘上设置的 machine-id。请参阅 systemd.machine\_id=。

自版本 229 起添加。

--service-watchdogs
全局启用/禁用所有服务看门狗超时和应急操作。请参阅 systemd.service_watchdogs。

自版本 237 起添加。

--default-standard-output=, --default-standard-error=
分别为所有服务和套接字设置默认输出或错误输出。请参阅 systemd.default_standard_output= 和 systemd.default_standard_error=。

系统时钟纪元

当 systemd 启动或重新启动时,它可能会将系统时钟设置为“纪元”。此机制用于确保系统时钟在重新启动后保持相对合理的初始化状态,并且大致单调,以防没有电池供电的本地 RTC,或者它无法正常工作。

纪元是系统时钟时间被假定设置正确的最低日期。在初始化期间,如果本地时钟设置为较低的值,则会将其前进到纪元。作为一种特殊情况,如果本地时钟在未来很长一段时间(默认情况下为 15 年,但这可以在构建时配置),则假定硬件时钟已损坏,并且系统时钟会回退到纪元。

纪元设置为以下各项中的最大值:systemd 的构建时间、/usr/lib/clock-epoch 的修改时间(“mtime”)以及 /var/lib/systemd/timesync/clock 的修改时间。


文件

/run/systemd/notify

守护进程状态通知套接字。这是一个 AF_UNIX 数据报套接字,用于实现由 sd_notify(3) 实现的守护进程通知逻辑。

/run/systemd/private

用作 systemctl(1) 和 systemd 进程之间的内部通信通道。这是一个 AF_UNIX 流套接字。此接口为 systemd 专用,不应在外部项目中使用。

/usr/lib/clock-epoch

此文件的修改时间(“mtime”)用于时间历元,请参见上一节。

于版本 247 中添加。

/var/lib/systemd/timesync/clock

此文件的修改时间(“mtime”)由 systemd-timesyncd.service(8) 更新。如果存在,则使用该文件的修改时间作为历元,请参见上一节。

于版本 257 中添加。

历史记录

systemd 252

内核命令行参数 systemd.unified_cgroup_hierarchy 和 systemd.legacy_systemd_cgroup_controller 已被弃用。请切换到统一的 cgroup 层次结构。

参见

systemd 官方网站[9],systemd-system.conf(5),locale.conf(5),systemctl(1),journalctl(1),systemd-notify(1),daemon(7),sd-daemon(3),org.freedesktop.systemd1(5),systemd.unit(5),systemd.special(7),pkg-config(1),kernel-command-line(7),bootup(7),systemd.directives(7),org.freedesktop.systemd1(5)

有关 systemd 背后的概念和想法的更多信息,请参阅原始设计文档[10]。

注意事项

    接口可移植性和稳定性承诺
https://systemd.io/PORTABILITY_AND_STABILITY/

    容器接口
https://systemd.io/CONTAINER_INTERFACE

initrd 接口
https://systemd.io/INITRD_INTERFACE/

    Control Groups v2
https://docs.kernel.org/admin-guide/cgroup-v2.html

XDG 基础目录规范
https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

    建议其他工具根据需要设置和检查 $SUDO\_UID,将其视为一个通用接口。

    已知环境变量
https://systemd.io/ENVIRONMENT

    系统和服务的凭据
https://systemd.io/CREDENTIALS

systemd 官方网站
https://systemd.io/

    原始设计文档
https://0pointer.de/blog/projects/systemd.html