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 验证最终效果。 
