嵌入式 Linux 系列 10：看门狗、进程守护和自恢复

嵌入式设备部署到现场后，不能依赖人工登录重启服务。网络异常、进程崩溃、死锁、内存泄漏、硬件偶发故障都可能发生。自恢复能力是产品稳定性的底线。

一、自恢复分几层

可以分成三层：

业务重连
  -> 进程守护
  -> 系统看门狗

业务重连解决 MQTT、HTTP、数据库连接这类问题。进程守护解决进程退出。硬件或内核 watchdog 解决系统卡死。

二、进程守护

最小 supervisor：

#!/bin/sh

APP=/usr/bin/device_agent
LOG=/data/log/device_agent.log

mkdir -p /data/log

while true; do
    "$APP" >> "$LOG" 2>&1
    echo "$(date) app exited, restart after 2s" >> "$LOG"
    sleep 2
done

这个脚本能解决简单崩溃，但还不够。

需要增加：

• 启动次数限制。
• 崩溃原因记录。
• 配置错误时不要无限重启。
• 支持停止和升级。
• 和 watchdog 喂狗逻辑分离。

三、硬件 watchdog

Linux 中常见设备：

/dev/watchdog
/dev/watchdog0

基本逻辑：

1. 打开 watchdog。
2. 周期性写入喂狗。
3. 如果系统卡死或进程不喂狗，硬件复位。

示例：

int fd = open("/dev/watchdog", O_WRONLY);
write(fd, "\0", 1);

真实项目要设置超时时间，并确认驱动支持。

四、不要随便喂狗

喂狗不是定时写一下就完事。更稳的方式是业务健康检查通过后才喂狗。

例如检查：

• 主循环还在运行。
• MQTT 线程没有死锁。
• 配置线程没有阻塞。
• 外设采集没有长期失败。
• 日志线程没有卡住。

如果只要进程活着就喂狗，死锁时 watchdog 也救不了设备。

五、重启原因记录

每次启动时记录：

/data/log/boot_reason.log

内容包括：

• 上次退出原因。
• watchdog 是否触发。
• 内核是否 panic。
• 应用是否频繁崩溃。
• 当前固件版本。

现场设备如果偶发重启，没有重启原因记录会很难查。

六、验收清单

至少测试：

• kill 业务进程后自动恢复。
• 业务线程死锁后 watchdog 能复位。
• MQTT 断网后能重连。
• 配置错误不会无限快速重启。
• 日志不会无限增长占满分区。
• OTA 期间 watchdog 不误复位。

自恢复不是单个功能，而是一组异常路径设计。