软件看门狗：让服务永不宕机

初级代码游戏的专栏介绍与文章目录-CSDN博客

我的github：codetoys，所有代码都将会位于ctfc库中。已经放入库中我会指出在库中的位置。

这些代码大部分以Linux为目标但部分代码是纯C++的，可以在任何平台上使用。

缘起

看门狗WatchDog是个硬件领域的概念，硬件一般没人盯着看，没人去重启，只能靠硬件自己来处理，所以使用一些专门硬件来确保故障后能恢复运行——一般也就是复位重启。其机制也很简单，就是硬件定时器，超时重启，如果运行正常，代码会在超时之前将定时器复位，避免重启。

现在的硬件“软化”程度很高，很多所谓“硬件盒子”其实就是个拆掉显示器和键盘的电脑，跑的是标准的linux/windows/android。

最近给一个盒子写程序，盒子是别人做的，我只写软件。盒子是个简化版linux，大部分开发工作和纯软件开发并无区别，只是遇到莫名其妙地跟盒子无法通讯了这就头疼了。

因为这是软件内部出的问题，所以软件自己要想办法发现。解决问题倒是很简单：重启即可。

为了在软件层面及时发现问题自动重启，需要实现看门狗一样的功能。

分析

有这么几个考虑的因素：

尽可能在外围，不深入被监控的代码，不会被无意修改
尽可能独立，不会因为被监控代码的故障而失效
自身容错，不会导致重启时间太长或太频繁
针对不明确的故障，因为明确的故障应该直接解决了

以上几条是考虑这些问题：

如果系统是因为某个原因卡住了，怎么办？
如果系统是因为罕见的异常出错，怎么办？
如果嵌入的代码被修改或移除，怎么办？
如果故障是因为存储满了，怎么办？

所有这些问题都是很难解决的，看门狗的思路不是创造无错代码，而是让有错误的代码能够恢复运行。

措施

双进程监控（fork）

双进程监控可以解决进程挂了的问题，监控进程因为太过简单，几乎不可能出错（硬件里面也没有人去手工kill -9）。监控进程应该足够简单，屏蔽所有可以屏蔽的信号，除了等待子进程结束之外什么都不做。

监控业务代码卡死

业务代码卡死，或者陷入故障循环，不会导致进程挂掉，双进程监控就解决不了这个问题了。只能手工设置监控点，通过定时检查监控点的状态来判断是否有故障。

例如，可以用一段时间内是否完成了业务来判断。在业务处理结束的地方设置一个全局变量，记录完成时间，那么只需要定时检查这个变量是否超过设定限度，比如这个值是10分钟前，说明10分钟内都没有完成任何业务，不妨重启一下（即使是真的没有业务可做，重启一下也没什么大不了，当然可能会恰好错过几个业务，但相比故障几天后找人去重启设备就是很小的损失了）。