☰

Out-of-Memory-Kernel (3.2.0)-Panik (Debian 7.3), obwohl der fehlerhafte Prozess beendet wurde

tag-icon • tag-icon linux debian kernel-panic rdiff-backup outofmemoryerror
Out-of-Memory-Kernel (3.2.0)-Panik (Debian 7.3), obwohl der fehlerhafte Prozess beendet wurde

Beim Versuch, ein Backup eines ziemlich großen Ordners (450G) auf ein 2TB-Laufwerk zu erstellen, das sich auf diesem Server ausschließlich als Backup-Ziel befindet rdiff-backup(Version 1.2.8 - zuletzt markiertstabil) verursachte einen Kernel Panic.

System:

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

Festplatten: 2 1-TB-Festplatten im Software-Mirror-RAID-Modus, 1 2-TB-Festplatte ausschließlich für Backups.

Ich habe einen Verdacht: Der Speicher auf dem Server beträgt 2G RAM + 2G Swap = 4G. Es sind Dateien bis zu 16G groß. Ist es möglich, dass rdiff-backupirgendwann die gesamte Datei in den Speicher geladen wird?

Auf jeden Fall hätte es nicht zu einem Kernel-Panic kommen dürfen (da der Rdiff-Prozess beendet wurde? Also hätte der Speicher wieder verfügbar gemacht werden müssen?). Meine Frage besteht also vermutlich aus zwei Teilen: Erstens zu meinem Verdacht und zweitens zu dem Kernel-Panic.

Übrigens begannen die Panikattacken vor Kurzem, eine ganze Reihe von Backups waren bereits erfolgreich – vollständig und inkrementell – und diese großen GB-Dateien waren bereits vorhanden. Ich vermute also, dass es eher die Schuld des neuen Debian-Kernels ist als die von rdiff-backup?

Abschnitt der Protokolldatei zum Zeitpunkt der Panikhttp://pastebin.com/e9a5fQdh

Letztes auf dem Bildschirm:

BEARBEITEN/Aktualisieren: Ich habe gerade versucht, eine 20 GB große Auslagerungsdatei zu erstellen (mit dd von /dev/zero) und der Server ist erneut AUSGEFALLEN, keine Reaktion darauf ping.

Aus den Protokollen geht hervor, dass der Kernel einige Prozesse beendet hat - darunter auch den, von dem ich vermute, dass er alles verursacht hat (rdiff-backup) -aber es wird angezeigt, dass „keine Prozesse mehr vorhanden sind, die beendet werden können“. Es scheint, als ob das Beenden der Prozesse den Speicher nicht freigegeben hat?

Antwort1

Es hat rdiff-backup nicht beendet, obwohl es das hätte tun sollen, aber es oom_score_adjsteht -1000.

Dies wird durch einen Fehler in sshd verursacht. Der Fehler wurde behoben, ist aber erst mit der nächsten Version (OpenSh 6.5) verfügbar.

sshd kann den oom_score_adj neuer Shells, die es erstellt, nicht auf 0 zurücksetzen, wenn Sie es neu laden. Dadurch haben alle Kindprozesse, die Sie über SSH starten (also Ihre Bash-Shell und alle Kindprozesse, die sie erstellt), -1000 oom_score_adjund können in der Folge den gesamten Speicher beanspruchen, ohne dass oom-killer sie beendet.

Dies lässt sich am schnellsten wie folgt beheben (vorausgesetzt, 7567 ist wie in Ihrem Fall die PID von SSHD): -

  • Laufenecho 0 >/proc/7567/oom_adj_score
  • Starten Sie sshd neu.

Laden Sie sshd nicht neu, sondern starten Sie es neu, bis der Fix vorhanden ist. (OpenSSH 6.5 sollte ihn haben)

Der Fehler wird hier gemeldet und behoben.https://bugzilla.mindrot.org/show_bug.cgi?id=2156

verwandte Informationen