Was hat meinen Prozess gestoppt und warum?

Question

Meine Anwendung läuft als Hintergrundprozess unter Linux. Sie wird derzeit über die Kommandozeile in einem Terminal-Fenster gestartet.

Kürzlich führte ein Benutzer die Anwendung eine Zeit lang aus und sie starb auf mysteriöse Weise. Der Text:

Getötet

war auf dem Terminal. Dies geschah zwei Mal. Ich fragte, ob jemand an einem anderen Terminal den Befehl kill verwendet hat, um den Prozess zu beenden? Nein.

Unter welchen Bedingungen würde Linux beschließen, meinen Prozess zu beenden? Ich glaube, die Shell hat "killed" angezeigt, weil der Prozess nach dem Empfang des kill(9)-Signals gestorben ist. Wenn Linux das kill-Signal gesendet hat, sollte dann irgendwo in einem Systemprotokoll eine Meldung erscheinen, die erklärt, warum der Prozess beendet wurde?

Answer 1

Wie dwc und Adam Jaskiewicz festgestellt haben, ist der Übeltäter wahrscheinlich der OOM-Killer. Die nächste Frage, die sich daraus ergibt, lautet jedoch: Wie kann ich das verhindern?

Es gibt mehrere Möglichkeiten:

1. Geben Sie Ihrem System mehr RAM, wenn Sie können (einfach, wenn es eine VM ist)
2. Stellen Sie sicher, dass der OOM-Killer einen anderen Prozess wählt.
3. Deaktivieren Sie den OOM-Killer
4. Wählen Sie eine Linux-Distribution, bei der der OOM-Killer deaktiviert ist.

Ich fand, dass (2) besonders einfach zu implementieren war, dank der dieser Artikel .

Answer 2

Ein Tool wie systemtap (oder ein Tracer) kann die Kernel-Signalübertragungslogik überwachen und einen Bericht erstellen. z.B., https://sourceware.org/systemtap/examples/process/sigmon.stp

# stap --example sigmon.stp -x 31994 SIGKILL
   SPID     SNAME            RPID  RNAME            SIGNUM SIGNAME
   5609     bash             31994 find             9      SIGKILL

Die Filterung if Block in diesem Skript kann nach Belieben angepasst oder eliminiert werden, um den systemweiten Signalverkehr zu verfolgen. Die Ursachen können weiter isoliert werden, indem Backtraces gesammelt werden (fügen Sie ein print_backtrace() und/oder print_ubacktrace() zur Sonde, für Kernel- bzw. Userspace-).

Answer 3

Le site PAM-Modul zur Begrenzung von Ressourcen verursachte genau die von Ihnen beschriebenen Ergebnisse: Mein Prozess starb auf mysteriöse Weise mit dem Text Getötet im Konsolenfenster. Keine Log-Ausgabe, weder in syslog noch in kern.log . Die top Programm hat mir geholfen, herauszufinden, dass mein Prozess genau nach einer Minute CPU-Auslastung beendet wird.

Answer 4

In einer LSF-Umgebung (interaktiv oder anderweitig) werden die Prozesse beendet, wenn die Anwendung die von den Admins in der Warteschlange oder der Ressourcenanforderung in der Warteschlange festgelegte Speicherauslastung überschreitet, damit andere Benutzer nicht Opfer eines möglichen Ausreißers werden. Je nach Einstellung wird nicht immer eine E-Mail verschickt, wenn dies der Fall ist.

Eine Lösung besteht in diesem Fall darin, eine Warteschlange mit größeren Ressourcen zu finden oder größere Ressourcenanforderungen in der Anmeldung zu definieren.

Sie können auch Folgendes überprüfen man ulimit

Obwohl ich mich nicht erinnern kann ulimit was zu Killed Es ist eine Weile her, dass ich das gebraucht habe.

Answer 5

In meinem Fall geschah dies mit einem Laravel-Warteschlangenarbeiter. In den Systemprotokollen wurde keine Tötung erwähnt, also habe ich weiter gesucht und es stellte sich heraus, dass der Worker sich im Grunde selbst tötete, weil ein Auftrag die Speichergrenze (die standardmäßig auf 128 MB festgelegt ist) überschritten hatte.

Ausführen des Queue Workers mit --timeout=600 y --memory=1024 hat das Problem für mich behoben.