我的情况如下：
我偶尔会遇到一个问题，运行 Debian 的（非常）远程嵌入式 PC/104 系统似乎失去了使用任何通信接口的能力。我无法通过以太网或串行端口（控制台）访问它。关闭电源后，系统日志显示没有任何异常。当我关闭电源时，它们会突然结束，并在几分钟或几小时后恢复。
我怀疑系统没有被锁定，因为我有一个 python 脚本尝试 ping google.com，如果失败，它会使用 IO 引脚通过继电器切换无线调制解调器的电源。
因此，我的系统完全没有响应，并且调制解调器每十分钟由同一系统进行一次电源循环。幸运的是，在重新启动之间，我可以使用调制解调器对处理器进行电源循环。然后重新启动并收集数据。
系统有一个硬件看门狗，我已经设置并运行了 watchdogd 一段时间。上次发生这种情况时，我尝试添加以下行：
file=/var/log/messages
到 watchdog.conf，但没有帮助。然后我读到
当使用文件模式时，看门狗将尝试 stat(2) 给定的文件。stat 返回的错误将不是导致重启。对于重启，stat 调用必须持续至少一分钟。
我对 stat 了解不够，不知道它会如何应对失去写入磁盘的能力，但我怀疑它不会挂起。
我还注意到 watchdogd 有一个 --sync 选项，但手册页并没有详细说明如果同步失败会发生什么。我的间隔是 2 秒，有什么理由不每两秒同步一次 SSD 吗？
-谢谢
答案1
您所说的“如果同步失败”是什么意思？sync(2) 的手册页提到返回代码“sync() 始终成功”。因此，在您的情况下它“失败”的唯一原因是它没有足够快地将控制权返回给 watchdogd（因为要写入的块很多、写入速度慢、磁盘或文件系统或内核 I/O 层损坏或损坏，...）
如果它不能足够快地将控制权返回给 watchdogd，它将无法足够快地写入 /dev/watchdog，并且您的硬件看门狗应该触发硬件重启。
stat(2) 只有在出现阻止读取的错误类型（内核错误、损坏的 I/O 层）时才会出现无法写入磁盘的问题。是的，如果出现问题，它可能会挂起。顺便说一句，您应该将“file=/var/log/messages”与“change=”结合使用，这样如果文件更改不够频繁，看门狗就会启动重新启动。
至于看门狗，您是否绝对确定硬件看门狗正在工作？在启动 watchdogd 之前，您是否 modprobe 了正确的硬件模块？dmesg(8) 是否指示了这一点？如果您“KILL -STOP”watchdogd 进程，机器应该会重新启动。如果是这样，您可以尝试将“nowayout”选项添加到您的硬件模块，以消除例如 OOM 杀手杀死 watchdogd 并从而停止硬件看门狗的可能性。您还可以添加“test-binary”和“test-timeout”来运行自定义脚本，该脚本将返回系统是否被视为处于活动状态（如果不是，则启动重新启动）。