我运行一个使用 Debian Squeeze 和几个 OpenVZ 容器的服务器。容器主要运行 Squeeze，一些运行 Lenny，一些已经更新到 Wheezy。主机除了 iptables 和 DHCP 之外没有做太多事情。文件服务器、代理、邮件服务器、kerberos、LDAP 等都放入容器中。该系统运行多年，除了一些防火墙规则外，没有发生重大变化，持续了一年多。
2 天前，系统突然崩溃了。我重启系统时遇到了很多问题。起初，它不允许我通过 ssh 登录。root 登录被拒绝，提示“您不存在。走开！”本地登录没问题。一段时间后，ssh 又能正常工作了。巧合的是，我没有重复使用 bash 历史记录中的那行，而是输入了一个新命令，经过三重检查，该命令与之前不起作用但在崩溃前起作用的那行相同。
然后系统运行起来，但大多数协议上的网络流量在 SYN ACK 之后被阻止。DNS、Telnet 和 SSH 都很好，但其余的都一团糟。经过几个小时的摸索和多次重新加载防火墙后，一切突然又恢复正常了。我在日志中找不到任何可疑的东西——但我不是取证专家。
今天，由于容器配额问题，文件服务器的 nscd 失去了与 LDAP 通信的套接字。这是以前从未发生过的事情。我还看到 smbd 声明了大量 (> 30) 套接字。
/var/log/messages 看起来与系统日志。/var/log/kern.log 包含有关崩溃原因的附加信息：
/var/log/kern.log:2950:Sep 19 10:46:57 asgard kernel: [6529441.320086] INFO: task sendmail:32181 blocked for more than 120 seconds.
/var/log/kern.log:2982:Sep 19 10:48:57 asgard kernel: [6529561.324525] INFO: task kdmflush:1932 blocked for more than 120 seconds.
/var/log/kern.log:3005:Sep 19 10:48:57 asgard kernel: [6529561.324694] INFO: task xfssyncd:10162 blocked for more than 120 seconds.
/var/log/kern.log:3027:Sep 19 10:48:57 asgard kernel: [6529561.324934] INFO: task postgres:16827 blocked for more than 120 seconds.
/var/log/kern.log:3060:Sep 19 10:49:51 asgard kernel: [6529561.325129] INFO: task imapd:31749 blocked for more than 120 seconds.
/var/log/kern.log:3084:Sep 19 10:49:51 asgard kernel: [6529561.325248] INFO: task cleanup:32194 blocked for more than 120 seconds.
/var/log/kern.log:3106:Sep 19 10:50:57 asgard kernel: [6529681.324028] INFO: task flush-253:3:3216 blocked for more than 120 seconds.
/var/log/kern.log:3142:Sep 19 10:50:57 asgard kernel: [6529681.324224] INFO: task kjournald:6859 blocked for more than 120 seconds.
/var/log/kern.log:3166:Sep 19 10:50:57 asgard kernel: [6529681.324366] INFO: task syslogd:11720 blocked for more than 120 seconds.
/var/log/kern.log:3198:Sep 19 10:50:57 asgard kernel: [6529681.324574] INFO: task postgres:16827 blocked for more than 120 seconds.
/var/log/kern.log:7152:Sep 19 19:29:41 asgard kernel: [ 1440.617090] INFO: task sendmail:11892 blocked for more than 120 seconds.
最后一次“sendmail”崩溃是在重启机器之后。从那时起，再也没有发生过这样的事件。“imapd”和“postgres”肯定在不同的容器中运行。
好吧，我没看到任何确凿的证据，但我可能只是瞎子。如果没有很好的理由，用已知/假定的良好备份来设置系统对我来说太难了。
我将非常感激您对下一步检查的建议。
感谢您的帮助。
更新：我花了更多精力寻找崩溃的前兆，在系统日志中发现了以下内容：
Sep 19 10:09:56 asgard ntop[7965]: **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]: **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]: **WARNING** packet truncated (10490->8232)
Sep 19 10:09:56 asgard ntop[7965]: **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]: **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]: **WARNING** packet truncated (17442->8232)
Sep 19 10:11:02 asgard ntop[7965]: **WARNING** packet truncated (11650->8232)
Sep 19 10:11:02 asgard ntop[7965]: **WARNING** packet truncated (10202->8232)
Sep 19 10:11:29 asgard ntop[7965]: **WARNING** packet truncated (8754->8232)
Sep 19 10:13:27 asgard ntop[7965]: **WARNING** packet truncated (8754->8232)
Sep 19 10:20:33 asgard ntop[7965]: **WARNING** packet truncated (8754->8232)
我知道这被认为无关紧要，但这似乎是罕见事件。数据包截断只存在于第二次崩溃当天。在所有可用的日志文件中没有其他地方出现。
答案1
这看起来像是 DoS，很可能源自网络或受感染容器内部。
我会研究 vmstat，每 5 秒连续运行一次：vmstat 5，并记录资源消耗的位置。您还可以使用 screen 并在单独的窗口中运行 vmstat 60（每分钟）——这样，当峰值在较长时间内出现时，您就可以注意到它们。
在这种情况下，高/峰值系统 CPU（sy）、高上下文切换率（cs）和高 IO（显示网络和磁盘）将指示 DoS：
$ vmstat 5
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 9584 6820 132432 23256 1 1 136 12 1 1 83 1 15 0 0
0 0 9584 6696 132432 23256 0 0 0 0 20 32 0 0 99 0 1
同时监控主机上的网络流量，我推荐使用ntop，即：
$ nload -t 10000 -u H eth0
答案2
这看起来像是磁盘 I/O 错误。运行 fsck 并检查错误。
答案3
也许您没有任何文件系统错误，但我确信您在日志中看到了警告，因为您有许多进程处于 D 状态（等待 I/O）并且内核正在通知您长时间等待。
答案4
该错误表明您的进程等待的时间太长（120 秒）才能访问磁盘；这种情况发生在磁盘太忙而无法响应进程的高度拥挤的服务器上。
您可以通过检查 vmstat 下的“等待”来确定。