守护进程的核心是快速恢复而非持续运行，需通过分层健康探测（进程、端口、业务）、幂等恢复策略及轻量shell实现可靠监控。
守护进程的核心不是“一直运行”，而是“出问题时能快速恢复”。watchdog 不是简单轮询进程是否存在，而是围绕服务的健康状态设计主动探测和决策逻辑。
明确服务的健康信号
不能只看进程是否存活（ps 有就认为 OK），要定义真正代表服务可用的指标：
- HTTP 服务：用
curl -f -s -o /dev/null http://localhost:8080/health检查返回码和超时 - 数据库：执行轻量查询如
SELECT 1，验证连接与响应能力 - 消息队列：尝试发布/消费一条测试消息，确认通道通畅
- 本地 socket 或文件锁：检查
/var/run/myapp.sock是否可连接或是否存在有效锁文件
分层探测 + 超时控制
避免单点误判，采用递进式检查：
- 第一层：进程存在且未僵死（
kill -0 $PID可发信号） - 第二层：端口监听且可接受连接（
nc -z localhost 8080） - 第三层：业务级探针成功（如上述 health endpoint 或 SQL 查询）
- 每层设置独立超时（如 2s / 3s / 5s），任一层失败即进入恢复流程
恢复动作需幂等且可控
重启不是唯一解，要区分场景并限制频次：
- 短暂失联（如网络抖动）：等待 5 秒后重试，最多 2 次
- 持续不可用：记录日志、发送告警（如
logger -t watchdog "service down"）、再执行重启 - 防雪崩：连续失败 3 次后暂停自动恢复，仅告警，避免反复拉起崩溃服务
- 重启前确保旧进程已退出（
kill -TERM $PID; sleep 2; kill -KILL $PID 2>/dev/null）
以最小依赖落地 watchdow
不依赖 Python 或 systemd，用 shell + cron 或独立循环更可靠：
- 写成单文件脚本（
/usr/local/bin/watchdog-myapp），带 shebang 和权限 - 用
while true; do ...; sleep 10; done &后台常驻，配合nohup和disown - 记录日志到
/var/log/watchdog-myapp.log，保留最近 7 天（logrotate配置） - 启动入口加锁（
flock -n /tmp/watchdog-myapp.lock）防重复运行
不复杂但容易忽略——真正的可靠性来自对“什么是好”和“坏了怎么办”的清晰定义，而不是让脚本跑得更久。
