Linux 启动时间为何和耗时列表对不上：critical-chain 关键路径读法

服务器重启完，SSH 能正常连上，业务应用却要等十几秒才能对外提供服务，很多人第一反应会误判“这个应用本身启动慢”。实际Linux系统里服务管理器的整个启动流程，大多是不同单元的依赖链在依次等待：目标单元卡着等网络就绪，上层应用单元又在等存储挂载或者身份凭据加载，最后拖慢整体体验的卡点，很可能根本不在应用自身的执行逻辑里。先执行一条命令把整条关键依赖链路打印出来，再决定后续是排查服务日志还是调整依赖配置，排查效率会高很多。

顺着启动的关键依赖链定位卡点，再用单元状态、启动日志、全量耗时统计交叉验证，就能直接区分出依赖顺序问题、服务自身初始化问题两类不同的根因。

先把“应用慢”拆解成完整启动链

在搭载Linux服务管理器的主机上，先执行下面这条命令：

systemd-analyze critical-chain

典型的输出内容大概是这样：

graphical.target @18.902s
└─app-gateway.service @18.760s +12.400s
  └─network-online.target @6.210s
    └─systemd-networkd-wait-online.service @2.100s +4.030s

从输出的末尾往上捋，network-online.target 先执行完成，app-gateway.service 在6秒左右就满足了全部启动前置条件，却额外花了12.4秒才进入active状态。这个结果说明“网络等待”和“应用自身初始化”是两个完全独立的问题，不能把整条链路加起来的18.9秒耗时全部归为应用的问题。

时间线里最容易被误读的两个数值

@ 后面标注的时间是单元进入active状态的相对时间，+ 后面标注的时间是该单元自身启动阶段消耗的时长。如果前置单元完成时间很晚，会把所有后续单元的启动时间整体往后推；要是后续单元的 + 数值偏大，基本可以判断是它自身的初始化、探活逻辑或者外部依赖访问在等待。

按三条证据线确认根因

第一条：确认实际的单元状态

systemdctl status app-gateway.service --no-pager
systemdctl show app-gateway.service \
  -p ActiveState -p SubState -p After -p Wants

重点查看 ActiveState、SubState 和完整的依赖列表。服务显示active仅代表它已经进入运行状态，不代表业务请求已经完成预热可以正常处理；如果状态在启动阶段反复切换，还要继续排查重试策略和退出原因。

第二条：单独拉取本次启动的日志

journalctl -b -u app-gateway.service --no-pager
journalctl -b -u systemd-networkd-wait-online.service --no-pager

-b 把日志范围锁定到本次启动周期，避免旧日志干扰判断方向。如果应用日志在6秒时已经开始加载配置，直到18秒才打印出ready标识，卡点就在服务初始化环节；如果应用一直没有输出日志，反而网络等待类服务迟迟没有结束执行，优先排查网络依赖和链路质量。

第三条：用总耗时做交叉验证

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

critical-chain 侧重展示启动关键路径，blame 更偏向按启动耗时罗列所有单元。两者结果不一致是正常情况：某个单元自身启动很慢，却不一定处在当前目标的关键等待链上。把两个结果和日志里的时间戳放在一起对照，才能确认它是不是真的拖慢了用户侧的可用时间。

修复时先区分顺序问题和初始化问题

如果日志能证明服务确实需要网络、挂载或者密钥文件，且当前的依赖声明确实缺失，才考虑补充正确的依赖关系。调整完成后要执行单元重载、重新启动，再次采集并核对critical-chain结果；单纯把某个单元的启动优先级往前调，很可能制造出新的资源竞态问题。

systemdctl daemon-reload
systemdctl restart app-gateway.service
systemd-analyze critical-chain app-gateway.service

如果服务已经配置在正确的依赖之后启动，但自身的 + 时长仍然偏高，就应该逐一检查配置扫描、证书读取、数据库连接、缓存预热和启动探活这些环节。生产环境更稳妥的做法是先采集一次冷启动和一次重复启动的日志，再做小范围的调整验证。

一份可复用的启动验收清单

• 记录 systemd-analyze time 的固件、引导加载器、内核和用户空间各阶段耗时。
• 保存 critical-chain 与 blame 的输出结果，标注用户业务真正依赖的核心单元。
• 对关键服务执行 systemdctl show，确认active/sub状态和生效的依赖关系。
• 使用 journalctl -b -u 对齐“开始初始化”和“ready/失败”的时间戳。
• 配置变更后重新启动验证，确认没有把原本的等待从应用侧转移成新的网络或挂载竞态。

常见问题

critical-chain 能列出所有启动最慢的服务吗？

不能。它展示的是影响目标完成时间的关键依赖链；要查看耗时较高但不一定在关键链上的单元，可以补充使用 systemd-analyze blame。

服务显示 active，为什么接口还不能访问？

active 只代表单元状态已经切换完成，应用可能还在做缓存预热或者等待内部子依赖就绪。判断标准应该以服务自身的ready日志、探活结果和端口监听状态为准。

看到网络等待很慢，能不能直接删掉网络依赖？

不建议这么做。如果应用运行过程中确实需要远端连接，删除依赖只会把故障从启动阶段推迟到运行阶段随机触发。先确认应用是否能容忍网络晚于启动流程就绪，再决定要不要修改启动策略。

为什么两次 critical-chain 的时间不完全一样？

磁盘缓存状态、DNS解析耗时、网络握手时长、设备初始化进度和服务自身的重试逻辑都会造成结果差异。应该在环境相近的条件下重复采集几次，再结合本次启动的日志判断是不是稳定存在的性能瓶颈。

排查Linux服务启动慢的问题，最有价值的不是找出一个最大的耗时数字，而是确认这段等待时间里到底是谁在等谁。把关键依赖链、有效状态信息和本次启动的日志对齐之后，顺序配置问题、服务初始化问题和外部依赖问题通常很快就能区分开。