Pánico por falta de memoria del kernel (3.2.0) (Debian 7.3) a pesar de que se eliminó el proceso ofensivo

Question

Al intentar realizar una copia de seguridad de una carpeta bastante grande (450G) en una unidad de 2 TB que se encuentra en ese servidor únicamente como destino de la copia de seguridad rdiff-backup(versión 1.2.8 - última marcadaestable) provocó un pánico en el núcleo.

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 en modo RAID espejo de software, 1 disco de 2 TB únicamente para copias de seguridad.

Tengo una sospecha: la memoria del servidor es 2G RAM + 2G swap = 4G. Hay archivos de hasta 16G de tamaño. ¿Es posible que rdiff-backupen algún momento cargue todo el archivo en la memoria?

En cualquier caso, no debería haber ocurrido un pánico en el kernel (¿ya que el proceso rdiff fue eliminado? ¿Entonces la memoria debería haber estado disponible nuevamente?), así que supongo que mi pregunta tiene dos partes, una: sobre mi sospecha, dos: sobre el panico kernel.

Por cierto, el pánico comenzó recientemente, ya se habían realizado con éxito bastantes copias de seguridad (completas e incrementales) y esos archivos de gran tamaño ya estaban allí. Entonces, ¿supongo que es culpa del nuevo kernel de Debian y no de rdiff-backup?

Sección del archivo de registro en el momento en que ocurre el pánicohttp://pastebin.com/e9a5fQdh

Lo último en la pantalla:

EDITAR/Actualizar: Intenté crear un archivo de intercambio de 20 GB (con dd de /dev/zero) y el servidor volvió a CAER, sin reacción ping.

Al mirar los registros: Parece que el kernel ha eliminado algunos procesos, incluido el que sospecho que lo causó todo (rdiff-backup).pero dice "quedarse sin procesos eliminables". ¿Parece que matar los procesos no liberó la memoria?

Answer 1

No eliminó rdiff-backup, debería haberlo hecho, pero oom_score_adjes -1000.

Esto se debe a un error en sshd. El error se solucionó pero no estará disponible hasta la próxima versión, que es openssh 6.5.

sshd no logra establecer el oom_score_adj de los nuevos shells que crea en 0 si lo recarga, lo que hace que todos los procesos secundarios que genere a través de SSH (por lo que su shell bash y cualquier proceso secundario que cree) tengan -1000 oom_score_adjy posteriormente puedan acaparar toda la memoria. sin que el asesino los mate.

La forma más rápida de solucionar este problema es (asumiendo que 7567 es el pid de sshd como en su caso): -

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

No vuelva a cargar sshd, reinícielo hasta que se solucione. (openssh 6.5 lo tendrá)

El error se informa y soluciona aquí.https://bugzilla.mindrot.org/show_bug.cgi?id=2156