systemd-analyze blame 怎样定位启动慢服务

Linux 开机变慢时，先别急着修改服务配置。systemd-analyze blame 能把正在运行的 unit 按初始化耗时排序，适合快速找出第一批排查对象；但排序靠前不等于它就是根因，因为它可能只是等待另一个依赖完成。更稳妥的做法是先看总耗时，再看 blame，最后用 critical-chain 判断这段耗时是否真的挡住了目标 target。

官方地址：https://www.freedesktop.org/software/systemd/man/latest/systemd-analyze.html

定位启动慢服务的核心不是“找出最长的一行”，而是把耗时排序和依赖链放在一起看：长耗时单元负责提供线索，关键链负责判断它是否影响了启动目标。

先确认慢在内核、initrd 还是 userspace

第一步先看启动时间的阶段分布。这样可以避免在 userspace 服务里排查半天，却发现主要时间花在内核或 initrd。

# 先查看固件、内核、initrd 与 userspace 的启动时间分布
systemd-analyze time

输出通常会把几个阶段拆开，并给出到达某个 target 的时间。它回答的是“时间花在哪个大阶段”，还没有回答“哪个 unit 最值得看”。如果 userspace 明显偏长，再进入下一步。

用 blame 找出最值得先看的 unit

blame 会按 unit 的初始化耗时排序。为了先缩小范围，可以只看前 15 行；这只是阅读结果的截取，不会改变 systemd 的统计。

# 按 unit 初始化耗时排序，只保留前 15 个线索
systemd-analyze blame | head -n 15

18.421s systemd-networkd-wait-online.service
 6.804s backup-index.service
 2.116s containerd.service
 1.407s systemd-udev-settle.service

这里先记录两件事：耗时值和 unit 名称。比如 systemd-networkd-wait-online.service 排在前面，只能说明它在激活阶段花的时间较多，不能直接说明它“单独拖慢了所有服务”。它可能在等待网络条件满足，而其他 unit 与它并行启动。

再用 critical-chain 判断它是不是关键阻塞点

下一步看默认 target 的关键链。它会以树形关系显示 unit 的启动时间位置：@ 后面是该 unit 被激活或启动的时间点，+ 后面是它自身的启动耗时。

# 查看默认 target 的时间关键链，确认耗时是否位于阻塞路径
systemd-analyze critical-chain

multi-user.target @31.200s
└─backup-index.service @24.396s +6.804s
  └─local-fs.target @10.102s
    └─systemd-networkd-wait-online.service @8.421s +18.421s

如果一个服务在 blame 中很慢，却不在你关心的 target 关键链上，它可能只是并行启动中的一个长任务；如果它同时出现在关键链上，才值得优先核对依赖、等待条件和服务本身的初始化逻辑。也可以指定某个 unit，让问题范围更小：

# 指定目标服务，沿它的关键依赖链查看时间关系
systemd-analyze critical-chain backup-index.service

回到 unit 定义核对“慢”的来源

确定排查对象后，再看服务状态、实际加载内容和关键属性。三条命令回答的问题不同：status 看当前状态与最近日志，cat 看 unit 文件及 drop-in，show 适合读取结构化属性。

# 查看当前状态和最近日志，先确认是否反复重启或等待失败
systemctl status backup-index.service

# 查看 systemd 实际加载的 unit 与 drop-in 内容
systemctl cat backup-index.service

# 读取类型、依赖和启动时间等结构化属性
systemctl show backup-index.service \
  -p Type -p After -p Wants -p ActiveEnterTimestamp

重点检查 Type=、After=、Wants= 以及是否有网络、挂载或设备相关依赖。不要只盯着一行耗时就删除依赖；先确认它是否是服务正常工作的前置条件。

几个容易误判的边界

因此，复查时至少保留一组“总时间 + blame 排序 + critical-chain”的对应关系，再结合 unit 定义判断修复方向。这样得到的是可解释的排查证据，而不是把一次启动样本直接当成性能结论。

常见问题

为什么 blame 显示的服务很慢，启动却不一定慢？

因为 systemd 可以并行启动多个 unit，某个 unit 的激活时间可能主要来自等待依赖。是否影响目标启动，要看它有没有落在对应的 critical-chain 上。

只运行 systemd-analyze blame 就够了吗？

不够。它适合排序和缩小范围；关键链、unit 文件、依赖属性和最近日志共同决定下一步怎么查。

最后的判断

systemd-analyze blame 最适合做第一轮“候选发现”：先找耗时靠前的 unit，再用 critical-chain 判断它是否挡住目标，最后回到 systemctl 核对配置和状态。记住它统计的是 unit 初始化耗时，不是完整启动因果图，定位结果才不会被一个醒目的秒数带偏。