服务器重启后服务启动顺序乱了：依赖声明

发布时间:2026-01-19 17:32

## 症状 机器重启后，应用服务起来了却连不上数据库；或者网关先于后端启动，健康检查失败被拉起又退出。手动逐个重启一遍就恢复正常，问题只在开机时出现，每次顺序还不完全一样。这类故障的根因不是服务本身，而是启动顺序没有被系统化地声明，全凭调度运气。 ## 定位 先看服务状态与日志时间线：应用报连接失败的时间早于数据库就绪的时间，顺序问题即坐实。再查两个服务的 unit 文件，看依赖声明是缺失还是写错了方向。systemd 的默认行为是并行启动，没有声明依赖的服务，谁先谁后完全不确定，机器快时碰巧对，机器慢时必然错。用下面的命令确认实际生效的依赖关系。 ``` systemctl list-dependencies myapp.service ``` 输出里看不到数据库单元，说明依赖根本没建立，问题就在这里。 ## 解决 在应用的 unit 文件里补上依赖声明，这是系统化的解法，而不是把服务塞进某个启动脚本的土办法。 ``` [Unit] After=network-online.target mysql.service Wants=network-online.target Requires=mysql.service ``` After 只约束顺序，Requires 才约束绑定：数据库起不来，应用也不该启动。改完执行 daemon-reload，然后做一次真实重启验证，观察两个服务的启动时间线是否按预期排序。网络类依赖还有个细节：网络接口已启用与网络真正可用是两回事，业务服务应挂在网络在线目标之后而不是基础网络服务之后，这个差别在高负载的开机时刻会显形。顺云云服务器上部署多服务依赖链时，把这套声明写进部署模板，新机器初始化就不再依赖人工记忆顺序。 ## 预防 新增服务时先画一张简单的依赖图，数据库、缓存、网关、应用谁依赖谁，一张图胜过十次排错。unit 文件纳入版本管理，依赖声明随代码一起评审。每次模板变更后做一次重启演练，开机顺序这类问题，不重启永远发现不了。