这是我的情况：
我有一个非常偶然的问题，运行Debian的（非常）远程embedded式PC / 104系统似乎失去了使用任何通信接口的能力。 我无法通过以太网或串行端口（控制台）。 电源循环后，系统日志显示没有任何不妥之处。 他们只是突然结束，几分钟或几小时后恢复供电。
我怀疑系统没有locking，因为我有一个python脚本试图ping google.com，如果失败，它使用一个IO引脚通过一个继电器切换无线调制解调器的电源。
所以，我有一个完全没有反应的系统，而且一个调制解调器正在每十分钟由同一个系统重新启动。 幸运的是，在重启之间，我可以使用调制解调器为处理器供电。 并恢复并收集数据。
该系统有一个硬件看门狗，我有看门狗设置和运行一段时间。 上次发生这种情况时，我尝试添加一行：
file=/var/log/messages 去watchdog.conf，但它没有帮助。 然后我读了
当使用文件模式时，看门狗将尝试stat（2）给定的文件。 stat返回的错误不会导致重新启动。 为了重新启动，统计调用必须持续至less一分钟。
我不知道stat是否知道如何回应丢失写入磁盘的能力，但我怀疑它不会挂起。
我也只是注意到，watchdogd有一个–sync选项，但手册页不是很详细，如果同步失败会发生什么。 我的间隔是2秒，有没有理由不每两秒同步一个SSD？
-谢谢
你是什么意思“如果同步失败”？ 同步手册页（2）说关于返回码“sync（）总是成功”。 所以只有这样，它可以“失败”在你的情况是它不会返回控制watchdogd足够快（由于许多块写入，写入缓慢，破损或损坏的磁盘或文件系统或内核I / O层，… … ）
如果它不能很快的将控制权交还给看门狗，它将不能很快写入到/ dev /看门狗，你的硬件看门狗应该触发硬件重启。
stat（2）可能会有不可写磁盘的问题，只有当这种types的错误，以防止读取（内核错误，损坏的I / O层）。 是的，如果有问题，它可能会挂起。 顺便说一句，你应该使用“file = / var / log / messages”和“change =”结合起来，这样如果文件没有经常改变，看门狗就会重启。
至于看门狗，你是否确定硬件看门狗正在工作？ 在启动看门狗之前，您是否修改了正确的硬件模块？ dmesg（8）表示如此吗？ 如果你“KILL -STOP”看门狗进程，机器应该重启。 如果是这样的话，你可以尝试添加“nowayout”选项到你的硬件模块，以消除例如OOM杀手看到杀死看门狗的机会，从而停止硬件看门狗。 你也可以添加“testing二进制”和“testing超时”来运行定制脚本，如果系统被认为是活着的（如果没有，则重新启动）。