使用 systemd 单元文件自定义和优化您的系统


Red Hat Enterprise Linux 10

使用 systemd 优化系统性能和扩展配置

Red Hat Customer Content Services

摘要

修改 systemd 单元文件并扩展默认配置,检查系统引导性能并优化 systemd 以缩短引导时间。

对红帽文档提供反馈

我们感谢您对我们文档的反馈。让我们了解如何改进它。

通过 Jira 提交反馈(需要帐户)

  1. 登录到 Jira 网站。
  2. 在顶部导航栏中点 Create
  3. Summary 字段中输入描述性标题。
  4. Description 字段中输入您对改进的建议。包括文档相关部分的链接。
  5. 点对话框底部的 Create

第 1 章 使用 systemd 单元文件

systemd 单元文件代表您的系统资源。作为系统管理员,您可以执行以下高级任务:

  • 创建自定义单元文件
  • 修改现有单元文件
  • 使用实例化单元

1.1. 单元文件简介

单元文件包含描述这个单元并定义其行为的配置指令。几个 systemctl 命令在后台与单元文件一起工作。要进行更精细的调整,您可以手动编辑或创建单元文件。

您可以找到系统上存储单元文件的三个主要目录,/etc/systemd/system/ 目录是为系统管理员创建或自定义的单元文件保留的。

单元文件名的格式如下:

<unit_name>.<type_extension>
Copy to Clipboard

这里的 unit_name 代表单元名称,type_extension 标识单元类型。

例如,您可以找到系统上存在的 sshd.servicesshd.socket 单元。

可通过一个目录来补充单元文件,以了解额外的配置文件。例如,要将自定义配置选项添加到 sshd.service 中,请创建 sshd.service.d/custom.conf 文件,并在其中插入额外的指令:有关配置目录的更多信息,请参阅 修改现有单元文件

systemd 系统和服务管理器也可以创建 sshd.service.wants/sshd.service.requires/ di。这些目录包含到 sshd 服务依赖的单元文件的符号链接。systemd 在安装过程中根据 [Install] 单元文件选项或在运行时根据 [Unit] 选项自动创建符号链接。您还可以手动创建这些目录和符号链接。

另外, sshd.service.wants/sshd.service.requires/ 目录可以被创建。这些目录包含到 sshd 服务依赖的单元文件的符号链接。符号链接会在安装过程中根据 [Install] 单元文件选项自动创建,或者根据 [Unit] 选项在运行时自动创建。也可以手动创建这些目录和符号链接。有关 [Install] 和 [Unit] 选项的详情请参考下表。

许多单元文件可以使用 单元指定符 -通配符字符串来设置,该字符串在载入单元文件时被动态替换为单元参数。这可创建通用单元文件,来用作生成实例化单元的模板。请参阅使用实例化单元

1.2. systemd 单元文件位置

您可以在以下目录中找到单元配置文件:

表 1.1. systemd 单元文件位置
目录描述

/usr/lib/systemd/system/

与安装的 RPM 软件包一起分发的 systemd 单元文件。

/run/systemd/system/

在运行时创建的 systemd 单元文件。该目录优先于安装了的服务单元文件的目录。

/etc/systemd/system/

使用 systemctl enable 命令创建的 systemd 单元文件,以及为扩展服务添加的单元文件。这个目录优先于带有运行时单元文件的目录。

systemd 的默认配置在编译过程中定义,您可以在 /etc/systemd/system.conf 文件中找到配置。通过编辑此文件,您可以通过全局覆盖 systemd 单元的值来修改默认配置。

例如,若要覆盖设为 90 秒的超时限制的默认值,可使用 DefaultTimeoutStartSec 参数输入所需的值(以秒为单位)。

DefaultTimeoutStartSec=required value
Copy to Clipboard

1.3. 单元文件结构

单元文件通常由三个以下部分组成:

[Unit] 部分
包含不依赖于单元类型的通用选项。这些选项提供了单元描述,指定了单元的行为,并设置了其他单元的依赖项。

有关最常用的 [Unit] 选项的列表,请参阅 重要 [单元] 部分选项

[Unit type] 部分
包含特定于类型的指令,这些指令分组在以单元类型命名的部分下。例如,服务单元文件包含 [Service] 部分。
[Install] 部分
包含有关 systemctl enabledisable 命令使用的单元安装的信息。有关 [Install] 部分的选项列表,请参阅 重要 [Install] 部分选项

1.4. 重要 [Unit] 部分选项

下表列出了 [Unit] 部分的重要选项。

表 1.2. 重要 [Unit] 部分选项
选项 [a]描述

描述

单元的有意义的描述。这个文本显示在 systemctl status 命令的输出中。

Documentation

提供单元参考文档的 URI 列表。

After[b]

定义启动单位的顺序。这个单元仅在 After 中指定的单元处于活跃状态后才启动。与 Requires 不同,After 不会显式激活指定的单元。Before 选项与 After 的功能相反。

Requires

配置其它单元上的依赖关系。Requires 中列出的单元与单元一同被激活。如果任何需要的单元无法启动,则该单位就不会被激活。

Wants

配置比 Requires 更弱的依赖项。如果列出的单元没有成功启动,它对单元激活不会有影响。这是建立自定义单元依赖项的建议方法。

Conflicts

配置负的依赖关系,与 Requires 相反。

[a] 有关 [Unit] 部分中可配置的选项的完整列表,请查看 systemd.unit(5) 手册页。
[b] 在大多数情况下,只需要AfterBefore 单元文件选项设置顺序依赖关系就足够了。如果还使用 Wants(推荐)或 Requires设置了需要的依赖关系,仍需要指定依赖关系顺序。这是因为排序和要求依赖关系可以独立地工作。

1.5. 重要 [Service] 部分选项

下表列出了 [Service] 部分的重要选项。

表 1.3. 重要 [Service] 部分选项
选项 [a]描述

Type

配置影响 ExecStart 和相关选项功能的单元进程启动类型。其中之一:

* simple - 默认值。使用 ExecStart 启动的进程是该服务的主要进程。

* forking - 使用 ExecStart 启动的进程会生成成为服务主进程的子进程。父进程在启动完成后会退出。

* oneshot - 这个类型与 simple 类似,但在启动单元前会退出。

* dbus - 这个类型与 simple 类似,但只有主进程获得 D-Bus 名称后才启动该单元。

* notify - 此类型与 simple 类似,但只有在通过 sd_notify ()函数发送通知消息后才启动该单元。

* idle - 与 simple 类似,服务二进制文件的实际执行会延迟到所有作业完成为止,这样可避免将状态输出与服务的 shell 输出混合在一起。

ExecStart

指定在启动该单元时要执行的命令或脚本。ExecStartPreExecStartPost 指定在 ExecStartPtart 之前和之后要执行的自定义命令。Type=oneshot 启用指定可按顺序执行的多个自定义命令。

ExecStop

指定在该单元停止时要执行的命令或脚本。

ExecReload

指定重新载入该单元时要执行的命令或脚本。

Restart

启用此选项后,服务会在进程退出后重启,但使用 systemctl 命令进行的干净停止除外。

RemainAfterExit

如果设置为 True,即使所有进程都退出了,该服务也被视为活动状态。默认为 False。这个选项在配置了 Type=oneshot 时特别有用。

[a] 有关 [Service] 部分中可配置的选项的完整列表,请参阅 systemd.service(5) 手册页。

1.6. 重要 [Install] 部分选项

下表列出了 [Install] 部分的重要选项。

表 1.4. 重要 [Install] 部分选项
选项 [a]描述

Alias

为这个单元提供空格分开的额外名称列表。除 systemctl enable 以外,多数systemctl 命令可使用别名而不是实际的单元名称。

RequiredBy

依赖于这个单元的单元列表。当启用此单元时,在 RequiredBy 中列出的单元会获得对这个单元的一个 Require 依赖项。

WantedBy

依赖于这个单元的单位列表。当启用这个单元时,在 WantedBy 中列出的单元会得到一个 Want 依赖项。

Also

指定要随这个单元一起安装或卸载的单元列表。

DefaultInstance

仅限于实例化单元,这个选项指定启用单位的默认实例。请参阅使用实例化单元

[a] 有关 [Install] 部分中可配置的选项的完整列表,请查看 systemd.unit(5) 手册页。

1.7. 创建自定义单元文件

从头开始创建单元文件有多种用例:您可以运行自定义守护进程,创建某些现有服务的第二个实例 ,如使用 sshd 服务的第二个实例来创建自定义单元文件

另一方面,如果您只想修改或扩展现有单元的行为,请使用 修改现有单元文件 中的说明。

步骤

  1. 要创建自定义服务,请准备具有服务的可执行文件。该文件可以包含自定义创建的脚本,也可以是软件供应商提供的可执行文件。如果需要,准备 PID 文件来保存自定义服务主要进程的恒定 PID。您还可以包含环境文件来存储服务的 shell 变量。确保源脚本是可执行的(通过执行 chmod a+x)且不是交互的。
  2. /etc/systemd/system/ 目录中创建一个单元文件,并确定它有正确的文件权限。以 root 用户身份执行:

    # touch /etc/systemd/system/<name>.service
    
    # chmod 664 /etc/systemd/system/<name>.service
    Copy to Clipboard

    将 &lt;name> 替换为您要创建的服务的名称。请注意,该文件不需要是可执行的。

  3. 打开创建的 <name>.service 文件,并添加服务配置选项。您可以根据您要创建的服务类型使用各种选项,请参阅 单元文件结构。???

    以下是网络相关服务的单元配置示例:

    [Unit]
    Description=<service_description>
    After=network.target
    
    [Service]
    ExecStart=<path_to_executable>
    Type=forking
    PIDFile=<path_to_pidfile>
    
    [Install]
    WantedBy=default.target
    Copy to Clipboard
    • <service_description> 是一个信息性描述,显示在 journal 日志文件和 systemctl status 命令的输出中。
    • After 设置可确保仅在网络运行后启动该服务。添加一个空格分隔的其他相关服务或目标的列表。
    • path_to_executable 代表到实际可执行服务的路径。
    • Type=forking 用于进行 fork 系统调用的守护进程。该服务的主要进程使用 path_to_pidfile 中指定的 PID 创建。在 重要 [Service] 部分选项中查找其他启动类型。
    • WantedBy 指出服务应在其下启动的目标。将这些目标视为旧的运行级别概念的替代。
  4. 通知 systemd 存在一个新的 <name>.service 文件:

    # systemctl daemon-reload
    
    # systemctl start <name>.service
    Copy to Clipboard
    警告

    在创建新单元文件或修改现有单元文件后,总是执行 systemctl daemon-reload 命令。否则,systemctl startsystemctl enable 命令可能会因为 systemd 的状态和磁盘上实际的服务单元文件不匹配而失败。请注意,对于有大量单元的系统来说,这需要很长时间,因为每个单元的状态必须在重新载入的过程中被序列化,然后再进行反序列化。

1.8. 使用 sshd 服务的第二个实例创建一个自定义单元文件

如果您需要配置并运行服务的多个实例,您可以创建原始服务配置文件的副本并修改某些参数以避免与服务的主实例冲突。

流程

要创建 sshd 服务的第二个实例:

  1. 创建第二个守护进程将使用的 sshd_config 文件的一个副本:

    # cp /etc/ssh/sshd{,-second}_config
    Copy to Clipboard
  2. 编辑上一步中创建的 sshd-second_config 文件,为第二个守护进程分配不同的端口号和 PID 文件:

    Port 22220
    PidFile /var/run/sshd-second.pid
    Copy to Clipboard

    有关 PortPidFile 选项的更多信息,请参阅 sshd_config(5)手册页。请确定您选择的端口没有被其他服务使用。在运行该服务前,PID 文件不一定存在,它会在服务启动时自动生成。

  3. sshd 服务创建 systemd 单元文件的一个副本:

    # cp /usr/lib/systemd/system/sshd.service /etc/systemd/system/sshd-second.service
    Copy to Clipboard
  4. 更改创建的 sshd-second.service

    1. 修改 Description 选项:

      Description=OpenSSH server second instance daemon
      Copy to Clipboard
    2. sshd.service 添加到 After 选项中指定的服务中,以便第二个实例仅在第一个实例启动后启动:

      After=syslog.target network.target auditd.service sshd.service
      Copy to Clipboard
    3. 删除 ExecStartPre=/usr/sbin/sshd-keygen 行,sshd 的第一个实例包括密钥生成。
    4. sshd 命令添加 -f /etc/ssh/sshd-second_config 参数,以便使用其它配置文件:

      ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS
      Copy to Clipboard
    5. 修改后,sshd-second.service 单元文件包含以下设置:

      [Unit]
      Description=OpenSSH server second instance daemon
      After=syslog.target network.target auditd.service sshd.service
      
      [Service]
      EnvironmentFile=/etc/sysconfig/sshd
      ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS
      ExecReload=/bin/kill -HUP $MAINPID
      KillMode=process
      Restart=on-failure
      RestartSec=42s
      
      [Install]
      WantedBy=multi-user.target
      Copy to Clipboard
  5. 如果使用 SELinux,请将 sshd 的第二个实例的端口添加到 SSH 端口中,否则 sshd 的第二个实例将被拒绝绑定到端口:

    # semanage port -a -t ssh_port_t -p tcp 22220
    Copy to Clipboard
  6. 启用 sshd-second.service ,以便在启动时自动启动:

    # systemctl enable sshd-second.service
    Copy to Clipboard
  7. 使用 systemctl status 命令验证 sshd-second.service 是否在运行。
  8. 通过连接到该服务来验证是否正确启用了端口:

    $ ssh -p 22220 user@server
    Copy to Clipboard

    确保将防火墙配置为允许连接 sshd 的第二个实例。

1.9. 查找 systemd 服务描述

您可以在以 #description 开头的行中找到有关脚本的描述性信息。将此描述与单元文件 [Unit] 部分中的 Description 选项中的服务名称一起使用。标头可能在 #Short-Description#Description 行包含类似的数据。

1.10. 查找 systemd 服务的依赖项

Linux 标准基础(LSB)标头可能包含在多个服务间构成依赖的指令。大多数可以转换为 systemd 单元选项,请查看下表:

表 1.5. LSB 标头中的依赖项选项
LSB 选项描述单元文件的对等

Provides

指定服务的引导工具名称,可在其他初始化脚本中引用(使用"$"前缀)。因为单元文件根据文件名指向其他单元,所以不再需要这个操作。

-

Required-Start

包含所需服务的引导工具名称。这被转换为一个排序依赖关系,引导工具名被替换为其所属的相应服务或目标的单元文件名。例如,如果是 postfix,$network 上的 Required-Start 依赖关系被转换为 network.target 上的 After 依赖关系。

After, Before

Should-Start

比 Required-Start 更弱的依赖项。Should-Start 依赖项失败不会影响服务的启动。

After, Before

required-Stop, Should-Stop

组成负依赖关系。

Conflicts

1.11. 查找服务的默认目标

#chkconfig 开始的行包含三个数字值。最重要的是第一个代表启动该服务的默认运行级别的数字。将这些运行级别映射到等同的 systemd 目标。然后在单元文件的 [Install] 部分中的 WantedBy 选项中列出这些目标。例如: postfix 之前在运行级别 2、3、4 和 5 中启动,它们转换为 multi-user.target 和 graphical.target。请注意,graphical.target 依赖于 multiuser.target,因此不需要指定它们。您也可以在 LSB 标头中的 #Default-Start#Default-Stop 行中找到有关默认和禁止运行级别的信息。

#chkconfig 行里指定的其他两个值代表初始化脚本的启动和关闭优先级。如果 systemd 加载了初始化脚本,则这些值由 systemd 解释,但没有等效的单元文件。

1.12. 查找该服务使用的文件

初始化脚本需要从专用目录中载入功能库,并允许导入配置、环境和 PID 文件。环境变量在初始化脚本标头中以 #config 开头的行中指定,它转换为 EnvironmentFile 单元文件选项。#pidfile 初始化脚本行中指定的 PID 文件使用 PIDFile 选项导入到单元文件中。

未包含在初始化脚本标头中的关键信息是该服务可执行文件的路径,以及该服务可能需要的一些其他文件。在以前的 Red Hat Enterprise Linux 版本中,init 脚本使用 Bash case 语句定义默认操作的服务行为,如 start, stop, 或 restart,以及自定义的操作。以下来自 postfix init 脚本的摘录显示了在服务启动时要执行的代码块。

conf_check() {
    [ -x /usr/sbin/postfix ] || exit 5
    [ -d /etc/postfix ] || exit 6
    [ -d /var/spool/postfix ] || exit 5
}

make_aliasesdb() {
	if [ "$(/usr/sbin/postconf -h alias_database)" == "hash:/etc/aliases" ]
	then
		# /etc/aliases.db might be used by other MTA, make sure nothing
		# has touched it since our last newaliases call
		[ /etc/aliases -nt /etc/aliases.db ] ||
			[ "$ALIASESDB_STAMP" -nt /etc/aliases.db ] ||
			[ "$ALIASESDB_STAMP" -ot /etc/aliases.db ] || return
		/usr/bin/newaliases
		touch -r /etc/aliases.db "$ALIASESDB_STAMP"
	else
		/usr/bin/newaliases
	fi
}

start() {
	[ "$EUID" != "0" ] && exit 4
	# Check that networking is up.
	[ ${NETWORKING} = "no" ] && exit 1
	conf_check
	# Start daemons.
	echo -n $"Starting postfix: "
	make_aliasesdb >/dev/null 2>&1
	[ -x $CHROOT_UPDATE ] && $CHROOT_UPDATE
	/usr/sbin/postfix start 2>/dev/null 1>&2 && success || failure $"$prog start"
	RETVAL=$?
	[ $RETVAL -eq 0 ] && touch $lockfile
        echo
	return $RETVAL
}
Copy to Clipboard

初始化脚本的可扩展性允许指定两个自定义函数,start() 函数块调用的 conf_check()make_aliasesdb()。然后,上面的代码中提到几个外部文件和目录:主服务可执行文件 /usr/sbin/postfix/etc/postfix//var/spool/postfix/ 配置目录,以及 /usr/sbin/postconf/ 目录。

systemd 只支持预定义的操作,但可以执行带有 ExecStartExecStartPreExecStartPostExecStopExecReload 选项的自定义的可执行文件。在 service start 中执行 /usr/sbin/postfix 以及支持脚本。转换复杂的初始化脚本需要了解脚本中每个语句的用途。其中一些语句特定于操作系统版本,因此您不需要转换它们。另一方面,新环境中可能需要进行一些调整,包括单元文件以及服务可执行文件和支持文件中。

1.13. 修改现有单元文件

如果要修改现有的单元文件,请进到 /etc/systemd/system/ 目录。请注意,您不应该修改默认的单元文件,系统将其保存在 /usr/lib/systemd/system/ 目录中。

流程

  1. 根据所需更改的程度,选择以下方法之一:

    • /etc/systemd/system/<unit>.d/ 中为补充配置文件创建一个目录。我们推荐在大多数用例中使用这个方法。您可以使用额外的功能扩展默认配置,同时仍然指向原始单元文件。因此,软件包升级引入的默认单元的更改会被自动应用。如需更多信息,请参阅扩展默认单元配置
    • '/etc/systemd/system/ 目录中的 /usr/lib/systemd/system/'目录中 创建一个原始单元文件的副本,并进行修改。这个副本会覆盖原始文件,因此不会应用软件包更新带来的更改。这个方法对无论软件包更新都应保留的重要单元更改都很有用。有关详细信息,请参阅覆盖默认单元配置
  2. 要返回单元的默认配置,请删除 /etc/systemd/system/ 目录中自定义创建的配置文件。
  3. 将更改应用到单元文件,而不重启系统:

    # systemctl daemon-reload
    Copy to Clipboard

    daemon-reload 选项重新加载所有单元文件,并重新创建依赖项树,这需要立即将任何更改应用到单元文件中。另外,您可以使用以下命令获得同样的效果:

    # init q
    Copy to Clipboard
  4. 如果修改后的单元文件属于一个正在运行的服务,重启该服务:

    # systemctl restart <name>.service
    Copy to Clipboard
重要

要修改由 SysV initscript 处理的服务的属性,如依赖项或超时,请不要修改 initscript 本身。相反,为服务创建一个 systemd 置入配置文件,如: 扩展默认的单元配置覆盖默认的单元配置 中所述。

然后,像普通的 systemd 服务那样管理该服务。

例如:要扩展 network 服务的配置,不要修改 /etc/rc.d/init.d/network initscript 文件。相反,创建一个新目录 /etc/systemd/system/network.service.d/systemd 置入文件 /etc/systemd/system/network.service.d/my_config.conf。然后将修改的值放到 drop-in 文件中。注: systemd 知道 network 服务为 network.service,这就是为什么创建的目录必须名为 network.service.d

1.14. 扩展默认单元配置

您可以使用额外的 systemd 配置选项扩展默认单元文件。

流程

  1. /etc/systemd/system/ 中创建一个配置目录:

    # mkdir /etc/systemd/system/<name>.service.d/
    Copy to Clipboard

    <name> 替换为您要扩展的服务的名称。语法适用于所有单元类型。

  2. 创建一个带有 .conf 后缀的配置文件:

    # touch /etc/systemd/system/name.service.d/<config_name>.conf
    Copy to Clipboard

    <config_name> 替换为配置文件的名称。此文件遵循正常的单元文件结构,且您必须在适当的部分中指定所有指令,请参阅 单元文件结构

    例如,要添加自定义依赖项,请使用以下内容创建配置文件:

    [Unit]
    Requires=<new_dependency>
    After=<new_dependency>
    Copy to Clipboard

    <new_dependency> 代表要被标记为依赖项的单元。另一个例子是主进程退出后重新启动服务的配置文件,延迟 30 秒:

    [Service]
    Restart=always
    RestartSec=30
    Copy to Clipboard

    创建仅关注于一项任务的小配置文件。这些文件可轻松地移动或者链接到其他服务的配置目录。

  3. 将更改应用到单元:

    # systemctl daemon-reload
    # systemctl restart <name>.service
    Copy to Clipboard

例 1.1. 扩展 httpd.service 配置

要修改 httpd.service 单元,以便在启动 Apache 服务时自动执行自定义 shell 脚本,请执行以下步骤。

  1. 创建目录和自定义配置文件:

    # mkdir /etc/systemd/system/httpd.service.d/
    Copy to Clipboard
    # touch /etc/systemd/system/httpd.service.d/custom_script.conf
    Copy to Clipboard
  2. 通过将以下文本插入到 custom_script.conf 文件中,指定您要在主服务进程后执行的脚本:

    [Service]
    ExecStartPost=/usr/local/bin/custom.sh
    Copy to Clipboard
  3. 应用单元更改:

    # systemctl daemon-reload
    Copy to Clipboard
    # systemctl restart httpd.service
    Copy to Clipboard
注意

/etc/systemd/system/ 配置目录中的文件优先于 /usr/lib/systemd/system/ 中的单元文件。因此,如果配置文件包含只可以指定一次的选项,如 DescriptionExecStart,则此选项的默认值会被覆盖。请注意,在 systemd-delta 命令的输出中(在 Monitoring overrides units 中所述)中,比如这个单元总是被标记为 [EXTENDED],即使总和和一些选项也会被覆盖。

1.15. 覆盖默认单元配置

您可以对更新提供单元文件的软件包后将保持不变的单元文件配置进行更改。

流程

  1. root 用户身份输入以下命令来将单元文件复制到 /etc/systemd/system/ 目录中:

    # cp /usr/lib/systemd/system/<name>.service /etc/systemd/system/<name>.service
    Copy to Clipboard
  2. 使用文本编辑器打开复制的文件,并进行更改。
  3. 应用单元更改:

    # systemctl daemon-reload
    # systemctl restart <name>.service
    Copy to Clipboard

1.16. 更改超时限制

您可以为每个服务指定一个超时值,以防止出现故障的服务中断。否则,正常服务的 timeout 的默认值为 90 秒,SysV 兼容服务的 timeout 的默认值为 300 秒。

流程

要扩展 httpd 服务的 timeout 限制:

  1. httpd 单元文件复制到 /etc/systemd/system/ 目录中:

    # cp /usr/lib/systemd/system/httpd.service /etc/systemd/system/httpd.service
    Copy to Clipboard
  2. 打开 /etc/systemd/system/httpd.service 文件,并在 [Service] 部分中指定 TimeoutStartUSec 值:

    ...
    [Service]
    ...
    PrivateTmp=true
    TimeoutStartSec=10
    
    [Install]
    WantedBy=multi-user.target
    ...
    Copy to Clipboard
  3. 重新载入 systemd 守护进程:

    # systemctl daemon-reload
    Copy to Clipboard

验证

  • 验证新的超时值:

    # systemctl show httpd -p TimeoutStartUSec
    Copy to Clipboard
    注意

    要全局更改超时限制,在/etc/systemd/system.conf 中输入 DefaultTimeoutStartSec

1.17. 监控覆盖的单元

您可以使用 systemd-delta 命令显示覆盖或修改的单元文件的概述。

流程

  • 显示被覆盖或修改的单元文件的概述:

    # systemd-delta
    Copy to Clipboard

    例如,命令的输出类似如下:

    [EQUIVALENT] /etc/systemd/system/default.target → /usr/lib/systemd/system/default.target
    [OVERRIDDEN] /etc/systemd/system/autofs.service → /usr/lib/systemd/system/autofs.service
    
    --- /usr/lib/systemd/system/autofs.service      2014-10-16 21:30:39.000000000 -0400
    +++ /etc/systemd/system/autofs.service  2014-11-21 10:00:58.513568275 -0500
    @@ -8,7 +8,8 @@
     EnvironmentFile=-/etc/sysconfig/autofs
     ExecStart=/usr/sbin/automount $OPTIONS --pid-file /run/autofs.pid
     ExecReload=/usr/bin/kill -HUP $MAINPID
    -TimeoutSec=180
    +TimeoutSec=240
    +Restart=Always
    
     [Install]
     WantedBy=multi-user.target
    
    [MASKED]     /etc/systemd/system/cups.service → /usr/lib/systemd/system/cups.service
    [EXTENDED]   /usr/lib/systemd/system/sssd.service → /etc/systemd/system/sssd.service.d/journal.conf
    
    4 overridden configuration files found.
    Copy to Clipboard

1.18. 使用实例化单元

您可以使用单个模板配置来管理服务的多个实例。您可以为单元定义一个通用模板,并在运行时使用特定参数生成该单元的多个实例。模板由 at 符号(@)表示。实例化的单元可以从另一个单元文件(使用 Requires 或者 Wants 选项)或者 systemctl start 命令启动。以下列方式命名实例化服务单元:

<template_name>@<instance_name>.service
Copy to Clipboard

<template_name> 代表模板配置文件的名称。将 <instance_name> 替换为单元实例的名称。多个实例可以指向带有通用于单元所有实例的配置选项的同一个模板文件。模板单元名称具有以下格式:

<unit_name>@.service
Copy to Clipboard

例如,单位文件中的以下 Wants 设置:

Wants=getty@ttyA.service getty@ttyB.service
Copy to Clipboard

首先为给定服务单元进行 systemd 搜索。如果没有找到这样的单元,"@" 和类型后缀间的部分会被忽略,systemd 搜索 getty@.service 文件,从中读取配置并启动服务。

例如, getty@.service 模板包含以下指令:

[Unit]
Description=Getty on %I
...
[Service]
ExecStart=-/sbin/agetty --noclear %I $TERM
...
Copy to Clipboard

getty@ttyA.servicegetty@ttyB.service 从上述模板实例化时,Description= 被解析为 Getty on ttyAGetty on ttyB

1.19. 重要单元指定符

您可以在任何单元配置文件中使用通配符字符,称为 单元指定符 。单元指定符替换某些单元参数,并在运行时被解释。

表 1.6. 重要单元指定符
单元指定符含义描述

%n

完整单元名称

代表完整的单元名称,包括类型后缀。%n 具有相同的含义,但也将禁止的字符替换为 ASCII 代码。

%p

前缀名称

代表删除了类型后缀的单元名称。对于实例化单元,%p 代表"@"字符前的单元名称的部分。

%i

实例名称

是"@"字符和类型后缀之间的实例化单元名称的一部分。%I 具有相同的含义,但也将禁止的字符替换为 ASCII 代码。

%H

主机名

代表在载入单元配置时的运行系统的主机名。

%t

运行时目录

代表运行时目录,对于 root 用户是 /run,对于非特权用户是 XDG_RUNTIME_DIR 变量的值。

有关单元指定符的完整列表,请查看系统中的 systemd.unit (5) 手册页。

第 2 章 管理 systemd

作为系统管理员,您可以使用 systemd 管理系统的关键方面。充当 Linux 操作系统的系统和服务管理器的systemd 软件套件提供用于控制、报告和系统初始化的工具和服务。systemd 的主要功能包括:

  • 在启动过程中并行启动系统服务
  • 按需激活守护进程
  • 基于依赖项的服务控制逻辑

systemd 管理的基本对象是 systemd 单元,一个系统资源和服务的表示。systemd 单元由一个名称、类型和配置文件组成,用来定义和管理特定的任务。您可以使用单元文件来配置系统行为。请参阅以下各种 systemd 单元类型示例:

service
控制和管理单个系统服务。
目标
表示定义系统状态的一组单元。
设备
管理硬件设备及其可用性。
Mount
处理文件系统挂载。
定时器
调度任务以特定间隔运行。

2.1. 使用 systemctl 管理系统服务

作为系统管理员,您可以使用 systemctl 工具管理系统服务。您可以执行各种任务,如启动、停止、重启运行的服务、启用和禁用服务以在引导时启动、列出可用的服务以及显示系统服务状态。

2.1.1. 列出系统服务

您可以列出所有当前载入的服务单元,并显示所有可用服务单元的状态。

流程

使用 systemctl 命令执行以下任何一个任务:

  • 列出所有当前载入的服务单元:

    $ systemctl list-units --type service
    UNIT                     LOAD   ACTIVE SUB     DESCRIPTION
    abrt-ccpp.service        loaded active exited  Install ABRT coredump hook
    abrt-oops.service        loaded active running ABRT kernel log watcher
    abrtd.service            loaded active running ABRT Automated Bug Reporting Tool
    ...
    systemd-vconsole-setup.service loaded active exited  Setup Virtual Console
    tog-pegasus.service            loaded active running OpenPegasus CIM Server
    
    LOAD   = Reflects whether the unit definition was properly loaded.
    ACTIVE = The high-level unit activation state, or a generalization of SUB.
    SUB    = The low-level unit activation state, values depend on unit type.
    
    46 loaded units listed. Pass --all to see loaded but inactive units, too.
    To show all installed unit files use 'systemctl list-unit-files'
    Copy to Clipboard

    默认情况下,systemctl list-units 命令只显示活跃的单元。对于每个服务单元文件,命令提供以下参数的概述:

    UNIT
    服务单元的全名
    LOAD
    配置文件的载入状态
    ACTIVESUB
    当前高级别和低级别单元文件激活状态
    DESCRIPTION
    单元目的和功能的简短描述
  • 使用带有 --all-a 命令行选项的命令,列出 所有载入的单元,而不考虑其状态

    $ systemctl list-units --type service --all
    Copy to Clipboard
  • 列出所有可用服务单元的状态(enableddisabled):

    $ systemctl list-unit-files --type service
    UNIT FILE                               STATE
    abrt-ccpp.service                       enabled
    abrt-oops.service                       enabled
    abrtd.service                           enabled
    ...
    wpa_supplicant.service                  disabled
    ypbind.service                          disabled
    
    208 unit files listed.
    Copy to Clipboard

    对于每个服务单元,这个命令会显示:

    UNIT FILE
    服务单元的全名
    STATE
    服务单元是否已启用或禁用,以便在引导时自动启动的信息

2.1.2. 显示系统服务状态

您可以检查任何服务单元以获取详细信息,并验证该服务的状态,无论是否启用了以便在引导期间启动还是当前正在运行。您还可以查看在特定的服务单元之后或之前启动的服务。

流程

  • 显示与系统服务对应的服务单元的详细信息:

    $ systemctl status <name>.service
    Copy to Clipboard

    <name> 替换为您要检查的服务单元的名称(例如:gdm)。

    这个命令显示以下信息:

    • 所选服务单元的名称,后跟一个简短描述
    • 可用服务单元信息中 中描述的一个或多个字段
    • 服务单元的执行:如果单元由 root 用户执行
    • 最新的日志条目

      表 2.1. 可用的服务单元信息
      描述

      Loaded

      是否服务单元已载入的信息、到单元文件的绝对路径,以及是否已启用该单元以便在引导时启动。

      Active

      服务单元是否在运行的信息,后面有一个时间戳。

      Main PID

      进程 ID 和相应的系统服务的名称。

      Status

      相关系统服务的额外信息。

      Process

      有关相关进程的附加信息。

      CGroup

      有关相关的控制组(cgroups)的额外信息。

  • 验证特定的服务单元是否正在运行:

    $ systemctl is-active <name>.service
    Copy to Clipboard
  • 确定是否已启用了特定的服务单元以便在引导时启动:

    $ systemctl is-enabled <name>.service
    Copy to Clipboard
    注意

    如果指定的服务单元正在运行或已启用,则 systemctl is-activesystemctl is-enabled 命令都会返回 0 退出状态 0。

  • 检查在指定的服务单元之前,systemd 命令哪些服务启动

    # systemctl list-dependencies --after <name>.service
    Copy to Clipboard

    例如,要查看在 gdm 前启动的服务列表,请输入:

    # systemctl list-dependencies --after gdm.service
    gdm.service
    ├─dbus.socket
    ├─getty@tty1.service
    ├─livesys.service
    ├─plymouth-quit.service
    ├─system.slice
    ├─systemd-journald.socket
    ├─systemd-user-sessions.service
    └─basic.target
    [output truncated]
    Copy to Clipboard
  • 检查在指定的服务单元之后,systemd 命令哪些服务启动:

    # systemctl list-dependencies --before <name>.service
    Copy to Clipboard

    例如,要查看在 gdmsystemd 启动的服务列表,请输入:

    # systemctl list-dependencies --before gdm.service
    gdm.service
    ├─dracut-shutdown.service
    ├─graphical.target
    │ ├─systemd-readahead-done.service
    │ ├─systemd-readahead-done.timer
    │ └─systemd-update-utmp-runlevel.service
    └─shutdown.target
      ├─systemd-reboot.service
      └─final.target
        └─systemd-reboot.service
    Copy to Clipboard

2.1.3. 启动和停止 systemd 单元

您可以使用 systemctl start 命令在当前会话中启动系统服务。

先决条件

  • 您有 Root 访问权限。

流程

  • 在当前会话中启动一个系统服务:

    # *systemctl start <systemd_unit> *
    Copy to Clipboard

    将 < systemd_unit > 替换为您要启动的服务单元的名称(例如 httpd.service)。

    注意

    systemd 中,不同服务间会存在正或负的依赖关系。启动一个特定的服务可能需要启动一个或多个其他服务(正依赖项)或停止一个或多个服务(负依赖项)。

    当您试图启动新服务时,systemd 会自动解析所有依赖项,而不会向用户明确通知。这意味着,如果您已运行了一个服务,并且您尝试使用负依赖项启动另一个服务,则第一个服务会自动停止。

    例如,如果您正在运行 sendmail 服务,并且您试图启动 postfix 服务,systemd 首先自动停止 sendmail,因为这些服务会冲突,且无法在同一端口上运行。

2.1.4. 停止一个系统服务

如果要在当前会话中停止系统服务,请使用 systemctl stop 命令。

先决条件

  • 有 Root 访问权限

流程

  • 停止一个系统服务:

    # systemctl stop <name>.service
    Copy to Clipboard

    <name> 替换为您要停止的服务单元的名称(例如:bluetooth)。

2.1.5. 重启并重新加载一个系统服务

您可以使用 restart 命令在当前会话中重启系统服务,以执行以下操作:

  • 在当前会话中停止所选的服务单元,并立即再次启动它。
  • 仅在对应的服务已在运行时才重启服务单元。
  • 重新加载系统服务的配置,而不中断其执行。

先决条件

  • 您有 Root 访问权限。

流程

  • 重启一个系统服务:

    # systemctl restart <name>.service
    Copy to Clipboard

    使用您要重启的服务单元的名称替换 <name>(例如 httpd)。

    如果所选服务单元没有运行,这个命令会启动它。

  • 仅在相应的服务已在运行时重启服务单元:

    # systemctl try-restart <name>.service
    Copy to Clipboard
  • 重新载入配置而不中断服务执行:

    # systemctl reload <name>.service
    Copy to Clipboard
    注意

    不支持此功能的系统服务忽略此命令。要重启这些服务,请使用 reload-or-restartreload-or-try-restart 命令。

2.1.6. 启用一个系统服务,以便在引导时启动

您可以启用一个服务以便在引导时自动启动,这些更改将在下次重启时应用。

先决条件

  • 您有 Root 访问权限。

流程

  • 验证单元是否已屏蔽:

    # systemctl status <systemd_unit>
    Copy to Clipboard
  • 如果这个单元被屏蔽,请首先取消屏蔽它:

    # systemctl unmask <systemd_unit>
    Copy to Clipboard
  • 在引导时启用服务:

    # systemctl enable <systemd_unit>
    Copy to Clipboard

    将 &lt ;systemd_unit > 替换为您要启用的服务单元的名称(例如 httpd)。

(可选)将 现在 选项传给命令,以便立即启动该单元。

2.1.7. 禁用一个系统服务在引导时启动

您可以防止服务单元在引导时自动启动。如果您禁用某个服务,它不会在引导时启动,但可以手动启动。您还可以屏蔽服务,使其无法手动启动。屏蔽是一种禁用服务的方法,使该服务能够永久不可用,直到再次屏蔽该服务。

先决条件

  • 您有 Root 访问权限。

流程

  • 禁用要在引导时启动的服务:

    # systemctl disable <name>.service
    Copy to Clipboard

    <name> 替换为您要禁用的服务单元的名称(例如:bluetooth)。(可选)传递- now 命令,以便在服务当前正在运行时同时停止该服务。

  • 可选: 要防止单元被管理员意外启动,或者作为其他单元的依赖项,请屏蔽该服务:

    # systemctl mask <name>.service
    Copy to Clipboard

2.2. 引导至目标系统状态

作为系统管理员,您可以控制系统的引导过程,并定义您希望系统引导到的状态。这称为 systemd 目标,它是您的系统启动以达到某一特定级别功能的一组 systemd 单元。在使用 systemd 目标时,您可以查看默认目标,选择一个运行时的目标,更改默认引导目标,引导到紧急或救援目标。

2.2.1. 目标单元文件

systemd 中的目标是一组相关的单元,它们在系统启动期间充当同步点。目标单元文件以 .target 文件扩展名结尾,代表 systemd 目标。目标单元的目的是通过一组依赖项将各种 systemd 单元分组到一起。

考虑以下示例:

  • 同样,multi-user.target 单元启动其他基本系统服务,如 NetworkManager (NetworkManager.service) 或 D-Bus (dbus.service),并激活另一个名为 basic.target 的目标单元。

您可以将以下 systemd 目标设置为默认或当前目标:

表 2.2. 常见 systemd 目标
救援在基本系统中拉取的单元目标,并生成一个救援 shell

多用户

用于设置多用户系统的单元目标

图形化

用于设置图形登录屏幕的单元目标

紧急

在主控制台上启动紧急 shell 的单元目标

2.2.2. 更改引导到的默认目标

default.target 符号链接指的是系统应引导到的 systemd 目标。当系统启动时,systemd 会解析此链接并引导至定义的目标。您可以在 /etc/systemd/system/default.target 文件中找到当前所选的默认目标单元。每个目标代表某个特定的功能级,用于对其他单元进行分组。另外,目标单元在引导过程中作为同步点提供服务。您可以更改系统引导到的默认目标。当您设置默认目标单元时,当前目标将保持不变,直到下次重启为止。

先决条件

  • 您有 Root 访问权限。

流程

  1. 确定当前用于启动系统的默认目标单元 systemd

    # systemctl get-default
    graphical.target
    Copy to Clipboard
  2. 列出当前载入的目标:

    # systemctl list-units --type target
    Copy to Clipboard
  3. 将系统配置为默认使用不同的目标单元:

    # systemctl set-default <name>.target
    Copy to Clipboard

    <name> 替换为您要默认使用的目标单元的名称。

    Example:
    # 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
    Copy to Clipboard
  4. 验证默认目标单元:

    # systemctl get-default
    multi-user.target
    Copy to Clipboard
  5. 可选:切换到新的默认目标:

    # systemctl isolate default.target
    Copy to Clipboard

    或者,重启系统。

2.2.3. 更改当前目标

在运行的系统中,您可以在不重启的情况下更改当前启动中的目标单元。如果您切换到不同的目标,systemd 会启动这个目标需要的所有服务及其依赖项,并停止新目标没有启用的所有服务。手动切换到其他目标只是临时操作。重启主机时,systemd 会再次引导到默认目标。

流程

  1. 可选:显示您可以选择的目标列表:

    # systemctl list-units --type target
    Copy to Clipboard
    注意

    您只能隔离单元文件中设置了 AllowIsolate=yes 选项的目标。

  2. 在当前引导中切换到不同的目标单元:

    # systemctl isolate <name>.target
    Copy to Clipboard

    <name> 替换为您要在当前引导中使用的目标单元的名称。

    Example:
    # systemctl isolate multi-user.target
    Copy to Clipboard

    这个命令启动名为 multi-user 的目标单元和所有依赖的单元,并立即停止所有其他单元。

2.2.4. 引导至救援模式

您可以引导到提供单用户环境的 救援模式,以便在系统无法进入后续目标以及常规引导过程失败时进行故障排除或修复。在救援模式中,系统会尝试挂载所有本地文件系统,并启动某些重要的系统服务,但不会激活网络接口。

先决条件

  • 您有 Root 访问权限。

流程

  • 要进入救援模式,在当前会话中更改当前目标:

    # systemctl rescue
    
    Broadcast message from root@localhost on pts/0 (Fri 2023-03-24 18:23:15 CEST):
    
    The system is going down to rescue mode NOW!
    Copy to Clipboard
    注意

    这个命令与 systemctl isolate rescue.target 类似,但它也会向当前登录到该系统的所有用户发送信息性消息。

    要防止 systemd 发送信息,输入带有以下命令行选项 --no-wall 的命令:

    # systemctl --no-wall rescue
    Copy to Clipboard

故障排除

如果您的系统无法进入救援模式,您可以引导至 紧急模式,其提供尽可能小的环境。在紧急模式下,系统仅挂载用于读取的 root 文件系统,不会尝试挂载任何其他本地文件系统,不激活网络接口,并且仅启动几个必要的服务。

2.2.5. 引导过程故障排除

作为系统管理员,您可以在引导时选择非默认目标来对引导过程进行故障排除。在引导时更改目标仅会影响单个引导。您可以引导到 紧急模式,它提供尽可能小的环境。

流程

  1. 重启系统,并通过按 Enter 键之外的任意键中断引导装载程序菜单倒计时,这将发起一个正常启动。
  2. 将光标移至要启动的内核条目。
  3. 按 E 键编辑当前条目。
  4. 移动到以 linux 开头的行的末尾,然后按 Ctrl+E 跳到行尾:

    linux ($root)/vmlinuz-5.14.0-70.22.1.e19_0.x86_64 root=/dev/mapper/rhel-root ro crash\
    kernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv/swap rhgb quiet
    Copy to Clipboard
  5. 要选择一个备用引导目标,请将 systemd.unit= 参数附加到以 linux 开头的行的末尾:

    linux ($root)/vmlinuz-5.14.0-70.22.1.e19_0.x86_64 root=/dev/mapper/rhel-root ro crash\
    kernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv/swap rhgb quiet systemd.unit=<name>.target
    Copy to Clipboard

    <name> 替换为您要使用的目标单元的名称。例如:systemd.unit=emergency.target

  6. 按 Ctrl+X 使用这些设置进行引导。

2.3. 关闭、挂起和休眠系统

作为系统管理员,您可以使用不同的电源管理选项来管理功耗,执行合适的 shutdown 以确保保存所有数据,或者重启系统以应用更改和更新。

2.3.1. 安排一个系统 shutdown

作为系统管理员,您可以安排一个延迟 shutdown,给用户保存其工作及注销系统留出时间。使用 shutdown 命令执行以下操作:

  • 关闭系统,并在特定时间关闭机器:

    # shutdown --poweroff hh:mm
    Copy to Clipboard

    其中 hh:mm 是 24 小时时间表示法的时间。为防止新的登录,在系统 shutdown 前 5 分钟会创建 /run/nologin 文件 。

    当使用时间参数时,您可以通过指定可选的 wall 消息 来通知登录到计划关闭的系统的用户,如 shutdown --poweroff 13:59 "Attention。系统将于 13:59" 关闭。

  • 在延迟后关闭和停止系统,而不关闭机器:

    # shutdown --halt +m
    Copy to Clipboard

    其中 +m 是延迟时间(以分钟为单位)。您可以使用 now 关键字作为 +0 的别名。

  • 取消待处理的 shutdown

    # shutdown -c
    Copy to Clipboard

2.3.2. 使用 systemctl 命令来关闭系统

作为系统管理员,您可以关闭系统并关闭机器,或使用 systemctl 命令关闭和停止系统,而不关掉机器电源。

先决条件

  • 根访问权限

流程

使用 systemctl 命令执行以下任何一个任务:

  • 关闭系统并关掉机器电源:

    # systemctl poweroff
    Copy to Clipboard
  • 关闭和停止系统,而不关掉机器电源:

    # systemctl halt
    Copy to Clipboard
注意

默认情况下,运行其中任何一个命令都可让 systemd 向当前登录到该系统的所有用户发送一条信息性消息。要防止 systemd 发送这条消息,请使用 --no-wall 命令行选项运行所选命令。

2.3.3. 重启系统

当您重启系统时,systemd 会停止所有正在运行的程序和服务,系统会关闭,然后立即启动。

先决条件

  • 您有 Root 访问权限。

流程

  • 重启系统:

    # systemctl reboot
    Copy to Clipboard
注意

默认情况下,当您使用此命令时,systemd 会向当前登录到该系统的所有用户发送一条信息性消息。要防止 systemd 发送这条消息,请使用 --no-wall 选项运行这个命令。

2.3.4. 通过挂起和休眠系统来优化功耗

作为系统管理员,您可以管理功耗,节省系统能源,并保留系统的当前状态。要做到这一点,请应用以下模式之一:

  • suspend
  • 休眠
  • Hybrid Sleep
  • suspend-then-hibernate

先决条件

  • 您有 Root 访问权限。

流程

选择适当的节能方法:

  • 暂停 Suspend ing 将系统状态保存在 RAM 中,除了 RAM 模块外,关闭机器中的大多数设备。当您重新打开机器时,系统会从内存中恢复其状态,而无需再次引导。由于系统状态保存在 RAM 中,而不是保存在硬盘上,因此,从挂起模式恢复系统比从休眠模式恢复要快得多。但是,挂起的系统状态也会受到断电的影响。要挂起系统,请运行:

    # systemctl suspend
    Copy to Clipboard
  • Hibernate Hibernating 在硬盘中保存系统状态,并关闭机器。当您重新打开机器时,系统会从保存的数据中恢复其状态,而无需再次引导。由于系统状态保存在硬盘上,而不是保存在 RAM 中,因此机器不必保持对 RAM 模块的供电。但是,因此,从休眠模式恢复系统要比将其恢复为挂起模式恢复要慢得多。要休眠系统,请运行:

    # systemctl hibernate
    Copy to Clipboard
  • 混合睡眠状态 组合了休眠和暂停的元素。系统首先在硬盘上保存当前状态,并进入类似挂起的低电源状态,这允许系统更快地恢复。混合睡眠的好处是,如果系统在睡眠状态下断电,它仍然可以从硬盘上保存的镜像中恢复之前的状态,类似于休眠。要休眠并挂起系统,请运行:

    # systemctl hybrid-sleep
    Copy to Clipboard
  • suspend -then-hibernate 此模式首先挂起系统,这会将当前系统状态保存到 RAM,并将系统置于低电源模式。如果系统保持挂起一段时间,则系统会休眠,您可以在 HibernateDelaySec 参数中定义。休眠将系统状态保存到硬盘上,并完全关闭系统。suspend-then-hibernate 模式提供了保留电池电源的好处,同时您仍能快速地恢复工作。另外,这个模式确保您的数据在出现电源故障时被保存。挂起然后休眠系统:

    # systemctl suspend-then-hibernate
    Copy to Clipboard

2.3.5. 更改电源按钮行为

当按计算机上的 power 按钮时,它默认挂起或关闭系统。您可以根据您的偏好自定义此行为。

2.3.5.1. 在按按钮且 GNOME 未运行时更改电源按钮的行为

当您在非图形 systemd 目标中按 power 按钮时,它默认关闭系统。您可以根据您的偏好自定义此行为。

先决条件

  • 管理权限

流程

  1. 编辑 /etc/systemd/logind.conf 配置文件,并将 HandlePowerKey=poweroff 变量设置为以下选项之一:

    poweroff
    关闭计算机。
    reboot
    重启系统。
    halt
    发起系统停止。
    kexec
    发起 kexec 重启。
    suspend
    挂起系统。
    hibernate
    发起系统休眠。
    ignore
    什么都不做。

    例如,要在按下电源按钮时重启系统,请使用这个设置:

    HandlePowerKey=reboot
    Copy to Clipboard
2.3.5.2. 在按按钮和 GNOME 运行时更改电源按钮的行为

在图形登录屏幕或在图形用户会话中,按 power 按钮默认挂起机器。当用户物理按下 power 按钮或从远程控制台按下虚拟 power 按钮时,才会出现这种情况。您可以选择不同的 power 按钮行为。

流程

  1. /etc/dconf/db/local.d/01-power 文件中为系统范围的设置创建一个本地数据库,其内容如下:

    [org/gnome/settings-daemon/plugins/power]
    power-button-action=<value>
    Copy to Clipboard

    使用以下电源按钮操作之一替换 < value >:

    nothing
    什么都不做。
    suspend
    挂起系统。
    hibernate
    休眠系统。
    interactive

    显示一个弹出窗口查询,询问用户要做什么。

    交互模式下,按下 power 按钮后,系统在 60 秒后自动关闭。但是,您可以从弹出查询中选择不同的行为。

  2. 可选:覆盖用户的设置,并阻止用户更改它。在 /etc/dconf/db/local.d/locks/01-power 文件中输入以下配置:

    /org/gnome/settings-daemon/plugins/power/power-button-action
    Copy to Clipboard
  3. 更新系统数据库:

    # dconf update
    Copy to Clipboard
  4. 注销并重新登录,以使系统范围的设置生效。

第 3 章 优化 systemd 以缩短引导时间

作为系统管理员,您可以优化系统的性能并缩短引导时间。您可以查看 systemd 在启动过程中启动的服务,并评估它们的必要性。禁用某些服务在引导时启动可以提高系统的引导时间。

3.1. 检查系统引导性能

要检查系统引导性能,您可以使用 systemd-analyze 命令。通过使用某些选项,您可以调优 systemd 来缩短引导时间。

先决条件

  • 可选:在检查 systemd 以调优引导时间前,列出所有启用的服务:

    $ systemctl list-unit-files --state=enabled
    Copy to Clipboard

流程

选择您要分析的信息:

  • 分析最后一次成功引导所需的时间的信息:

    $ systemd-analyze
    Copy to Clipboard
  • 分析每个 systemd 单元的单元初始化时间:

    $ systemd-analyze blame
    Copy to Clipboard

    输出会根据在上一次成功引导过程中初始化的时间以降序列出。

  • 识别在最后一次成功引导时花费最长初始化时间的关键单元:

    $ systemd-analyze critical-chain
    Copy to Clipboard

    输出突出显示使用红色的引导速度非常慢的单元。

    图 3.1. systemd-analyze critical-chain 命令的输出

    systemd analyze critical

3.2. 为选择可安全禁用的服务提供指导信息

您可以通过禁用引导时默认启用的某些服务来缩短系统的引导时间。

  • 列出启用的服务:

    $ systemctl list-unit-files --state=enabled
    Copy to Clipboard
  • 禁用服务:

    # systemctl disable <service_name>
    Copy to Clipboard

某些服务必须保持启用状态,以便您的操作系统安全且以您需要的方式工作。

请参阅下表,来作为选择可安全禁用的服务的指南。此表列出了 Red Hat Enterprise Linux 最小安装上默认启用的所有服务。

表 3.1. 在 RHEL 的最小安装中默认启用的服务
服务名称它可用被禁用吗?更多信息

auditd.service

仅在不需要内核提供审核信息时禁用 auditd.service。请注意,如果禁用 auditd.service,则不会生成 /var/log/audit/audit.log 文件。因此,您无法追溯检查一些常见的动作或事件,如用户登录、服务启动或密码更改。还请注意 auditd 有两个部分:内核部分和服务本身。使用 systemctl disable auditd 命令,您只是禁用了该服务,而不是禁用内核的部分。要禁用系统审核,请在内核命令行中设置 audit=0

autovt@.service

这个服务只在真正需要时才运行,因此不需要禁用它。

crond.service

请注意,如果您禁用 crond.service,则不会运行 crontab 中的项目。

dbus-org.fedoraproject.FirewallD1.service

firewalld.service 的符号链接

dbus-org.freedesktop.NetworkManager.service

NetworkManager.service 的符号链接

dbus-org.freedesktop.nm-dispatcher.service

NetworkManager-dispatcher.service的符号链接

firewalld.service

仅在不需要防火墙时禁用 firewalld.service

getty@.service

这个服务只在真正需要时才运行,因此不需要禁用它。

import-state.service

仅在不需要从网络存储引导时才禁用 import-state.service

irqbalance.service

仅在只有一个 CPU 时禁用 irqbalance.service。不要在有多个 CPU 的系统中禁用 irqbalance.service

kdump.service

仅在不需要内核崩溃报告时禁用 kdump.service

loadmodules.service

除非 /etc/rc.modules/etc/sysconfig/modules 目录存在,否则该服务不会在最小 RHEL 安装中启动,否则不会启动该服务。

lvm2-monitor.service

仅在不使用逻辑卷管理器(LVM)时禁用 lvm2-monitor.service

microcode.service

不要禁用该服务,因为它在 CPU 中提供了 microcode 软件的更新。

NetworkManager-dispatcher.service

只在不需要在网络配置更改时通知时才禁用 NetworkManager-dispatcher.service (例如在静态网络中)。

NetworkManager-wait-online.service

只有在引导后不需要工作网络连接时才禁用 NetworkManager-wait-online.service。如果启用该服务,则该系统不会在网络连接正常工作前完成引导。这可能会大大延长引导时间。

NetworkManager.service

仅在不需要连接到网络时禁用 NetworkManager.service

nis-domainname.service

仅在不使用网络信息服务(NIS)时禁用 nis-domainname.service

rhsmcertd.service

 

rngd.service

仅在系统上不需要大量熵或者没有任何硬件生成器时才禁用 rngd.service。请注意,在需要大量好熵的环境中,比如用于生成 X.509 证书的系统(如 FreeIPA 服务器)中,该服务是必需的。

rsyslog.service

仅在不需要持久性日志,或把 systemd-journald 设置为持久性模式时,禁用 rsyslog.service

selinux-autorelabel-mark.service

仅在不使用 SELinux 时禁用 selinux-autorelabel-mark.service

sshd.service

仅在不需要 OpenSSH 服务器远程登录时禁用 sshd.service

sssd.service

仅在没有通过网络登录系统的用户(例如,使用 LDAP 或 Kerberos)时禁用 sssd.service。如果禁用了 sssd.service,红帽建议禁用所有 sssd-* 单元。

syslog.service

rsyslog.service 的别名

tuned.service

仅在需要使用性能调整时禁用 tuned.service

lvm2-lvmpolld.socket

仅在您不使用逻辑卷管理器(LVM)时禁用 lvm2-lvmpolld.socket

dnf-makecache.timer

仅在不需要自动更新软件包元数据时禁用 dnf-makecache.timer

unbound-anchor.timer

仅在不需要 DNS 安全扩展(DNSSEC)的 root 信任锚时禁用 unbound-anchor.timer。Unbound 解析器和解析器库使用此根信任定位符进行 DNSSEC 验证。

要查找有关服务的更多信息,请使用以下命令之一:

$ systemctl cat <service_name>
Copy to Clipboard
$ systemctl help <service_name>
Copy to Clipboard

systemctl cat 命令提供相应 /usr/lib/systemd/system/<service> 服务文件的内容,以及所有适用的覆盖。适用的覆盖包括 /etc/systemd/system/<service> 文件中的单元文件覆盖,或者相应 unit.type.d 目录中的临时文件。

法律通告

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat