Linux 服务启动变慢：用 critical-chain 找到阻塞单元

一台 Linux 主机重启后，SSH 已经能连上，但应用服务要过几十秒才真正可用。先别急着把所有服务都禁掉：systemd 可能只是按依赖顺序等待某个单元，真正需要找的是“谁在关键链上拖住了默认目标”。

systemd-analyze time 先看启动总账，systemd-analyze blame 找耗时单元，systemd-analyze critical-chain 再确认哪些耗时确实位于目标依赖链；三者不能互相替代。

先把“开机慢”拆成四段时间

在问题主机上先执行下面两条命令，保存原始输出。第一条给出 systemd 看到的启动总耗时，第二条按单元的激活时间排序：

systemd-analyze time
systemd-analyze blame | head -20

systemd-analyze time 会把内核、initrd、userspace 和进入启动目标的时间分开。若 userspace 很长，才进入服务依赖排查；如果内核或 initrd 占大头，继续改 unit 文件通常不会改变结论。

blame 适合建立候选名单，不适合直接宣布根因。一个单元可能启动很慢，却没有挡住你的应用；另一个单元可能本身耗时不长，但在链上被前置依赖卡住。

用 critical-chain 追真正的等待路径

默认目标可以直接查看：

systemd-analyze critical-chain

输出里的 @ 表示单元变为 active 或 started 的时间，+ 表示它自身花费的启动时间。比如下面这条链里，应用目标在等网络在线目标，而网络在线目标又在等 systemd-networkd-wait-online.service：

multi-user.target @47.820s
└─network-online.target @33.712s
  └─systemd-networkd-wait-online.service @12.804s +20.905s
    └─systemd-networkd.service @11.109s +1.690s

这时应该先核对网络等待是否真的是业务必需，而不是看到服务名就直接屏蔽。指定单元可以缩小范围，例如：

systemd-analyze critical-chain my-api.service

图中从 systemd-analyze time 到 critical-chain 的路径对应的是排查顺序，不是又一份启动日志。阅读链条时，目标单元在上方，依赖单元逐层向下；带有明显 + 数值且位于这条链上的单元，才值得优先验证。

为什么 blame 排名第一不一定是阻塞点

systemd 会并行启动许多单元，所以 blame 的第一名只是“自身激活耗时最长”。手册还特别提醒，socket activation、并行执行，以及从未进入 activating 状态的设备单元，都可能让 critical-chain 与 blame 呈现不同视角；超时 job 也不会完整出现在关键链里。

从 unit 依赖字段核对“为什么要等”

关键链确定候选后，查看目标服务的排序与依赖字段：

systemctl show my-api.service \
  -p After -p Wants -p Requires -p JobRunningTimeoutUSec
systemctl list-dependencies --all my-api.service

After= 只表达启动顺序，不会单独拉起另一个单元；Requires= 和 Wants= 才涉及依赖关系。把这几个字段混为一谈，很容易为了“提速”删掉排序约束，结果让应用在依赖尚未准备好时提前启动。

如果链条落在 network-online.target，再检查网络管理器提供的等待服务、网卡是否拿到地址，以及应用是否真的需要网络就绪。可先看：

systemctl status systemd-networkd-wait-online.service
systemctl is-active network-online.target
systemctl show my-api.service -p After -p Wants

这里的核对目标是“依赖是否有理由存在”。不要只改 After= 的顺序；如果应用启动后会立刻连接数据库或注册服务，正确做法往往是保留顺序，同时把应用自己的重试和健康检查写清楚。

修复后怎样做一次可复现复查

修改 unit 配置后，先让 systemd 重新读取文件，再只重启相关服务做局部验证：

sudo systemctl daemon-reload
sudo systemctl restart my-api.service
systemctl is-active my-api.service
systemctl show my-api.service -p ActiveEnterTimestamp -p SubState

确认局部服务正常后，再安排完整重启做冷启动对照。复查记录至少保留四项：systemd-analyze time 的总账、目标服务的 critical-chain、修改前后的 unit 字段，以及应用健康检查的结果。只看到启动秒数下降，还不能说明依赖改对了。

若只是某个网络等待服务偶发超时，先查 DHCP、DNS、链路和网卡状态；若业务本身不需要网络在线目标，也应通过清晰的 unit 依赖表达这一点。生产环境不要直接删除发行版提供的 unit，优先使用 drop-in 配置，并为回滚保留原文件。

常见问题

critical-chain 输出的最大加号就是总启动时间吗？

不是。它展示指定目标的时间关键依赖链，服务可能并行启动，链外耗时不会简单相加。总时间应回到 systemd-analyze time 核对。

blame 第一名很慢，应该马上禁用它吗？

不应该。先用 critical-chain 确认它是否挡住目标，再用 systemctl show 看依赖和排序关系。无关单元即使耗时高，也可能不影响应用可用时间。

After= 能保证依赖服务启动成功吗？

不能。After= 只规定顺序；是否建立依赖以及失败时的联动，要看 Requires=、Wants= 等字段和服务自身的状态检查。

为什么 critical-chain 没显示某个超时任务？

关键链主要记录进入 activating 状态的单元耗时，手册说明部分 job 超时和直接从 inactive 到 active 的设备单元不会完整呈现。此时应结合 systemctl status 和启动日志继续核对。

小结

排查 systemd 启动变慢，最短路径是先看总账，再看单元排行，最后沿目标服务的 critical-chain 核实等待关系。修复动作要落到真实依赖字段和可回滚的 drop-in 配置，复查时同时看 systemd 时间、unit 状态和应用健康检查，才不会把“启动数字变小”误当成问题已经解决。