linux – 内存不足的内核(3.2.0)恐慌(Debian 7.3)即使攻击过程被杀死了

尝试将一个非常大的文件夹(450G)备份到2TB驱动器时,该服务器仅作为备份目标rdiff-backup(版本1.2.8 – 最后标记为稳定),导致内核崩溃.

系统：

Linux giorgio 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux

磁盘：2个1TB磁盘,采用软件镜像RAID模式,1个2TB磁盘,仅用于备份.

我有一个怀疑：服务器上的内存是2G RAM 2G swap = 4G.有最大16G的文件.是否有可能rdiff-backup在某个时刻将整个文件加载到内存中？

在任何情况下,都不应该发生内核恐慌(因为rdiff进程被杀了？所以内存应该再次可用？),所以我想我的问题有两部分,一部分：关于我的怀疑,两部分：关于内核恐慌.

顺便说一句,恐慌最近开始了,相当多的备份已经成功 – 完全和增量 – 并且那些大GB文件已经存在.所以我猜这是新的Debian内核的错,而不是rdiff-backup的？

当恐慌发生http://pastebin.com/e9a5fQdh时的日志文件部分

屏幕上的最后一件事：

编辑/更新：我刚尝试创建一个20GB的交换文件(dd来自/ dev / zero),服务器再次关闭,对ping没有反应.

从查看日志：内核似乎已经杀死了一些进程 – 包括我怀疑已经造成这一切的进程(rdiff-backup) – 但是说“用完了可用的进程”.似乎杀死进程并没有释放内存？

它没有杀死rdiff-backup,它应该有,但它的oom_score_adj是-1000.

这是由sshd中的错误引起的.该错误是固定的,但在下一个版本是openssh 6.5之前不可用.

如果你重新加载它,sshd无法将它创建的新shell的oom_score_adj设置回0,导致你通过SSH生成的所有子进程(所以你的bash shell和创建的所有子进程)都有-1000 oom_score_adj,然后可以占用所有没有oom-killer杀死他们的记忆.

解决这个问题的最快方法是(假设7567是sshd的pid,就像你的情况一样)： –

>运行echo 0> / proc / 7567 / oom_adj_score
>重新启动sshd.

不要重新加载sshd,重新启动它,直到修复程序到位. (openssh 6.5应该有)

相关文章