systemd-analyze命令：Linux系统启动分析

一、命令简介

• 用途: systemd-analyze ​命令用于分析系统引导过程的时间性能。
• 标签: 系统管理，性能分析。
• 相关命令: systemd-bootchart​, systemd-cgtop​, systemd-resolve​.

‍

二、命令参数

命令格式

systemd-analyze [OPTIONS...] COMMAND ...

选项和参数

systemd-analyze [OPTIONS...] COMMAND ...

系统分析，显示单元依赖关系，检查单元文件。

命令：
  [time]                   打印启动系统所需的时间
  blame                    按初始化时间排序打印正在运行的单元列表
  critical-chain [UNIT...] 打印单元的关键时间链的树形结构
  plot                     输出显示服务初始化的SVG图形
  dot [UNIT...]            输出dot(1)格式的依赖图
  dump                     输出服务管理器的状态序列化
  cat-config               显示配置文件和补充配置
  unit-files               列出单元的文件和符号链接
  unit-paths               列出单元的加载目录
  exit-status [STATUS...]  列出退出状态的定义
  capability [CAP...]      列出能力的定义
  syscall-filter [NAME...] 打印seccomp过滤器中的系统调用列表
  condition CONDITION...   评估条件和断言
  verify FILE...           检查单元文件的正确性
  calendar SPEC...         验证重复的日历时间事件
  timestamp TIMESTAMP...   验证时间戳
  timespan SPAN...         验证时间跨度
  security [UNIT...]       分析单元的安全性

选项：
  -h --help                显示此帮助信息
     --version             显示软件包版本
     --no-pager            不要将输出传送到分页器
     --system              在系统 systemd 实例上操作
     --user                在用户 systemd 实例上操作
     --global              在全局用户配置上操作
  -H --host=[USER@]HOST    在远程主机上操作
  -M --machine=CONTAINER   在本地容器上操作
     --order               仅在图中显示顺序
     --require             仅在图中显示需求
     --from-pattern=GLOB   仅在图中显示源
     --to-pattern=GLOB     仅在图中显示目标
     --fuzz=SECONDS        还打印比分支中最新完成时间早SECONDS的服务
     --man[=BOOL]          是否检查man页面的存在
     --generators[=BOOL]   是否运行单元生成器（需要权限）
     --iterations=N        显示指定数量的迭代次数
     --base-time=TIMESTAMP 相对于指定时间计算日历时间

详细信息请参阅 systemd-analyze(1) man 页面。

‍

三、命令示例

1 系统启动耗时-概览

systemd-analyze

总时间=内核时间 + 用户时间

​​

‍

2 系统启动耗时-详细

systemd-analyze blame

这个命令会按服务打印出启动所花费的时间，并按照每个服务启动所花费的时间从大到小排序，帮助你识别启动过程中的瓶颈。

​​

可使用 tac 命令，让结果升序排列。

systemd-analyze blame | tac

这样你就可以看到系统启动时，服务启动的顺序了。

   27us blk-availability.service
    6ms update-notifier-motd.service
    6ms snapd.socket
    7ms user-runtime-dir@1000.service
    9ms systemd-update-utmp-runlevel.service
   10ms ufw.service
   10ms plymouth-quit-wait.service
   10ms proc-sys-fs-binfmt_misc.mount
   10ms sys-kernel-config.mount
   11ms sys-fs-fuse-connections.mount
   12ms docker.socket
...
 6.588s fwupd-refresh.service
10.580s apt-daily-upgrade.service
12.108s apt-daily.service

‍

3 特定服务的启动耗时

systemd-analyze critical-chain [unit]

这个命令会显示服务启动的"关键链"，你可以指定一个服务单元来查看它的详细启动耗时和依赖关系。

​​

• 第一个依赖在系统启动后 343ms 启动，最后一个依赖在系统启动后 4.449s 启动。
• 启动 ssh.service 耗时 21ms

‍

4 系统启动耗时-图表

systemd-analyze plot > boot-up.svg

这个命令会生成一个 SVG 图表，显示启动过程中各个服务单元的启动时间和依赖关系。有没有觉得更直观了。

​​

​​

5 系统启动日志-等级设置

systemd-analyze log-level

这个命令可以查看系统启动过程中的日志级别设置。

​​

输出 info​ 表示 systemd 当前的日志级别设置为 info​。这意味着 systemd 将记录有关单元、服务和其他系统组件状态变化的信息性消息。以下是 systemd 支持的不同日志级别的简要概述：

• emerg：系统无法使用。
• alert：必须立即采取行动。
• crit：临界条件。
• err：错误条件。
• warning：警告条件。
• notice：正常但重要的条件。
• info：信息性消息。
• debug：调试级别的消息。

如果你想更改日志级别，可以将上述级别之一作为参数传递给命令。例如，要将日志级别设置为 debug​ 以获取更详细的日志进行故障排除，你可以使用：

systemd-analyze log-level debug

​​

请注意，将日志级别更改为更详细的设置（如 debug​）可能会生成大量日志数据，这可能会影响系统性能并迅速填满日志文件。一旦完成故障排除，请务必将日志级别设置回不那么详细的设置，如 info​ 或 notice​。

查看系统启动日志

可以使用以下任一命令查看系统启动日志

• sudo dmesg
• sudo journalctl -b -0

‍

6 服务的依赖关系

systemd-analyze dot [unit] > /path/to/graph.dot

这个命令可以生成一个服务的依赖关系图，如果你指定了一个服务单元，它将仅生成该服务的依赖关系图。

sudo systemd-analyze dot > /path/to/graph.dot
# 或者，只为特定的服务生成依赖关系图
sudo systemd-analyze dot sshd.service > /path/to/dbus_graph.dot

在这个例子中，/path/to/graph.dot​ 是你希望保存生成的点格式文件的路径。如果你想要生成特定 systemd 单元的依赖关系图，你可以像第二个命令那样指定该单元的名称（例如 dbus.service​）。
一旦你有了这个 .dot​ 文件，你可以使用 Graphviz 工具集来将其转换为可视化的图形格式，比如 PNG 或 SVG。下面是如何使用 dot​ 命令（来自 Graphviz）来转换 .dot​ 文件为 PNG 图片的示例：

# 安装 Graphviz（如果尚未安装）
sudo apt-get install graphviz
# 将 dot 文件转换为 PNG 图片
dot -Tpng /path/to/graph.dot > /path/to/graph.png

这里，/path/to/graph.dot​ 是你之前创建的 dot 文件，/path/to/graph.png​ 是你希望保存生成的 PNG 图片的路径。

​​

最终生成的图像

​​

• 黑色（black） ：表示 “Requires” 关系，即一个服务单元启动需要依赖的其他服务单元。
• 深蓝色（dark blue） ：表示 “Requisite” 关系，这种依赖比 “Requires” 更强，它要求依赖的服务单元必须已经启动成功。
• 深灰色（dark grey） ：表示 “Wants” 关系，这是一个比较弱的依赖关系，表示一个服务单元希望某个其他服务单元也启动，但不是必需的。
• 红色（red） ：表示 “Conflicts” 关系，即一个服务单元与另一个服务单元有冲突，不能同时运行。
• 绿色（green） ：表示 “After” 关系，即一个服务单元需要在另一个服务单元之后启动。

‍

7 查看特定服务的状态

systemd-analyze unit-paths

这个命令显示 systemd​ 单元文件的路径。

​​

这些目录中的单元文件定义了 systemd 如何管理服务和系统资源。通过在这些目录中放置或修改单元文件，系统管理员可以定制和控制系统的行为。

‍

8 安全性检查

systemd-analyze security [unit]

这个命令对指定的服务执行安全性检查，并提供一个关于该服务安全配置的详细报告。

所有单元总览

​​

浏览指定单元

​​

​systemd-analyze security [unit]​ 是一个用于分析和调试 systemd 系统管理器的命令，它特别关注于服务的安全性和沙箱设置。这个命令可以帮助您检查和改善 systemd 服务的安全性。

以下是关于这个命令的一些详细信息和使用方法：

1. 命令功能：

   • 这个命令用于分析指定的服务单元（[unit]​）的安全和沙箱设置。
   • 如果没有指定服务单元，它将分析所有服务单元。
   • 对于每个指定的服务单元，命令将检查其安全设置并提供详细的报告。

2. 输出内容：

   • 输出包括每个服务单元的安全暴露评分，评分范围从 0 到 10。分数越低，表示服务越安全。
   • 输出还会显示每个服务的安全状态，例如“不安全”或“暴露”。

3. 使用示例：

   • 基本使用方式是 systemd-analyze security [unit]​，其中 [unit]​ 是您想要分析的服务单元名称。
   • 例如，systemd-analyze security sshd.service​ 将分析 sshd​ 服务的安全性。

4. 安全强化：

   • 这个命令可以帮助识别服务的潜在安全漏洞或弱点。
   • 根据命令的输出，您可以采取适当的措施来加强服务的安全性。

5. 版本要求：

   • 这个安全审查工具是在 systemd 的版本 240 中添加的，发布于 2018 年 12 月。您需要运行这个版本或更高版本的 systemd 才能使用这个命令。

分析 nginx 服务的安全问题

​​

• ​PrivateNetwork=​ - 服务可以访问主机的网络。这可能会增加安全风险，因为它可能允许服务与不受信任的网络进行通信。
• ​User=/DynamicUser=​ - 服务以 root 用户身份运行。这是不推荐的做法，因为它会给服务过多的权限。
• ​CapabilityBoundingSet=~CAP_SET(UID|GID|PCAP)​ - 服务可以更改 UID/GID 身份或捕获网络流量。
• ​CapabilityBoundingSet=~CAP_SYS_ADMIN​ - 服务具有管理员权限，这是一个非常高的权限级别，可能会带来严重的安全风险。
• ​CapabilityBoundingSet=~CAP_SYS_PTRACE​ - 服务具有调试能力，可以跟踪其他进程。

列表继续列出了服务所具有的各种权限和能力，每个权限旁边都有一个分数，表示它的安全暴露程度。这些权限包括但不限于网络配置、文件系统访问、系统调用权限等。
以下是一些关键点：

• ✗ 表示服务缺少推荐的安全设置。
• ✓ 表示服务已经实施了推荐的安全设置。

最后，命令给出了 nginx.service​ 的总体暴露级别为 9.6 UNSAFE 😨，这意味着服务存在多个安全问题，需要立即关注和解决。
为了提高服务的安全性，您应该考虑以下步骤：

1. 限制网络访问：如果服务不需要访问外部网络，应该设置 PrivateNetwork=yes​。
2. 运行非 root 用户：使用 User=​ 和 DynamicUser=​ 指令以非 root 用户身份运行服务。
3. 限制能力集：使用 CapabilityBoundingSet=​ 来限制服务可以执行的系统调用。
4. 应用沙箱设置：使用 ProtectSystem=​, ProtectHome=​, PrivateTmp=​ 等指令来增加服务的隔离性。
5. 限制地址族：使用 RestrictAddressFamilies=​ 来限制服务可以使用的网络协议。

请根据服务的具体需求和安全要求来调整这些设置。在更改任何配置之前，请确保备份原始文件，并在安全的环境中测试更改。

‍