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,重新启动它,直到修复程序到位. (openssh 6.5应该有) 该错误在此处报告并修复. https://bugzilla.mindrot.org/show_bug.cgi?id=2156 （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |