应直接通过 /dev/watchdog 喂狗，以 O_WRONLY 打开、周期性写任意字节、退出前写 "V" 关闭；需绑定业务关键路径完成点，避免空转或误触发，禁用用户态模拟窗口狗。
直接用 /dev/watchdog 喂狗，别自己实现硬件寄存器操作
嵌入式 Linux 的 watchdog 子系统已经把硬件抽象成标准字符设备，/dev/watchdog 就是你的入口。你不需要、也不应该在用户态直接读写 SoC 的 WDT 寄存器（比如 IWDG->KR 或 WDOG_CNT），那属于内核驱动职责。用户空间唯一要做的，就是打开这个设备、周期性写入任意字节（喂狗）、并在退出前执行 magic close（写入 "V"）防止误复位。
常见错误现象：程序一退出就立刻复位——多半是没做 magic close；或者喂狗线程被调度延迟太久，超时触发复位。
- 必须以
O_WRONLY打开，不能带O_NONBLOCK（否则write()会失败） - 喂狗间隔必须严格小于设备树里配置的 timeout（例如设备树设了
timeout-sec =，你得控制在 25 秒内写一次） - 关闭前务必
write(fd, "V", 1)，否则内核认为“程序异常终止”，立即触发复位 - 如果系统启用了
nowayout（常见于生产环境），即使写了"V"也无法停止喂狗，只能靠ioctl(fd, WDIOC_SETOPTIONS, &opts)配合WDIOS_DISABLECARD（需 root 权限且内核支持）
watchdogd 不是银弹，它只管“系统级心跳”，不管你的业务逻辑
watchdogd 是一个成熟的用户态守护进程，能自动喂狗、监控 CPU/内存/磁盘等指标，并支持配置文件热重载。但它默认不感知你的业务进程状态——它不会因为你主进程卡死在某个 mutex 上而主动重启你。
所以如果你的核心业务进程需要被单独守护，不能只依赖 watchdogd。你需要额外一层逻辑：
立即学习“C++免费学习笔记（深入）”；
- 用
fork()+waitpid()监控子进程退出，捕获SIGCHLD后判断WIFEXITED()/WIFSIGNALED() - 避免用
system("kill -9 ...")杀进程后不 wait，否则僵尸进程堆积会导致fork()失败 - 喂狗动作必须和业务健康检查耦合：比如每次成功处理完一条 MQTT 消息后再
write(/dev/watchdog)，而不是单纯靠sleep(20)定时喂 - 不要让喂狗线程和业务线程共享同一个 mutex —— 若业务线程持锁卡死，喂狗线程也阻塞，整套机制就失效了
窗口狗（Window Watchdog）在用户态几乎不可行，别强行模拟
窗口狗要求“喂狗时间必须落在 [Tmin, Tmax] 区间内”，早于 Tmin 或晚于 Tmax 都触发复位。这个特性依赖硬件精确计时与双阈值比较逻辑，目前主流 SoC（如 i.MX6ULL、RK3328、Allwinner H3）的 watchdog IP 都只支持超时狗（Timeout Watchdog），不暴露窗口模式寄存器给用户空间。
有人试图用两个定时器+状态机在用户态模拟窗口行为，结果反而引入竞态和调度不确定性：Linux 的 CFS 调度无法保证定时器精度，nanosleep() 实际延迟可能远超预期，导致“合法喂狗”被判超时。
- 确认你的 SoC 是否真支持窗口狗：查芯片手册中 watchdog 章节，搜索 “window mode”、“WWDG”、“early kick” 等关键词
- 即使硬件支持，内核 watchdog 驱动也未必导出该能力到
/dev/watchdog—— 大部分驱动只实现了watchdog_ops::start/kick/stop三个基本回调 - 真有强安全需求（如车规级），应由内核驱动层实现窗口逻辑，用户空间只负责按约定节奏调用
write()
喂狗频率不是越快越好，关键看业务响应 SLA
很多工程师第一反应是“每 2 秒喂一次最保险”，但这是错的。喂狗太快，等于把看门狗退化成“只要 CPU 还在跑就认为系统正常”的假象；喂太慢，又可能因网络抖动、I/O 延迟等正常波动误触发复位。
合理策略是：把喂狗时机绑定到业务关键路径的完成点上。例如：
- 工业网关：每次成功上报一次 OPC UA 数据后喂狗
- 车载终端：每次完成一次 CAN 报文解析 + 校验 + 转发后喂狗
- 视频分析设备：每次完成一帧 AI 推理并写入 ringbuffer 后喂狗
这样既避免了空转喂狗，又能真实反映业务是否“活着”。如果某次关键操作耗时超过 timeout 的 70%，就得排查是不是算法复杂度突增、内存碎片严重或外设响应异常——这些才是看门狗该帮你揪出来的真问题。
