我遇到了一个偶尔出现的问题，似乎是我们的一台 Ubuntu 服务器完全随机发生的。服务器会随机决定停止响应除 ping 请求之外的所有服务（SSH、HTTP 等）的连接。它仍会响应 ping，但其他一切都会停止。让系统恢复运行的唯一方法是让数据中心执行硬重启。
我已经尝试调查该问题近一年了，但一直无法找出导致此行为的原因。我安装了一系列监控实用程序，包括 Monit，并将它们设置为在 CPU 使用率、内存使用率或交换空间使用率超过特定阈值时向我发送警报。我还编写了一个脚本，如果满足任何这些阈值，则向我发送当前正在运行的进程列表。
不幸的是，似乎导致服务器无响应的原因来得太快，以至于监控实用程序甚至没有机会发送警报电子邮件（或者问题的原因与 CPU 或内存使用无关）。我的一个朋友建议编写一个简单的 bash 脚本，每 5 分钟获取 ps auxf 的输出并将其写入日志文件，所以我设置了一个脚本并将其放在 crontab 上。
今天早上我醒来发现服务器再次无响应，所以我联系了数据中心并要求他们再次执行硬重启。然后我登录服务器并查看 ps auxf 快照的日志文件。在日志文件中，最后一次记录的快照是在午夜，从那时到服务器重新启动之间没有写入其他快照，这表明服务器在午夜左右的某个时间无响应，导致进程日志记录脚本无法运行。
最后一个快照不包含任何表明发生这种情况的原因的进程列表。最后一个快照中没有使用大量 CPU 时间或内存的进程。我进行了一些谷歌搜索，发现其他人也在这里发布了关于同一问题的帖子。其中一个帖子包含建议你检查 /var/log/messages 的答案，但不幸的是，自 2011 年以来，此服务器上的 /var/log/messages 就没有被写入过（我不知道为什么，其他人可以访问此服务器，可能更改了日志路径）。
我猜是发生了某种内核恐慌，导致服务器上的所有服务停止工作，但我不知道是什么导致了内核恐慌，甚至不知道这是否真的发生了。有人知道是什么原因造成的吗？这对我来说真是一个令人头疼的问题，我花了几乎一年的时间试图找出原因。
谢谢！
答案1
不要运行 cronjobs。派生一个优先级非常高的守护进程（我假设您可以获得 root 权限）。您需要的是一个实时进程（不能被抢占），它会定期执行您认为合适的任何类型的扫描。并使用计时器来运行这些扫描。这听起来像资源阻塞 - 就像进程报头中的可用进程槽被用完了，例如，您在派生炸弹中看到的那种情况。这不太可能，但突然冻结是资源完全消失或完全用完的症状。内存过度使用会导致大量交换，然后系统会变得完全无法使用。
小心！这个进程可能会毁掉你的系统。如果你对实时编程不熟悉，可以寻求帮助。
syslog 会说什么？如果 syslogd 没有运行，请打开服务/守护程序。服务日志会说什么？除非开始时间少于几毫秒，否则肯定有什么东西在抱怨。在某个地方。
答案2
我遇到了同样的问题，我发现这是一个内存问题，有一个进程占用了所有可用内存，因此内核可能会在解决内存紧张的问题时遇到问题，从而冻结系统。
我成功解决了该问题，只需增加内存大小即可，也可以通过降低内存使用量来解决该问题（例如：通过禁用某些功能......）
祝你好運，謝謝！