systemd不能解决断电瞬间的硬件上电问题，仅在服务器重启后按依赖关系和Restart策略自动拉起服务；需用After/Wants声明依赖、Restart=on-failure防雪崩、ExecStartPre健康检查确保就绪。
脚本不能真正“自动恢复”断电后的服务——先明确边界
断电后服务器全部下电，systemd 或任何用户态脚本都不存在运行基础。所谓“自动拉起”，实际是指：UPS 延时供电期间或市电恢复、服务器完成 BIOS/UEFI 自检、内核加载、systemd 启动后，由初始化系统按依赖关系和服务配置，逐批启动服务。脚本本身不解决“断电瞬间状态保存”或“硬件上电控制”，只参与 systemd 启动阶段的顺序编排。
用 systemd 的 Wants/After/Requires 控制服务启动依赖
核心不是写 shell 脚本轮询等待，而是通过 .service 单元文件声明依赖关系。常见错误是把“数据库要等网络通”写成 sleep 10 或 ping -c3，这不可靠且违反 systemd 设计哲学。
-
After=network.target表示本服务在network.target**达到 active** 状态后才开始启动（但不保证网卡已获取 IP） -
Wants=postgresql.service表示“我期望它也启动”，但不阻塞；若加After=postgresql.service，则必须等 PostgreSQL 完全 ready 才继续 - 真正要等数据库就绪，应配合
Type=notify+postgresql的 systemd 集成，或使用ExecStartPre=/usr/bin/pg_isready -U postgres -d template1 - 避免循环依赖：
A Wants=B; After=B与B Wants=A; After=A会导致systemd启动失败并报错Found ordering cycle
关键服务需设置 Restart=on-failure 与 StartLimitIntervalSec
断电恢复过程中，依赖服务（如 etcd、consul、redis）可能因网络未稳或存储延迟而短暂启动失败。默认 systemd 只试一次就标记 failed，后续服务全卡住。
- 在服务单元中添加：
Restart=on-failure<br>RestartSec=5<br>StartLimitIntervalSec=60<br>StartLimitBurst=3
- 这意味着：1 分钟内最多重试 3 次，每次间隔 5 秒；超过则停止尝试，避免无限拉起失败
- 注意：
Restart=always在数据库类服务上很危险——崩溃后反复重启可能加剧磁盘损坏
跨主机依赖无法靠单机 systemd 解决——得用外部协调
比如 A 机器的 API 服务必须等 B 机器的 Kafka 集群完全选举完毕才能启动。systemd 无跨节点感知能力，硬写 ssh b-host systemctl is-active kafka.service 属于反模式（SSH 密钥、超时、防火墙都会破环可靠性）。
- 可行做法：Kafka 启动后向 Consul 注册健康端点（如
/v1/health/service/kafka），API 服务用ExecStartPre=/usr/bin/curl -f http://consul:8500/v1/health/service/kafka?passing - 更健壮方案：用
systemd-run --scope启动一个临时监听器，watch ZooKeeper 节点或 Kafka Admin API，再触发本地服务启动 - 切忌在
ExecStartPre中调用长时阻塞命令（如无 timeout 的 curl）——会卡死整个启动队列
真正难的不是写几行 systemctl start，而是厘清哪些状态必须由服务自身报告（如 pg_isready）、哪些需外部系统仲裁（如 etcd member health）、哪些其实可以异步容忍（如日志收集 agent 晚 2 分钟启动）。断电恢复的“顺序”，本质是把隐式依赖显式编码进单元文件和健康检查里，而不是靠脚本里的 sleep 和 for 循环硬凑。
