rebug Asked: 2021-04-20 00:45:51 +0800 CST2021-04-20 00:45:51 +0800 CST 2021-04-20 00:45:51 +0800 CST Snmpd 停止工作而没有任何更改 772 我正在使用 snmp 监控多个服务器/路由器。一切正常，但今天我看到 3 服务器不再通过 SNMP 响应。3 个 snmp 守护进程在同一时刻（星期六早上 6 点）停止，最后一个日志（Cannot statfs : /var/docker/lib .....） 我试图重新启动 snmp 守护程序，但 systemctl 遇到超时并且无法重新启动它们。配置没有任何变化。 有人有想法吗？ 谢谢 monitoring snmp snmpd 1 个回答 Voted Best Answer Simon Richter 2021-04-20T01:26:09+08:002021-04-20T01:26:09+08:00 “Cannot statfs”可能来自 snmpd 中的磁盘使用监视器，它迭代已挂载的文件系统并询问剩余的可用空间量。 如果statfs(2)调用失败，这是机器上的一个严重问题，这是系统调用之一，它基本上只是在共享结构中查找信息并返回它，唯一可能失败的方法是同步访问该结构结构体。 因此，某些东西挂在那里，它持有对内核中某些结构的独占访问权，这也是阻止文件系统访问的原因，这会导致重新启动超时。 如果这是一个本地文件系统，我会重新启动并在启动期间强制检查文件系统。在 systemd 之前，这样做的机制是shutdown -Fr now，但systemd 要求您设置内核命令行参数。 如果这是在 SAN 或类似设备上，我会先找出 SAN 出了什么问题，然后进行文件系统检查。 三台主机同时出现，真的只能用“这个文件系统在一个失败的SAN上”来解释。
“Cannot statfs”可能来自 snmpd 中的磁盘使用监视器，它迭代已挂载的文件系统并询问剩余的可用空间量。
如果statfs(2)调用失败，这是机器上的一个严重问题，这是系统调用之一，它基本上只是在共享结构中查找信息并返回它，唯一可能失败的方法是同步访问该结构结构体。
因此，某些东西挂在那里，它持有对内核中某些结构的独占访问权，这也是阻止文件系统访问的原因，这会导致重新启动超时。
如果这是一个本地文件系统，我会重新启动并在启动期间强制检查文件系统。在 systemd 之前，这样做的机制是
shutdown -Fr now，但systemd 要求您设置内核命令行参数。如果这是在 SAN 或类似设备上，我会先找出 SAN 出了什么问题，然后进行文件系统检查。
三台主机同时出现，真的只能用“这个文件系统在一个失败的SAN上”来解释。