关键是在启动前主动检查依赖服务是否就绪：先用 systemctl 验证 systemd 层状态（is-active、show），再用 ss/nc/curl/test 检查业务级可达性；预检失败立即退出并输出明确提示；结果记录日志并支持告警联动。
运维脚本捕获“依赖服务未启动”的错误，关键不是等主服务失败后去翻日志，而是在启动前主动检查、明确验证、分层告警。Linux 下多数依赖问题其实发生在 systemd 层面（如 Requires、Wants 未满足），或业务逻辑层面（如主服务需连 MySQL 但 mysqld 没起来）。脚本要做的，是把这类隐性依赖显性化、可检测、可反馈。
检查 systemd 依赖状态
直接读取依赖关系并验证目标服务是否 active：
- 用
systemctl list-dependencies --reverse <service></service>获取反向依赖项（即哪些服务依赖当前服务），或查看 unit 文件中Requires=/Wants=列出的服务名 - 对每个依赖服务，运行
systemctl is-active --quiet <dep-service></dep-service>；返回 0 表示 active，非 0 表示未运行（注意：inactive、failed、not-found都算异常） - 配合
systemctl show -p LoadState,ActiveState,SubState <dep-service></dep-service>确认是否加载成功且状态正常，避免因 unit 文件路径错误导致“找不到服务”却误判为“已启动”
验证业务级可达性
systemd 状态只是起点，真正要捕获的是“服务虽 running，但不可用”——比如数据库进程在，但端口没监听，或健康接口返回 503：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 对网络依赖服务（如 Redis、PostgreSQL），用
ss -tuln | grep :port或nc -zv host port -w2测试端口连通性 - 若服务提供 HTTP 健康端点（如
/health），用curl -sfL --max-time 3 http://localhost:port/health | grep -q "status.*up"判断业务就绪 - 对本地 socket 或 Unix domain socket 依赖（如 Docker 的
/var/run/docker.sock），用test -S /path/to/socket && ls -l /path/to/socket验证存在且可访问
在启动主服务前做预检并中断流程
把依赖检查嵌入启动脚本中，失败时立即退出并输出明确提示，不留给 systemd “启动后崩溃”这种难排查场景：
- 写一个函数
check_required_services()，逐个调用上述检查，任一失败则echo "ERROR: dependency $svc not ready" >&2; exit 1 - 在主服务的
ExecStartPre=中调用该脚本（适用于 systemd unit），或在 shell 启动脚本开头直接执行 - 输出信息包含具体缺失项、建议命令（如
sudo systemctl start mysql）和超时时间，方便运维快速响应
记录与告警联动
单纯报错不够，长期运维需要可追溯和自动通知：
- 每次检查结果写入日志文件，格式如：
$(date '+%Y-%m-%d %H:%M:%S'),redis,active,ok或...,mysql,inactive,fail - 连续 N 次检测到同一依赖失败（如 3 分钟内 5 次），触发邮件或 Slack 通知，并附上
systemctl status mysql输出片段 - 避免静默忽略：即使配置了
Wants=，也要检查；因为 Wants 不阻止启动，脚本必须补上这层防护
