h81主板设置启动项（h81主板启动针脚图解）

用 systemd-analyze 洞悉并解决 Linux 启动性能问题。

h81主板设置启动项,h81主板启动针脚图解(1)

系统管理员的一部分工作就是分析系统性能，发现并解决引起性能不佳、启动时间长的问题。系统管理员也需要去检查 systemd 的配置和使用的其它方面。

systemd 初始化系统提供了 systemd-analyze工具，可以帮助发现性能问题和其他重要的 systemd 信息。在以前的文章《分析 systemd 日历和时间跨度》里，我用了systemd-analyze去分析 systemd 里的时间戳和时间跨度，但是这个工具还有很多其他用法，这个文章里我将再揭示一些。

（LCTT 译注：systemd 是目前主流 Linux 发行版采用的系统管理系统）

（LCTT 译注：为了区分英文的 “boot” 和 “startup” 的不同涵义，此处将 “boot” 翻译为“引导”，“startup” 翻译为“启动”。）

概述启动

Linux 启动过程是值得学习关注的地方，因为 systemd-analyze工具很多功能聚焦在启动startup过程。但是首先，要理解引导boot和启动startup。引导阶段从 BIOS 加电自检（POST）开始，结束于内核完成加载并控制主机系统，然后是开始了启动过程，也是 systemd 日志的开始点。

这个系列的第二篇文章《理解 Linux 启动时的 systemd》中，我详细讨论了启动阶段的内容和过程。在这篇文章里，我想研究一下启动过程，看看需要多少时间和大部分时间花费在哪里。

下面我将展示的结果来自我的主要工作站，这比虚拟机的结果要有趣得多。这个工作站包括一块华硕 TUF X299 Mark 2 主板、一个英特尔 i9-7960X CPU（16 核 32 线程），64 G 内存。下面的一些命令非 root 用户也可以使用，但是我在这篇文章里使用了 root 用户，以避免在用户之间切换。

检查启动过程有几种方法，最简单的 systemd-analyze命令显示了启动的几个主要部分耗费的时间，包括内核启动、装载运行 initrd（即初始 ramdisk，这是一个用来初始化一些硬件、挂载/根文件系统的临时系统镜像），还有用户空间（加载所有使主机达到可用状态的程序和守护程序）。如果没有像该命令传递子命令，默认是systemd-analyze time：

[root@david ~]$ systemd-analyze Startup finished in 53.921s (firmware) 2.643s (loader) 2.236s (kernel) 4.348s (initrd) 10.082s (userspace) = 1min 13.233s graphical.target reached after 10.071s in userspace [root@david ~]#

这个输出中最值得注意的数据是在固件（BIOS）中花费的时间：几乎 54 秒。这是一个不太正常的时间，我的其他物理系统都没有花费这么长的时间来通过 BIOS。

我的 System76 Oryx Pro 笔记本在 BIOS 阶段只花了 8.506 秒，我家里所有的系统都在 10 秒以内。在线搜索一阵之后，我发现这块主板以其超长的 BIOS 引导时间而闻名。我的主板从不“马上启动”，总是挂起，我需要关机再开机，BIOS 报错，按 F1进入 BIOS 设置，选择要引导的驱动器完成引导，多花费的时间就是这样用掉的。

不是所有主机都会显示固件数据（LCTT 译注：固件引导中不涉及 systemd）。我的不科学的实验使我相信，这个数据只显示给英特尔 9 代或以上的处理器。但这可能是不正确的。

这个关于引导、启动的概述提供了很好的（虽然有限）的信息，但是还有很多关于启动的信息，我将在下面描述。

分配责任

你可以用 systemd-analyze blame来发现哪个 systemd 单元的初始化时间最长。其结果按照初始化时间长短排序，从多到少：

[root@david ~]$ systemd-analyze blame 5.417s NetworkManager-wait-online.service 3.423s dracut-initqueue.service 2.715s systemd-udev-settle.service 2.519s fstrim.service 1.275s udisks2.service 1.271s smartd.service 996ms upower.service 637ms lvm2-monitor.service 533ms lvm2-pvscan@8:17.service 520ms dmraid-activation.service 460ms vboxdrv.service 396ms initrd-switch-root.service

因为很多服务是并行开始的，在 BIOS 之后所有单元加在一起的总数大大超过了 systemd-analyze time汇总数。很多都是小数，不能显著的节省时间。

这个命令提供的数据指明了改善启动时间的办法。无用的服务可以禁用（disable）。在这个启动过程中，似乎没有任何一个服务需要花费过长的时间。你可能会在每次启动时看到不同的结果。（LCTT 译注：并行启动服务的原因）

关键链

就像项目管理中的关键路径一样，关键链显示了在启动过程中发生的时间关键的事件链（LCTT 译注：systemd 可以定义服务间的依赖，构成关键链）。如果启动缓慢，这些是你想查看的 systemd 单元，因为它们是导致延迟的单元。这个工具不会显示所有启动的单元，只显示这个关键事件链中的单元。（LCTT 译注：相当于最短路径。并不显示依赖不在关键链上的服务单元）

[root@david ~]# systemd-analyze critical-chain The time when unit became active or started is printed after the "@" character. The time the unit took to start is printed after the " " character. graphical.target @10.071s └─lxdm.service @10.071s └─plymouth-quit.service @10.047s 22ms └─systemd-user-sessions.service @10.031s 7ms └─remote-fs.target @10.026s └─remote-fs-pre.target @10.025s └─nfs-client.target @4.636s └─gssproxy.service @4.607s 28ms └─network.target @4.604s └─NetworkManager.service @4.383s 219ms └─dbus-broker.service @4.434s 136ms └─dbus.socket @4.369s └─sysinit.target @4.354s └─systemd-update-utmp.service @4.345s 9ms └─auditd.service @4.301s 42ms └─systemd-tmpfiles-setup.service @4.254s 42ms └─import-state.service @4.233s 19ms └─local-fs.target @4.229s └─Virtual.mount @4.019s 209ms └─systemd-fsck@dev-mapper-vg_david2\x2dVirtual.service @3.742s 274ms └─local-fs-pre.target @3.726s └─lvm2-monitor.service @356ms 637ms └─dm-event.socket @319ms └─-.mount └─system.slice └─-.slice [root@david ~]#

前面有 @的数字表示单元激活开始启动所使用的绝对秒数。前面有的数字显示单元启动所需的时间。

系统状态

有时候你需要确定系统的当前状态，systemd-analyze dump命令转储了当前系统状态的大量数据。有主要的启动时间戳，一个每个 systemd 单元的列表，并对每个单元状态进行了完整描述：

[root@david ~]# systemd-analyze dump Timestamp firmware: 1min 7.983523s Timestamp loader: 3.872325s Timestamp kernel: Wed 2020-08-26 12:33:35 EDT Timestamp initrd: Wed 2020-08-26 12:33:38 EDT Timestamp userspace: Wed 2020-08-26 12:33:42 EDT Timestamp finish: Wed 2020-08-26 16:33:56 EDT Timestamp security-start: Wed 2020-08-26 12:33:42 EDT Timestamp security-finish: Wed 2020-08-26 12:33:42 EDT Timestamp generators-start: Wed 2020-08-26 16:33:42 EDT Timestamp generators-finish: Wed 2020-08-26 16:33:43 EDT Timestamp units-load-start: Wed 2020-08-26 16:33:43 EDT Timestamp units-load-finish: Wed 2020-08-26 16:33:43 EDT Timestamp initrd-security-start: Wed 2020-08-26 12:33:38 EDT Timestamp initrd-security-finish: Wed 2020-08-26 12:33:38 EDT Timestamp initrd-generators-start: Wed 2020-08-26 12:33:38 EDT Timestamp initrd-generators-finish: Wed 2020-08-26 12:33:38 EDT Timestamp initrd-units-load-start: Wed 2020-08-26 12:33:38 EDT Timestamp initrd-units-load-finish: Wed 2020-08-26 12:33:38 EDT -> Unit system.slice: Description: System Slice Instance: n/a Unit Load State: loaded Unit Active State: active State Change Timestamp: Wed 2020-08-26 12:33:38 EDT Inactive Exit Timestamp: Wed 2020-08-26 12:33:38 EDT Active Enter Timestamp: Wed 2020-08-26 12:33:38 EDT Active Exit Timestamp: n/a Inactive Enter Timestamp: n/a May GC: no

在我的主工作站上，这个命令生成了 49680 行输出，大概 1.66MB，这个命令非常快，不需要等待。

我很喜欢为各种连接设备（如存储设备）提供的大量细节。每个 systemd 单元有一个部分，包括各种运行时、缓存、日志目录的模式、启动单元的命令行、PID、开始时间戳，以及内存和文件限制等细节。

systemd-analyze的手册页里展示了systemd-analyze --user dump选项，目的是显示用户管理器的内部状态。但这个选项对我来说是失败的，互联网搜索之后表明它可能有一些问题。在 systemd 里，--user实例用来管理和控制处理器给每个用户的进程资源。处理能力按分给每个用户的进程都属于一个控制组，我将在以后的文章中介绍。

分析图表

大多数啥都不懂的猥琐老板（PHB）和许多优秀的管理者都发现漂亮的图表比我通常喜欢的基于文本的系统性能数据更容易阅读和理解。但有时，即使是我也喜欢一个好的图表，systemd-analyze提供了显示引导/启动数据的SVG矢量图表。

下面的命令生成一个矢量图文件，来显示在引导和启动过程发生的事件。生成这个文件只需要几秒：

[root@david ~]# systemd-analyze plot > /tmp/bootup.svg

这个命令创建了一个 SVG 文件，SVG 是一个定义了一系列图形矢量的文本文件，包括 Image Viewer、Ristretto、Okular、Eye of Mate、LibreOffice Draw 在内的这些可以生成图形的应用，可以用 SVG 来创建图像。

我用 LibreOffice Draw（LCTT 译注：一个办公文档软件）来渲染一幅图形。这张图形很大，你需要放到很大才能看清细节。这里是它的一小部分：

h81主板设置启动项,h81主板启动针脚图解(2)

图中时间轴上零点（0）的左边是引导阶段，零点的右边是启动阶段。这一小部分显示了内核、initrd 和 initrd 启动的进程。

这张图一目了然地显示了什么时候启动，启动需要多少时间，以及主要的依赖项。关键路径用红色高亮显示。

另外一个生成图形输出的命令是 systemd-analyze plot，它生成了DOT格式的文本依赖图。产生的数据流通过dot工具进行处理，这是一组用来从多种类型数据中生成矢量图文件的程序。这些 SVG 文件也能被上面列出的工具处理。

首先，生成文件，在我的主工作站花了 9 分钟：

[root@david ~]# time systemd-analyze dot | dot -Tsvg > /tmp/test.svg Color legend: black = Requires dark blue = Requisite dark grey = Wants red = Conflicts green = After real 8m37.544s user 8m35.375s sys 0m0.070s [root@david ~]#

我不会在这里重现输出，因为产生的图形就像一大堆意大利面条。但是你应该试试，看看我想让你看到的结果。

条件

在阅读 systemd-analyze(1) 的手册页时，我发现了一个更有趣的功能，但又有点通用，就是条件子命令。（是的，我确实在读手册页，而且我神奇地通过这种方式学到了很多东西！）。这个 condition子命令能用来测试 systemd 单元文件中的条件和断言。

它也可以在脚本中用来评估一个或多个条件 —— 如果所有条件都满足，则返回 0；如果有条件不满足，则返回 1。在其它情况下，它都会输出其结果文本。

下面的例子来自手册页，稍微有点复杂。它测试了内核版本是否在 4.0 和 5.1 之间，主机是否使用交流电供电，系统结构是否是 ARM，以及 /etc/os-release目录是否存在。我添加了echo $?来打印返回值。

[root@david ~]# systemd-analyze condition 'ConditionKernelVersion = ! =5.1' \ 'ConditionACPower=|false' \ 'ConditionArchitecture=|!arm' \ 'AssertPathExists=/etc/os-release' ; \ echo $? test.service: AssertPathExists=/etc/os-release succeeded. Asserts succeeded. test.service: ConditionArchitecture=|!arm succeeded. test.service: ConditionACPower=|false failed. test.service: ConditionKernelVersion=>=5.1 succeeded. test.service: ConditionKernelVersion=!

条件和断言的列表大约从 systemd.unit(5) 手册页的第 600 行左右开始。

列出配置文件

systemd-analyze工具提供了一种将各种配置文件的内容发送到 STDOUT 的方法，如图所示。其基本目录是/etc/。

[root@david ~]# systemd-analyze cat-config systemd/system/display-manager.service # /etc/systemd/system/display-manager.service [Unit] Description=LXDM (Lightweight X11 Display Manager) #Documentation=man:lxdm(8) Conflicts=getty@tty1.service After=systemd-user-sessions.service getty@tty1.service plymouth-quit.service livesys-late.service #Conflicts=plymouth-quit.service [Service] ExecStart=/usr/sbin/lxdm Restart=always IgnoreSIGPIPE=no #BusName=org.freedesktop.lxdm [Install] Alias=display-manager.service [root@david ~]#

打了这么多字却和标准的 cat命令做的差不多。我发现下一条命令小有帮助，它能在标准的 systemd 所在的位置搜索具有指定模式的内容：

[root@david ~]# systemctl cat backup* # /etc/systemd/system/backup.timer # This timer unit runs the local backup program # (C) David Both # Licensed under GPL V2 # [Unit] Description=Perform system backups Requires=backup.service [Timer] Unit=backup.service OnCalendar=*-*-* 00:15:30 [Install] WantedBy=timers.target # /etc/systemd/system/backup.service # This service unit runs the rsbu backup program # By David Both # Licensed under GPL V2 # [Unit] Description=Backup services using rsbu Wants=backup.timer [Service] Type=oneshot Environment="HOME=/root" ExecStart=/usr/local/bin/rsbu -bvd1 ExecStart=/usr/local/bin/rsbu -buvd2 [Install] WantedBy=multi-user.target [root@david ~]#

这两个命令在每个文件的内容前面都有一个注释行，包含文件的完整路径和名称。

单元文件检查

当创建了一个新的单元文件，可以利用 verify子命令帮助检查语法是否正确。它能指出来不正确的拼写，并列出缺失的服务单元。

[root@david ~]# systemd-analyze verify /etc/systemd/system/backup.service

秉承 Unix/Linux 的“沉默是金”的宗旨，没有输出意味着扫描的文件中没有错误。

安全性

security子命令检查指定服务的安全级别。它只能针对服务单元，其他类型的单元文件不起作用：

[root@david ~]# systemd-analyze security display-manager NAME DESCRIPTION > ✗ PrivateNetwork= Service has access to the host's network > ✗ User=/DynamicUser= Service runs as root user > ✗ CapabilityBoundingSet=~CAP_SET(UID|GID|PCAP) Service may change UID/GID identities/capabilities > ✗ CapabilityBoundingSet=~CAP_SYS_ADMIN Service has administrator privileges > ✗ CapabilityBoundingSet=~CAP_SYS_PTRACE Service has ptrace debugging abilities > ✗ RestrictAddressFamilies=~AF_(INET|INET6) Service may allocate Internet sockets > ✗ RestrictNamespaces=~CLONE_NEWUSER Service may create user namespaces > ✗ RestrictAddressFamilies=~… Service may allocate exotic sockets > ✗ CapabilityBoundingSet=~CAP_(CHOWN|FSETID|SETFCAP) Service may change file ownership/access mode/capabilities unres> ✗ CapabilityBoundingSet=~CAP_(DAC_*|FOWNER|IPC_OWNER) Service may override UNIX file/IPC permission checks > ✗ CapabilityBoundingSet=~CAP_NET_ADMIN Service has network configuration privileges > ✗ CapabilityBoundingSet=~CAP_SYS_MODULE Service may load kernel modules ✗ CapabilityBoundingSet=~CAP_SYS_TTY_CONFIG Service may issue vhangup > ✗ CapabilityBoundingSet=~CAP_WAKE_ALARM Service may program timers that wake up the system > ✗ RestrictAddressFamilies=~AF_UNIX Service may allocate local sockets > → Overall exposure level for backup.service: 9.6 UNSAFE ? lines 34-81/81 (END)

是的，表情符是输出的一部分。但是，当然，许多服务需要几乎完全访问所有的东西，以便完成它们的工作。我针对几个服务运行了这个程序，包括我自己的备份服务；结果可能有所不同，但最底下一行似乎大多是一样的。

这个工具对于在严格的安全环境检查和修复用户空间的服务单元是很有用的。我不认为我们的大多数都能用到它。