Linux 服务启动慢怎么定位：After、Requires 与启动时间线的核对方法

Linux 服务启动变慢，很多人第一反应就是自家程序写得烂、初始化逻辑拖慢了整体进度。实际排查下来就会发现，依赖排序错误、网络就绪时机没对齐、远端挂载点等待和服务自身初始化耗时往往叠在同一条启动链上混在一起。先把整条启动时间线拆解开，再判断是改启动顺序、补全依赖规则还是优化程序逻辑，通常比直接把服务超时阈值调大要靠谱得多。

先区分“单元耗时”和“启动链被阻塞”

看到某个服务在 systemd-analyze blame 中排第一，并不等于它就是系统启动的关键瓶颈。这个命令展示的是各单元自身从开始到完成的大致耗时；如果它与目标服务不在同一条关键链上，优先优化它可能没有收益。

systemd-analyze blame
systemd-analyze critical-chain your-app.service
systemctl status your-app.service --no-pager
journalctl -b -u your-app.service --no-pager

第一条命令用来做启动单元耗时排序，第二条命令能直接定位“哪个单元在等另一个单元”，剩下两条则用来确认单元实际状态和对应运行日志。排查时建议先把整套命令的完整输出存一份本地备份，不要边看数据边反复重启机器，免得把多次不同启动的耗时数据混在一起，反而找不到准确根因。

用同一条启动时间线定位等待点

critical-chain 输出中的箭头和时间标记比单纯的耗时排行更有价值。若服务等待 network-online.target，要继续追到具体的网络管理单元；若等待挂载点，则检查对应的 mount unit；若依赖已完成但进程仍长时间没有进入 ready 状态，才把重点转向应用初始化。

时间线里出现几秒到几十秒的空白空档时，优先去看空档前最后一个运行单元的完整日志。空档基本都不是“没有日志输出”，而是某个同步调用逻辑正在后台等待设备响应、网络返回或者子进程退出。

After、Requires 和 Wants 分别解决什么问题

这三个配置项经常被写在同一段 service 配置块里，实际表达的语义完全不一样：

• After=foo.service：如果两个单元都被启动，当前单元排在 foo.service 后面；它本身不会自动拉起 foo.service。
• Requires=foo.service：当前单元需要 foo.service，依赖失败或被停止时，当前单元也会受到影响。
• Wants=foo.service：表达较弱的拉起意图，被希望的单元失败时，当前单元通常仍可继续。

因此，“必须先启动数据库”通常需要把依赖关系和顺序关系一起写清楚；只写 After=database.service，可能得到一个顺序正确但数据库根本没有被拉起的配置。反过来，只写 Requires= 也不保证两个单元按业务需要的先后完成。

用 drop-in 做最小改动并核对最终配置

不要直接修改发行版或者第三方软件包自带的 unit 配置文件。用 drop-in 配置的方式可以完整保留原有默认配置，后续改坏了回滚也非常方便：

sudo systemctl edit your-app.service

举个例子，如果你的服务确实需要等网络管理器完全就绪之后再启动，可以在编辑器里写入对应规则：

[Unit]
Wants=network-online.target
After=network-online.target

配置写完之后先让 systemd 重新载入全部配置，再检查合并之后的最终配置结果是否符合预期：

sudo systemctl daemon-reload
systemctl cat your-app.service
systemctl show your-app.service -p After -p Wants -p Requires
systemctl restart your-app.service
systemctl status your-app.service --no-pager

这里的重点是 systemctl cat 和 systemctl show。前者能看到主文件与 drop-in 的来源，后者能看到管理器实际采用的属性。只看编辑器里的片段，无法确认是否被其他 drop-in 覆盖。

重启后用日志和关键链复测

改动后不要只看服务变成了 active (running)。需要同时确认启动时间、依赖状态和应用是否真的可用：

systemd-analyze critical-chain your-app.service
journalctl -b -u your-app.service -o short-monotonic --no-pager
systemctl is-active your-app.service
systemctl is-enabled your-app.service

short-monotonic 便于对照本次启动的相对时间。若服务状态正常但首个请求仍失败，说明“进程已启动”和“业务已就绪”之间还有一道边界，应检查应用的健康检查、端口监听或内部迁移任务，而不是继续增加 unit 顺序。

几个容易把问题越改越复杂的做法

把 blame 排名当成最终结论

blame 输出只是耗时单元的候选列表，不能直接当因果结论。必须再用 critical-chain 命令和对应服务日志交叉确认，才能判定这个单元是不是真的阻塞了你要排查的目标服务。

只写 After，不写真实依赖

这会造成“等待对象根本没被拉起”的假象。按照业务实际要求，选择用 Requires 或者 Wants 配置依赖拉起规则，再补全对应的 After 排序规则就可以解决。

直接把 TimeoutStartSec 调得很大

单纯把超时阈值改大只会延后故障暴露的时机。先区分耗时来自设备等待、网络等待还是程序本身初始化，再判断是否真的需要调整超时常量。

常见问题

为什么服务已经 active，依赖服务却没有启动？

这种情况基本是只配置了 After 排序规则。它只能保证执行先后顺序，不会自动帮你拉起对应的依赖单元；需要结合业务语义补上 Wants 或者 Requires 配置。

critical-chain 比 blame 更可靠吗？

两个命令输出回答的是不同维度的问题。blame 适合快速找到全局范围内的高耗时单元，critical-chain 适合精准定位目标服务真正在等待的完整链路，排查过程里搭配使用效率更高。

改完 drop-in 后为什么状态没有变化？

遇到配置修改不生效的情况，先检查有没有执行 daemon-reload 重载配置，再用 systemctl cat 命令确认配置文件的加载来源；如果改完配置之后没有重启对应服务，还需要手动重新触发一次启动流程才能观察到新的时间线数据。

一份可复用的启动排查清单

1. 保存 systemd-analyze blame 和目标服务的 critical-chain。
2. 用 journalctl -b -u 对齐空档和错误。
3. 判断当前问题属于依赖排序错误、依赖未自动拉起、外部资源等待还是程序本身初始化逻辑耗时。
4. 用 drop-in 配置做最小范围的修改，同步记录修改前后的完整配置内容。
5. 执行 daemon-reload 重载、重启目标服务，复测运行状态、日志、关键链耗时和真实业务就绪条件是否满足预期。

启动排查的核心目标不是让所有服务都尽可能早地启动，而是让 systemd 里写的依赖关系和实际业务边界完全对齐。只要完整保留修改来源、复测命令和结果，后续系统升级或者配置回滚的时候，就不用再重复排查一遍同样的问题。