linux服务启动顺序错误本质是依赖关系未显式声明或未被正确解析；systemd依据requires、after等指令构建启动图，需用daemon-reload重载配置并用list-dependencies、show等命令验证依赖。
Linux服务启动顺序错误，本质是依赖关系未被正确声明或系统未按预期解析依赖链。关键不在“谁先谁后”，而在“谁等谁”。
systemd 依赖声明必须显式定义
systemd 不按文件名或目录顺序启动服务，而是依据 WantedBy、Requires、After 等单元指令构建启动图。若 A 服务需在 B 启动后运行，仅把 A 放在 /etc/systemd/system/multi-user.target.wants/ 下毫无意义。
- Requires=B.service 表示强依赖：B 启动失败则 A 不启动
- After=B.service 仅控制顺序，不隐含依赖；需配合 Requires 或 Wants 才生效
- Wants=B.service 是弱依赖，B 启动失败不影响 A，但建议与 After 共用以确保时序
检查实际启动顺序与依赖图
运行 systemctl list-dependencies --after --reverse multi-user.target 可查看 multi-user.target 下所有服务的“应在之后启动”的依赖关系。更直观的方式是：
- 用 systemctl show -p After,Requires,Wants,Conflicts service-name 查单个服务的依赖字段
- 用 systemd-analyze plot > boot.svg 生成启动时序图（需安装 graphviz）
- 用 systemd-analyze critical-chain service-name 追踪该服务从启动到就绪的完整依赖路径
常见陷阱：网络、存储、配置加载时机
很多服务失败表面是“启动太早”，实则是没等对目标。例如：
- 应用服务连不上数据库 → 应 After=postgresql.service + Wants=postgresql.service，而非只等 network.target
- 服务读取 NFS 挂载的配置 → 需 After=remote-fs.target，不能只依赖 local-fs.target
- 自定义脚本依赖 /etc/myapp/config.yaml → 若该文件由另一服务生成，应明确 After=generator.service 并 Wants=generator.service
覆盖默认单元文件时务必重载并验证
修改 .service 文件（包括 drop-in 片段）后，必须执行：
- systemctl daemon-reload（否则改动不生效）
- systemctl cat service-name 确认最终合并后的单元内容
- systemctl is-active service-name 和 systemctl status service-name 观察实际状态与日志
不要假设“改完保存就自动生效”。systemd 缓存单元信息，漏掉 reload 是启动链错乱最常被忽略的原因。
