前言
继续上文内容https://blog.51cto.com/infrado/7083074，上文说到，看门狗的调用。
环境
实验环境同上文，继续是ESXi环境，进行一些有趣的实验，以及在x86服务器硬件上，看门狗是如何工作的，以及arm环境的Linux系统看门狗的小实验。
watchdog经常被用于重置系统，其实在很多业务中相当实用，但是极少有人部署，可能是不了解，也可能是环境过多，此文章做一些小范围的测试，验证硬件看门狗本身的有效性。
在上一篇文章中，通过对爱快本身进行压力负载测试的操作让爱快软路由系统进入CPU100%的异常状态，这个状态难以确定是ESXi模拟的硬件看门狗起作用了，还是爱快本身请求重置操作。从画面状态上来说，应该是CPU完全繁忙之后，操作系统没有空闲时间喂狗，导致看门狗重置了操作系统。因为并没有出现正常的操作系统关闭动作，系统是直接RESET了，直接进入重新开机的流程。
爱快可以借助一些方式获取到root权限，就不在本文的讨论范围内了。本文讨论的是硬件看门狗的广泛有效性。爱快的doker容器默认状态下是没有特权的，虽然在容器内为root特权，但是并没有得到操作系统本身的root。
/proc/sysrq-trigger这就是一个很方便的方式。通过给这玩意儿一个C，瞬间系统就崩溃了。
测试方法
验证看门狗的有效性
#touch /dev/watchdog0
#请勿随意在操作系统执行输入后等待一会儿。如果在ESXi，可以看到守护被启用了。等待一会儿之后，可以发现运行中的状态被直接重置了。
如果服务软件正常运行过程中，我们可以固定间隔的一段时间去重复“喂狗”。可以写在操作系统层面的单独的守护软件来运行这个任务，也可以用操作系统自带的软件进行这个操作，这样能够确保操作系统本身在运行中。另外构造程序，软件看门狗，自己编写逻辑，去确保操作系统上对外提供服务的软件能够有效的运行。
暂停“喂狗”，能够让系统在一段时间后崩溃，这个时候操作系统是正常的，能不能让操作系统内核崩溃呢？Windows玩蓝屏的方法太多反倒是不太好决定用哪个，而Linux下，我不假思索，就用/proc/sysrq-trigger
#touch /dev/watchdog0
#echo c > /proc/sysrq-trigge
#！！！任何一条都不要随意在操作系统执行在操作系统执行上述命令，前者“摸”了下看门狗，后者让系统立刻崩溃。
经过测试：不仅仅是X86虚拟机能有效，X86服务器以及ARM开发板均能够提供有效的自我守护。当操作系统出现错误，无法响应的时候，能够及时的重置系统，使服务自我恢复。
可以将强制重置系统的逻辑放在业务逻辑，也可以仅仅是由系统喂狗，另外由软件去保活自己期望长期运行的服务。在CentOS中，最常见的就是借助systemd去保活服务，然后借助watchdog程序来确保系统正常运行。当服务软件出现异常的情况，systemd会重新拉起服务。当操作系统本身出现问题的时候，服务器本身的看门狗能确保系统重新进入正常状态。
而非systemd管理的软件，可以在自己实现的自动启动的基础上进行额外的开发管理。当然软件的运行最好是借助操作系统自带的管理方式，哪怕是简单程序，最好也不要用cron、rc.local之类的方式去管理自动运行。
通过看门狗的介入，能够自动处理正常运行中出现的崩溃。如果持续频繁崩溃，找到崩溃的原因解决才是关键。服务器配置了看门狗之后，当看门狗动作导致系统重置，最好是有监控手段监控例如uptime之类的信息，记录事件解决问题。