我的github：codetoys，所有代码都将会位于ctfc库中。已经放入库中我会指出在库中的位置。
这些代码大部分以Linux为目标但部分代码是纯C++的，可以在任何平台上使用。
缘起
看门狗WatchDog是个硬件领域的概念，硬件一般没人盯着看，没人去重启，只能靠硬件自己来处理，所以使用一些专门硬件来确保故障后能恢复运行——一般也就是复位重启。其机制也很简单，就是硬件定时器，超时重启，如果运行正常，代码会在超时之前将定时器复位，避免重启。
现在的硬件“软化”程度很高，很多所谓“硬件盒子”其实就是个拆掉显示器和键盘的电脑，跑的是标准的linux/windows/android。
最近给一个盒子写程序，盒子是别人做的，我只写软件。盒子是个简化版linux，大部分开发工作和纯软件开发并无区别，只是遇到莫名其妙地跟盒子无法通讯了这就头疼了。
因为这是软件内部出的问题，所以软件自己要想办法发现。解决问题倒是很简单：重启即可。
为了在软件层面及时发现问题自动重启，需要实现看门狗一样的功能。
分析
有这么几个考虑的因素：
- 尽可能在外围，不深入被监控的代码，不会被无意修改
- 尽可能独立，不会因为被监控代码的故障而失效
- 自身容错，不会导致重启时间太长或太频繁
- 针对不明确的故障，因为明确的故障应该直接解决了
以上几条是考虑这些问题：
- 如果系统是因为某个原因卡住了，怎么办？
- 如果系统是因为罕见的异常出错，怎么办？
- 如果嵌入的代码被修改或移除，怎么办？
- 如果故障是因为存储满了，怎么办？
所有这些问题都是很难解决的，看门狗的思路不是创造无错代码，而是让有错误的代码能够恢复运行。
措施
双进程监控（fork）
双进程监控可以解决进程挂了的问题，监控进程因为太过简单，几乎不可能出错（硬件里面也没有人去手工kill -9）。监控进程应该足够简单，屏蔽所有可以屏蔽的信号，除了等待子进程结束之外什么都不做。
监控业务代码卡死
业务代码卡死，或者陷入故障循环，不会导致进程挂掉，双进程监控就解决不了这个问题了。只能手工设置监控点，通过定时检查监控点的状态来判断是否有故障。
例如，可以用一段时间内是否完成了业务来判断。在业务处理结束的地方设置一个全局变量，记录完成时间，那么只需要定时检查这个变量是否超过设定限度，比如这个值是10分钟前，说明10分钟内都没有完成任何业务，不妨重启一下（即使是真的没有业务可做，重启一下也没什么大不了，当然可能会恰好错过几个业务，但相比故障几天后找人去重启设备就是很小的损失了）。
存储满怎么办
存储满很难监控，也很难避免，可以在重启系统前删掉一些东西，保证重启后肯定有足够空间就可以了。
例如可以删掉最早的日志文件或数据文件。当然这引出一个话题：不能无限制写日志。
写文件要限制大小
所有写文件的机制都应该加上最大大小限制，不然写满整个存储是必然发生的事。即使如此，也可能因为各种问题导致占用了非预期的空间，比如文件复制、删除的失败导致遗留文件，所以存储满的情形时一定要考虑的。
代码
哎，代码太简单了，不好意西贴出来骗字数。
（这里是结束）
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
