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