我给5美元芯片派了个活：服务器死机自己重启

服务器电源灯亮着，风扇在转，但SSH连不上，所有服务都没响应。我始终没查清是什么原因，服务器内部某个东西出了问题，把它冻住了。没有访问权限，就没法排查和修复，唯一的出路是用物理按键强制重启。就在那时，我决定给一块5美元的ESP32派个活：从外部盯着我的服务器，在真正需要的时候触发重启。

搭硬件是简单的那部分，让一台笔记本听懂ESP32在说什么，是另一回事。

服务器没法给自己作证

几天前，我在服务器上做实验，经历了几次硬断电。实验结束几个小时后，我注意到DNS查询不再被过滤了，广告又回来了。

我去打开AdGuard Home（AGH）面板，打不开。我打开Portainer看它到底还在不在，意外的是，它显示在运行。但日志里全是错误。排查过程中，我随手跑了docker ps，它也显示容器是up状态，但有个奇怪的地方：PORTS那一列是空的。

再往下挖，我跑了docker inspect，它给出了确切的问题：容器没有挂载任何网络。最后我通过删除并重建容器修好了它，但这里的教训不是我怎么诊断的，真正的重点是：即使Docker说它在运行，它也是不可用的。

我以前写过，把监控服务部署在它本该监控的同一台服务器上，是个坏主意。但就我个人而言，从没真正遇到过。我当时用的监控服务（Uptime Kuma、Pulse）依赖的正是Docker显示的那套检查。

更糟的是，如果服务器彻底无响应或冻住，它们一个都帮不上忙。于是我想到看门狗。最简单的选项是软件方案，它可以对失败的进程做出反应并重启服务，但同样，如果它底下的操作系统停止响应，它也无能为力。

那一刻，我决定把这件事交给一个真正能从外部检查、然后采取行动的外部看门狗。

ESP32不听服务器的一面之词

找外部看门狗的时候，我注意到工作站抽屉里躺着一块ESP32板子。它立刻对上了：它可以当外部监视器来检查服务器。ESP32上不会装任何东西在服务器里，它不检查Docker容器，也不在服务器上跑任何东西。

然后我开始琢磨逻辑。头脑风暴了几个小时后，我定下了三项检查。第一，它会尝试对22端口的SSH做一次TCP连接。第二，它会通过我的AGH服务对一个真实域名做一次真正的DNS查询，因为DNS已经在我身上出过故障。第三，第三项探测作为对照，用来防止不必要的重启。

第三项检查针对我常开的NAS，这一项很重要，因为它决定问题是不是真的出在服务器上。举个例子，如果SSH和DNS都失败，但NAS检查通过，那就是服务器有问题的强烈信号。但如果三项全失败，那说明可能有别的问题影响了整个网络，重启也没用。

我还决定加各种其他保护措施，防止误触发。比如，第一次报告服务器死亡后延迟五分钟，下一次重置前延迟八分钟，连续三次重置失败后永久停止。甚至还有一个用BOOT按钮实现的临时暂停机制，方便我在做计划内维护时暂停脚本。

最后，用继电器或智能开关接在服务器电源和ESP32上，来执行真正的重置。但我刚开始动手做这个看门狗，服务器就不肯听ESP32说话了。

重置一台笔记本，试了三个方案

继电器始终没做成，然后看门狗失败了。

服务器决定变成一堵打不穿的墙。背景是，我把一台8年前的戴尔Latitude改造成了家用服务器。它证明了自己是一台可靠的家用服务器，没在 enterprise 硬件上花一分钱。

回到问题上，我的计划是用继电器或智能开关给服务器断电重启，这两样我手头都有。如果服务器是一台迷你主机或塔式机，这个计划本可以完美运行。但因为它是一台带电池的笔记本，切断墙电根本没用。

断开电池是个办法，但那会移除服务器内置的电源备份，所以不值得。这样一来，继电器和智能开关的方案就出局了。我又开始头脑风暴。在翻硬件资料时，我发现采用英特尔芯片组的笔记本自带一个内部看门狗。

这台Latitude用的是i5-6300U，所以我的服务器很可能已经自带看门狗。这本该是个完美的方案，但在我以30秒超时启用位于/dev/watchdog0的iTCO_wdt硬件看门狗后，即使我停止喂它，它也没能重置电源并重启。我搞不清这是机器特定的问题还是普遍问题。但我也放弃了这个方案。

我准备放弃了，但在那之前，我做了最后一次尝试，发现了英特尔主动管理技术（AMT）。它是一种内置于芯片组的远程管理系统，独立于操作系统运行。我立刻通过BIOS级的MEBx菜单配置了它，并做了一次试运行。它只需要有线局域网连接，我可以通过HTTP摘要认证在16992端口访问AMT。

之后，实现就很直接了。ESP32检查服务器状态，如果发现它死了，就启动一个300秒的计时器。计时器一到，ESP32就向AMT发送一个电源循环请求（RequestPowerStateChange (5)）；AMT回复一个HTTP 200 OK响应，然后……