用crontab触发服务健康检查需每5分钟执行脚本，显式设置path、使用绝对路径命令，组合systemctl状态与curl/nc接口检测，连续2次失败再重启，并添加锁文件防运维冲突、分项日志记录与logrotate管理。
怎么用 crontab 触发服务健康检查
直接用 crontab 调脚本是最常用也最可靠的方式，不依赖进程守护工具。关键不是“每分钟跑一次”，而是确保环境变量和路径正确——crontab 默认的 $PATH 很窄，systemctl 或 ps 命令可能根本找不到。
实操建议：
- 在脚本开头显式设置
PATH=/usr/local/bin:/usr/bin:/bin - 用绝对路径调用命令，比如
/bin/ps、/usr/bin/systemctl，避免因$PATH差异导致检测失效 -
crontab -e里写成：*/5 * * * * /path/to/check_service.sh >/dev/null 2>&1（每5分钟执行，错误不发邮件） - 别用
@reboot启动检查脚本——它只运行一次，起不到“定时”作用
怎么判断服务真的挂了而不是暂时无响应
只看 systemctl is-active 返回 inactive 不够，因为服务可能卡在 activating 或 failed 状态；更糟的是，某些服务进程还在，但 HTTP 接口已失联。
实操建议：
- 优先组合判断：
systemctl is-active --quiet SERVICE_NAME检状态 +timeout 3 curl -sf http://localhost:8080/health || exit 1检接口 - 对无 HTTP 接口的服务（如 Redis），改用
echo PING | nc -w3 127.0.0.1 6379 | grep -q PONG - 避免用
ps aux | grep myapp——容易误杀或漏判，grep自身也会出现在结果里 - 加个简单计数：连续 2 次失败再重启，防止瞬时抖动触发误重启
重启服务前为什么要先确认没在更新或维护中
自动重启撞上人工运维操作（比如正在升级配置、重载证书），轻则服务反复崩溃，重则数据错乱。没人希望半夜三点被告警叫醒，发现只是同事刚手动 reload 了 Nginx。
实操建议：
- 在脚本开头检查是否存在临时锁文件：
[ -f /tmp/service_check.lock ] && exit 0 - 人工维护时只需
touch /tmp/service_check.lock，维护完rm /tmp/service_check.lock - 更稳妥的做法是检查
systemctl show --property=ActiveState,SubState，跳过reloading或maintaining状态 - 重启命令统一用
systemctl try-restart而非restart——前者只在服务已运行时才重启，避免对已停服务报错
日志记录和错误隔离为什么不能省
没有日志的自动脚本等于黑盒。某次重启失败，你得知道是 curl 超时、权限不足，还是 systemctl 返回了 Job for xxx failed 这种模糊错误。
实操建议：
- 每次执行都追加时间戳日志：
echo "[$(date '+%Y-%m-%d %H:%M:%S')] checking..." >> /var/log/service_check.log - 把重启命令的 stderr 重定向出来：
systemctl try-restart myapp 2>> /var/log/service_check.log - 别把所有输出都丢进同一个日志——HTTP 检查、进程检查、重启动作分开记录，方便 grep 定位
- 日志文件加 logrotate 配置，否则半年后
/var/log被占满，检查脚本自己先挂掉
真正麻烦的从来不是“怎么写重启逻辑”，而是“怎么让重启行为可追溯、不扰民、不打架”。多一行状态校验，少半夜一次电话。
