当前位置：首页 > 文章列表 > 文章 > linux > Linux 服务启动变慢：用 critical-chain 找到阻塞单元

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

来源：17golang原创 2026-08-27 22:12:04 0浏览收藏

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

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

要点速览

先用 systemd-analyze time 区分内核、initrd、用户空间和启动目标的耗时。
critical-chain 输出 @ 后的激活时间和 + 后的启动耗时，重点看从目标向下的最长等待链。
blame 只按单元激活耗时排序，socket 激活、并行启动和超时任务可能让它误导排查。
修复依赖或网络等待后，要用同一组命令复查，并确认应用自己的健康检查已经通过。

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

在问题主机上先执行下面两条命令，保存原始输出。第一条给出 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 的 Linux 启动等待路径，定位 network-online.target 与 systemd-networkd-wait-online.service

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

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

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

命令	回答的问题	不能单独证明什么
`systemd-analyze time`	启动总时间主要花在哪一段	哪个服务挡住应用
`systemd-analyze blame`	哪些单元自身激活较慢	慢单元是否在关键依赖链
`systemd-analyze critical-chain`	目标单元的时间关键依赖链	所有 job 超时和并行成本
`systemctl show`	确认 unit 的依赖与排序字段	应用自身是否健康

从 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= 的顺序；如果应用启动后会立刻连接数据库或注册服务，正确做法往往是保留顺序，同时把应用自己的重试和健康检查写清楚。

Linux systemd 关键链中 systemd-networkd-wait-online.service 的等待与修复后 systemctl show 复查

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

修改 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 状态和应用健康检查，才不会把“启动数字变小”误当成问题已经解决。