Kernel sem memória (3.2.0) pânico (Debian 7.3) mesmo que o processo ofensivo tenha sido eliminado

Question

Ao tentar fazer backup de uma pasta muito grande (450G) em uma unidade de 2 TB que está naquele servidor apenas como destino de backup rdiff-backup(versão 1.2.8 - última marcadaestábulo) causou um pânico no kernel.

Sistema:

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

Discos: 2 discos de 1 TB em modo RAID de espelho de software, 1 disco de 2 TB somente para backups.

Tenho uma suspeita: a memória do servidor é 2G RAM + 2G swap = 4G. Existem arquivos de até 16G de tamanho. É possível que rdiff-backupem algum momento carregue o arquivo inteiro na memória?

De qualquer forma, um kernel panic não deveria ter acontecido (já que o processo rdiff foi eliminado? então a memória deveria ter sido disponibilizada novamente?), então acho que minha pergunta tem duas partes, uma: sobre minha suspeita, duas: sobre o pânico do núcleo.

A propósito, o pânico começou recentemente, vários backups já haviam sido bem-sucedidos - completos e incrementais - e aqueles grandes arquivos de GB já estavam lá. Então eu acho que é culpa do novo kernel Debian e não do rdiff-backup?

Seção do arquivo de log no momento em que o pânico acontecehttp://pastebin.com/e9a5fQdh

Última coisa na tela:

EDIT/Atualização: Tentei criar um arquivo de troca de 20 GB (com dd de/dev/zero) e o servidor caiu novamente, sem reação a ping.

Olhando os logs: parece que o kernel eliminou alguns processos - incluindo aquele que suspeito ter causado tudo (rdiff-backup) -mas diz "ficando sem processos elimináveis". Parece que matar os processos não liberou memória?

Answer 1

Ele não matou o rdiff-backup, deveria ter matado, mas oom_score_adjé -1000.

Isso é causado por um bug no sshd. O bug foi corrigido, mas não estará disponível até a próxima versão, que é o openssh 6.5.

sshd falha ao definir o oom_score_adj de novos shells que ele cria de volta para 0 se você recarregá-lo, fazendo com que todos os processos filhos gerados via SSH (portanto, seu shell bash e quaisquer processos filhos criados) tenham -1000 oom_score_adje, posteriormente, possam ocupar toda a memória sem oom-killer matá-los.

A maneira mais rápida de corrigir isso é (assumindo que 7567 é o pid do sshd como no seu caso): –

• Correrecho 0 >/proc/7567/oom_adj_score
• Reinicie o sshd.

Não recarregue o sshd, reinicie-o até que a correção esteja implementada. (openssh 6.5 deve tê-lo)

O bug é relatado e corrigido aqui.https://bugzilla.mindrot.org/show_bug.cgi?id=2156