Linux服务启动依赖关系_顺序控制说明【指导】

systemd 服务启动顺序由 Wants/After 等依赖声明控制，而非文件名排序；需用 drop-in 机制修改依赖，通过 list-dependencies 验证实际生效的依赖关系。

systemd 服务启动顺序由 Wants/After 控制，不是靠文件名排序

很多人以为把服务文件名改成 01-redis.service、02-mysql.service 就能控制启动顺序——这在 systemd 下完全无效。systemd 不解析文件名，只认单元（unit）之间的显式依赖声明。

真正起作用的是 Wants= 和 After=（或 Requires= + After=）组合：

• Wants=redis.service 表示“希望 redis 启动”，但不强制；失败也不阻塞当前服务
• Requires=redis.service 表示“必须启动 redis”，失败则当前服务启动失败
• After=redis.service 表示“本服务应在 redis 启动完成后才开始启动”，仅控制顺序，不隐含依赖关系
• 单独写 After= 没有意义，必须搭配 Wants= 或 Requires= 才生效

如何让 A.service 等待 B.service 完全就绪（不只是启动中）

After= 只保证 B 的 start 调用已发出，不保证它已监听 端口、加载完数据或进入 ready 状态。常见坑是 A 启动后立刻连 B 的端口，结果连接被拒。

解决方法 分两类：

• 若 B 是标准 systemd 服务，且正确设置了 Type=notify（如用 systemd-notify --ready），A 可加 BindTo=b.service + After=b.service，并配合 Restart=on-failure 做重试
• 更通用做法：A 的 ExecStart= 前插入健康检查，例如：

  ExecStart=/bin/sh -c 'while ! nc -z localhost 6379; do sleep 1; done; /usr/bin/myapp'

• 避免用 sleep 5 这类固定延时——环境差异大，不可靠

修改已有服务的依赖关系，不要直接改 /usr/lib/systemd/system/

直接编辑系统自带的服务文件（如 /usr/lib/systemd/system/mysql.service）会在下次软件包升级时被覆盖，导致依赖丢失。

正确做法是使用 systemd 的 drop-in 机制：

• 创建目录：sudo mkdir -p /etc/systemd/system/mysql.service.d
• 新建覆盖文件：sudo vim /etc/systemd/system/mysql.service.d/override.conf
• 内容示例（让 mysql 等待网络就绪）：

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

• 执行 sudo systemctl daemon-reload 生效

调试依赖是否生效：用 systemctl list-dependencies 和 show

光看 配置文件 容易误判，实际加载后的依赖图可能受多处 override 影响。验证时优先用运行时命令：

• systemctl list-dependencies --reverse myapp.service 查谁依赖 myapp
• systemctl list-dependencies --all myapp.service 展开全部正向依赖（含间接依赖）
• systemctl show myapp.service | grep -E "WantedBy|RequiredBy|After|Before" 看最终解析出的字段值
• 注意：systemctl status myapp.service 显示的“Loaded:”行末尾若有 overridden，说明有 drop-in 文件在起作用

真实环境中，After= 和 Wants= 的组合漏写一项、或写错服务名（比如写成 redis-server.service 而实际是 redis.service），都会导致静默失效——既不报错，也不按预期顺序启动。务必用 list-dependencies 验证最终效果。