Pânico do kernel de falta de memória (3.2.0) (Debian 7.3) mesmo que o processo de ofensa tenha sido morto

Question

Durante a tentativa de backup de uma pasta muito grande (450G) para uma unidade de 2Tb que está nesse servidor apenas como destino de backup rdiff-backup (versão 1.2.8 - última marcada estável ) causou uma falha pânico do 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 no modo RAID espelho do software, 1 disco de 2 TB apenas para backups.

Eu tenho uma suspeita: a memória no servidor é 2G RAM + 2G swap = 4G. Existem arquivos com tamanho até 16G. É possível que rdiff-backup em algum momento carregue o arquivo inteiro na memória?

Em qualquer caso, um pânico no kernel não deveria ter acontecido (já que o processo rdiff foi morto? então a memória deveria ter sido disponibilizada novamente?), então eu acho que minha pergunta tem duas partes, uma sobre minha suspeita, duas : sobre o pânico do kernel.

A propósito, os pânicos começaram recentemente, vários backups já foram bem-sucedidos - completos e incrementais - e esses arquivos GB grandes já estavam lá. Então eu acho que é a falha do novo kernel do Debian ao invés do erro do rdiff-backup?

Seção do arquivo de registro no momento em que o pânico acontece link

Última coisa na tela:

EDIT/Update:Euapenastenteicriarumarquivodeswapde20GB(comddde/dev/zero)eoservidordesceunovamente,semreaçãoaping.

Deolharparaoslogs:Parecequeokernelmatoualgunsprocessos-incluindooqueeususpeitodetercausadotudo(rdiff-backup)-masdizque"está ficando sem processos elimináveis". Parece que matar os processos não liberou a memória?

    

Answer 1

Ele não matou o rdiff-backup, ele deve ter, mas seu oom_score_adj é -1000.

Isso é causado por um bug no sshd. O bug é 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ê recarregar, fazendo com que todos os processos filhos que você gera via SSH (assim seu shell bash e qualquer processo filho que cria) tenham -1000 oom_score_adj e subseqüentemente pode roubar 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): -

• Executar echo 0 >/proc/7567/oom_adj_score
• Reinicie o sshd.

Não recarregue o sshd, reinicie-o até que a correção esteja no lugar. (openssh 6.5 terá)

O bug é reportado e corrigido aqui. link