设备死机了怎么自己活过来？看门狗与分级自恢复设计实战（2026）
核心结论：看门狗的价值不在「会重启」，而在「重启之后能回到可用状态」。很多设备装了看门狗，现场依然一批一批变成「重启循环」或「重启后配置丢失」。真正要设计的是三层：谁来判断系统还活着、判断失败后按什么顺序恢复、恢复不了怎么退到安全状态。
一、先把「死机」分类
| 类型 | 表现 | 谁能发现 |
|---|---|---|
| 应用卡死 | 进程在，但不处理业务；界面不动、不上报 | 应用心跳 / systemd watchdog |
| 进程退出 | 服务崩溃或被 OOM 杀掉 | 进程守护 / systemd Restart |
| 内核异常 | oops、panic、驱动死锁；系统整体不响应 | 硬件看门狗 |
| 外设挂死 | 某个设备（摄像头、4G 模组、网卡）无响应，系统其他部分正常 | 业务层超时检测 |
| 网络失联 | 设备在跑，但对平台不可见 | 平台侧离线告警 + 设备侧自检 |
| 电源/硬件故障 | 反复掉电、复位、电压不足 | 复位原因寄存器 + 电源监测 |
不同类型要用不同手段。用硬件看门狗去救「应用卡死」是杀鸡用牛刀，还会造成不必要的整机重启；只靠应用守护也救不了内核死锁。
二、分层的看门狗体系
- 第一层：SoC 内部看门狗（WDT）。最简单，超时直接复位 SoC。缺点是它只认「有没有喂」，不认「系统是否健康」，喂狗逻辑写错就等于没有；
- 第二层：外部看门狗芯片。独立于 SoC，通过 GPIO 或 I²C 喂狗。SoC 完全挂死、内部 WDT 失效、甚至电源异常时仍能拉复位。要求高的无人值守设备建议加；
- 第三层：systemd watchdog。由服务自己定期
sd_notify(WATCHDOG=1)，超时由 systemd 重启该服务而不是整机。粒度更细，避免「一个应用卡住，整机重启」； - 第四层：业务心跳。不是「进程还活着」，而是「业务真的在跑」：采到数据、推到平台、处理完队列。这一层最接近用户感知；
- 层级关系：业务心跳异常 → 先重启服务；服务重启多次仍异常 → 复位整机；整机复位后仍无法启动 → 回滚到备份分区或进入恢复模式。
三、喂狗的正确姿势
- 只在健康检查全部通过后喂：主循环里依次检查「关键线程心跳、队列未积压、外设可访问、网络任务未长时间阻塞」，全部通过才喂一次；任何一项失败就停止喂狗，让系统按设计复位；
- 多线程不要各自喂：多个线程都去喂，等于谁活着都能喂，卡死一个线程照样通过。正确做法是各线程置健康位，由一个监管线程汇总后统一喂；
- 不要在中断或定时器里无脑喂：中断还在跑不代表应用还在跑。这是最典型的「看门狗形同虚设」；
- 超时要留足合法阻塞：按「最长合法操作耗时 × 2～3」设，比如大文件写入、升级、日志归档这类会长时间占用主循环的操作，要么分段处理，要么在操作期间显式延长；
- 启动阶段单独处理：内核启动、文件系统检查、应用初始化可能超过看门狗超时。要在 bootloader 或启动脚本里先关闭/延长看门狗，等应用起来接管后再打开；
- 喂狗要有记录：把「最后一次成功喂狗的时间」和「当前健康位」写进日志或共享内存，复位后能判断是哪一项先失效。
四、复位不等于恢复
这是自恢复设计里最容易被跳过的一环：设备确实重启了，但起来之后还是同样的状态，于是陷入「重启—卡死—重启」的循环。
- 记录复位原因：SoC 通常有复位原因寄存器，能区分上电复位、看门狗复位、软件复位、外部复位。启动后第一时间读取并持久化；
- 启动失败计数：在可写分区（或 RTC 备份寄存器）里累计「未成功启动次数」。应用完整启动并上报成功后清零；
- 连续失败就降级：比如连续多次未成功启动，就切到备份 rootfs、关闭非必要服务、进入最小系统模式，先保证可远程访问；
- A/B 回滚：升级后启动失败自动回退到上一版本，这部分与 固件 OTA 与 A/B 分区升级 的 A/B 机制配套；
- 恢复模式：保留一个能进的最小系统（网络 + SSH 或维护口），供现场或远程修复。没有恢复模式的设备，一旦启动链损坏就只能返厂；
- 避免重启风暴：重启间隔要递增（退避），不要 1 秒一次。频繁重启会让上级平台告警刷屏，也会加速 Flash 磨损。
五、应用级守护
- systemd 是最省事的方案：
Restart=always、RestartSec设几秒、StartLimitBurst限制单位时间内重启次数，超过就进入 failed 状态而不是无限重试； - 区分「可恢复」和「不可恢复」退出码：配置错误、授权失败这类重启也没用的，应该退出并告警，而不是无限重启掩盖问题；
- 依赖顺序：网络、存储、时钟服务就绪后再启动业务，避免业务起来发现依赖没准备好又退出；
- 资源限制：用 cgroup 限制内存，避免 OOM 杀掉关键进程；OOM 本身就是需要告警的故障，不是「重启一下就好」；
- 优雅退出：收到 SIGTERM 后停止取流、提交数据、释放设备，再退出。直接 SIGKILL 会留下没释放的硬件资源与半写文件。
六、保留崩溃现场
- pstore / ramoops：把内核 oops 日志写进预留内存，重启后还能读出来。这是排查「为什么死」最有效的手段，成本只是设备树里留一块内存；
- core dump：应用崩溃时把 core 存到可写分区，带符号表分析。注意限个数与总大小，别把分区写满；
- 日志要能活着：日志写 tmpfs 一重启就没了。关键日志应落到持久化分区，并做大小与条数限制；
- 黑匣子：记录最近若干条关键事件（启动、复位原因、配置变更、升级、外设错误）到一个小环形区，出问题时可整体导出；
- 时间要可信：没有 RTC 或 NTP 时，日志时间戳会跳。至少记录「开机后秒数」与「启动次数」，便于排序。
七、远程可观测与恢复
- 心跳上报：设备定期向平台上报「在线 + 健康状态 + 复位次数 + 版本 + 关键指标」。只有在线状态不够，看不出「在跑但业务不通」；
- 离线告警：平台侧按超时判离线，比设备自己上报「我离线了」可靠；
- 远程重启与远程诊断：提供受控的重启命令、日志拉取、配置回读。要有权限控制与操作审计，别做成谁都能重启；
- 带外通道：主网络不通时，能否通过 4G、串口或本地维护口进入？无人值守场景值得预留；
- 现场兜底：再好的远程也怕断网。设备面板上留一个「长按恢复」的物理方式，比让客户拆机短接可靠。
八、误复位排查
- 电源跌落：负载突变（4G 发射、继电器动作、硬盘启动）拉低电压触发复位，看起来像「看门狗误动作」。用示波器抓复位瞬间的电源波形；
- 超时设太短：正常业务峰值超过了看门狗超时，设备在重负载时反复重启；
- 启动时间过长：文件系统检查、OTA 校验让启动超过超时，形成「永远起不来」；
- Flash 卡顿：eMMC 垃圾回收或坏块重试导致写操作阻塞数秒，喂狗线程被拖住；
- 调度饥饿：低优先级喂狗线程被高负载业务长期抢占。提高优先级或用独立线程；
- EMC 干扰：复位引脚走线过长、未加滤波，附近继电器动作就复位。硬件上要加 RC 与TVS，这部分与 嵌入式 EMC 设计与认证 相关。
九、怎么验证自恢复真的有效
- 故障注入：
kill -STOP暂停主进程、制造死循环、拔掉摄像头、断开网线、填满分区、模拟 OOM，逐项验证恢复路径； - 验证恢复时间：从故障发生到业务恢复要多久？无人值守场景通常要求分钟级，不是「能恢复就行」；
- 连续循环：让设备在故障与恢复之间循环数十次，确认不会累积泄漏、不会进入重启风暴；
- 断电 + 复位组合：在复位过程中再断电，验证启动失败计数与回滚逻辑；
- 看复位原因统计：长期运行后统计复位原因分布。如果看门狗复位占比异常高，说明有系统性问题没解决。
十、常见坑
- 坑一：在定时器中断里喂狗。应用死了狗还在喂，等于没有看门狗；
- 坑二：只看进程在不在。进程活着但业务不通，平台看到「在线」，用户看到「没数据」；
- 坑三：复位后不做失败计数。升级坏了就无限重启，现场只能返厂；
- 坑四：重启间隔 1 秒。日志刷爆、平台告警刷屏、Flash 加速磨损；
- 坑五：没有崩溃现场。只知道「重启过」，永远查不出原因，同一个问题反复发生。
十一、常见问题（FAQ）
- Q1：内部看门狗够用吗？消费类、可人工干预的场景够用。无人值守、户外、车载等「到现场成本很高」的场景，建议加外部看门狗芯片。
- Q2：看门狗超时设多少？按最长合法阻塞时间的 2～3 倍，并确保启动阶段单独处理。不要照抄别人的 10 秒或 30 秒。
- Q3：重启能解决所有问题吗？不能。重启只能清除瞬时状态，配置错误、硬件损坏、网络策略问题重启多少次都一样，必须能区分并告警。
- Q4：要不要做双系统备份？升级频繁、现场不可达的设备值得做。A/B 分区加启动失败回滚，成本主要是 Flash 空间与升级逻辑复杂度。
- Q5：这套自恢复机制能一起做吗？可以。虹音科技在固件与整机交付中同步设计看门狗分层、启动失败回滚、崩溃日志保留与远程诊断接口，并做故障注入验证。把设备的使用场景与运维方式发给我们，48 小时内回复方案。
十二、相关方案与联系方式
相关方案：边缘计算网关、安防 NVR 录像、泵站水厂无人值守终端。配套阅读：7×24 长期运行稳定性设计、固件 OTA 与 A/B 分区升级、开机时间优化。
深圳市虹音科技有限公司（HONGYIN TECH）提供 RK3588/RK3576/RK3568 等平台的嵌入式项目定制服务，免费需求评审、工程师直连、小批量起订。把你的需求清单发给我们，48 小时内收到选型建议与报价。
联系方式：电话 13728726926｜邮箱 sales@hoyin-tech.com｜官网 www.hoyin-tech.com｜地址：深圳市宝安区航城街道三围社区凡荣科创园 A 栋 301。