it-swarm.com.de

Was hat meinen Prozess getötet und warum?

Meine Anwendung läuft als Hintergrundprozess unter Linux. Es wird derzeit über die Befehlszeile in einem Terminalfenster gestartet.

Vor kurzem hat ein Benutzer die Anwendung für eine Weile ausgeführt und er starb auf mysteriöse Weise. Der Text:

Getötet

war auf dem Terminal. Das passierte zweimal. Ich habe gefragt, ob jemand an einem anderen Terminal den Befehl kill verwendet hat, um den Prozess zu beenden. Nein.

Unter welchen Bedingungen würde Linux meinen Prozess beenden? Ich glaube, dass die Shell "getötet" angezeigt hat, weil der Prozess nach Erhalt des Kill-Signals (9) gestorben ist. Wenn das Kill-Signal von Linux gesendet wurde, sollte irgendwo in einem Systemprotokoll eine Nachricht angezeigt werden, aus der hervorgeht, warum es getötet wurde?

505
sbq

Wenn der Benutzer oder sysadmin das Programm nicht beendet hat, hat der Kernel möglicherweise einen Fehler. Der Kernel würde einen Prozess nur unter außergewöhnlichen Umständen wie extremem Ressourcenhunger beenden (Think Mem + Swap-Erschöpfung).

337
dwc

Versuchen:

dmesg -T| grep -E -i -B100 'killed process'

Dabei gibt -B100 die Anzahl der Zeilen an, bevor der Abbruch stattgefunden hat.

Lassen Sie -T unter Mac OS aus.

201

Das sieht nach einem guten Artikel zum Thema aus: Die OOM-Killer zähmen .

Das Wichtigste ist, dass Linux overcommits Speicher ist. Wenn ein Prozess nach mehr Speicherplatz fragt, gibt Linux ihm diesen Speicherplatz, selbst wenn er von einem anderen Prozess beansprucht wird, unter der Annahme, dass niemand den gesamten Speicher benötigt, nach dem er gefragt wird. Der Prozess wird exklusiv den Speicher nutzen, den er zugewiesen hat, wenn er ihn tatsächlich verwendet, nicht wenn er danach fragt. Dies macht die Zuweisung schnell und ermöglicht es Ihnen möglicherweise, zu "betrügen" und mehr Speicher zuzuordnen, als Sie tatsächlich haben. Sobald Prozesse jedoch diesen Speicher verwenden, wird Linux möglicherweise feststellen, dass er bei der Zuweisung von Arbeitsspeicher zu großzügig war, den er nicht hat, und er muss einen Prozess beenden, um Speicherplatz freizugeben. Der Prozess, der beendet werden muss, basiert auf einer Bewertung unter Berücksichtigung der Laufzeit (langlaufende Prozesse sind sicherer), der Speicherauslastung (gierige Prozesse sind weniger sicher) und einigen anderen Faktoren, einschließlich eines Werts, den Sie anpassen können, um einen Prozess zu reduzieren wahrscheinlich getötet werden. Es ist alles in dem Artikel ausführlicher beschrieben.

Edit: Und hier ist ein weiterer Artikel der ziemlich gut erklärt, wie ein Prozess ausgewählt wird (kommentiert mit einigen Kernel-Code-Beispielen). Das Tolle daran ist, dass es einige Kommentare zu den reasoning hinter den verschiedenen badness()-Regeln enthält.

156
Adam Jaskiewicz

Lassen Sie mich zuerst erklären, wann und warum OOMKiller aufgerufen wird.

Angenommen, Sie haben 512 RAM + 1 GB Arbeitsspeicher. Theoretisch hat Ihre CPU also Zugriff auf insgesamt 1,5 GB virtuellen Speicher.

Seit einiger Zeit läuft alles innerhalb von 1,5 GB des Gesamtspeichers. Aber plötzlich (oder allmählich) hat Ihr System angefangen, mehr und mehr Speicher zu verbrauchen, und es erreichte zu einem Zeitpunkt rund 95% des gesamten Speicherplatzes.

Nehmen wir jetzt an, dass jeder Prozess einen großen Teil des Speichers vom Kernel angefordert hat. Überprüfen Sie den Kernel auf den verfügbaren Speicher und stellen Sie fest, dass er Ihrem Prozess auf keinen Fall mehr Speicher zuweisen kann. Es wird also versucht, Speicherplatz freizugeben, der OOMKiller ( http://linux-mm.org/OOM ) aufruft.

OOMKiller verfügt über einen eigenen Algorithmus, um den Rang für jeden Prozess zu bewerten. In der Regel wird bei dem Prozess, der mehr Speicher benötigt, das Opfer getötet.

Wo finde ich Protokolle von OOMKiller?

Normalerweise im Verzeichnis/var/log. Entweder /var/log/kern.log oder/var/log/dmesg

Hoffe, das wird dir helfen.

Einige typische Lösungen:

  1. Speicher erhöhen (nicht tauschen) 
  2. Finden Sie die Speicherlecks in Ihrem Programm und beheben Sie diese 
  3. Speicher einschränken, den jeder Prozess beanspruchen kann (JVM-Speicher kann beispielsweise mit Java_OPTS eingeschränkt werden) 
  4. Siehe die Protokolle und google :)
37
Jadav Bheda

Dies ist der Linux Out of Memory Manager (OOM) . Ihr Prozess wurde aufgrund von " badness " ausgewählt - einer Kombination aus Aktualität, Einwohnergröße (belegter Speicher, nicht nur zugewiesen) und anderen Faktoren.

Sudo journalctl -xb

Sie sehen eine Nachricht wie:

Jul 20 11:05:00 someapp kernel: Mem-Info:
Jul 20 11:05:00 someapp kernel: Node 0 DMA per-cpu:
Jul 20 11:05:00 someapp kernel: CPU    0: hi:    0, btch:   1 usd:   0
Jul 20 11:05:00 someapp kernel: Node 0 DMA32 per-cpu:
Jul 20 11:05:00 someapp kernel: CPU    0: hi:  186, btch:  31 usd:  30
Jul 20 11:05:00 someapp kernel: active_anon:206043 inactive_anon:6347 isolated_anon:0
                                    active_file:722 inactive_file:4126 isolated_file:0
                                    unevictable:0 dirty:5 writeback:0 unstable:0
                                    free:12202 slab_reclaimable:3849 slab_unreclaimable:14574
                                    mapped:792 shmem:12802 pagetables:1651 bounce:0
                                    free_cma:0
Jul 20 11:05:00 someapp kernel: Node 0 DMA free:4576kB min:708kB low:884kB high:1060kB active_anon:10012kB inactive_anon:488kB active_file:4kB inactive_file:4kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present
Jul 20 11:05:00 someapp kernel: lowmem_reserve[]: 0 968 968 968
Jul 20 11:05:00 someapp kernel: Node 0 DMA32 free:44232kB min:44344kB low:55428kB high:66516kB active_anon:814160kB inactive_anon:24900kB active_file:2884kB inactive_file:16500kB unevictable:0kB isolated(anon):0kB isolated
Jul 20 11:05:00 someapp kernel: lowmem_reserve[]: 0 0 0 0
Jul 20 11:05:00 someapp kernel: Node 0 DMA: 17*4kB (UEM) 22*8kB (UEM) 15*16kB (UEM) 12*32kB (UEM) 8*64kB (E) 9*128kB (UEM) 2*256kB (UE) 3*512kB (UM) 0*1024kB 0*2048kB 0*4096kB = 4580kB
Jul 20 11:05:00 someapp kernel: Node 0 DMA32: 216*4kB (UE) 601*8kB (UE) 448*16kB (UE) 311*32kB (UEM) 135*64kB (UEM) 74*128kB (UEM) 5*256kB (EM) 0*512kB 0*1024kB 1*2048kB (R) 0*4096kB = 44232kB
Jul 20 11:05:00 someapp kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
Jul 20 11:05:00 someapp kernel: 17656 total pagecache pages
Jul 20 11:05:00 someapp kernel: 0 pages in swap cache
Jul 20 11:05:00 someapp kernel: Swap cache stats: add 0, delete 0, find 0/0
Jul 20 11:05:00 someapp kernel: Free swap  = 0kB
Jul 20 11:05:00 someapp kernel: Total swap = 0kB
Jul 20 11:05:00 someapp kernel: 262141 pages RAM
Jul 20 11:05:00 someapp kernel: 7645 pages reserved
Jul 20 11:05:00 someapp kernel: 264073 pages shared
Jul 20 11:05:00 someapp kernel: 240240 pages non-shared
Jul 20 11:05:00 someapp kernel: [ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name
Jul 20 11:05:00 someapp kernel: [  241]     0   241    13581     1610      26        0             0 systemd-journal
Jul 20 11:05:00 someapp kernel: [  246]     0   246    10494      133      22        0         -1000 systemd-udevd
Jul 20 11:05:00 someapp kernel: [  264]     0   264    29174      121      26        0         -1000 auditd
Jul 20 11:05:00 someapp kernel: [  342]     0   342    94449      466      67        0             0 NetworkManager
Jul 20 11:05:00 someapp kernel: [  346]     0   346   137495     3125      88        0             0 tuned
Jul 20 11:05:00 someapp kernel: [  348]     0   348    79595      726      60        0             0 rsyslogd
Jul 20 11:05:00 someapp kernel: [  353]    70   353     6986       72      19        0             0 avahi-daemon
Jul 20 11:05:00 someapp kernel: [  362]    70   362     6986       58      18        0             0 avahi-daemon
Jul 20 11:05:00 someapp kernel: [  378]     0   378     1621       25       8        0             0 iprinit
Jul 20 11:05:00 someapp kernel: [  380]     0   380     1621       26       9        0             0 iprupdate
Jul 20 11:05:00 someapp kernel: [  384]    81   384     6676      142      18        0          -900 dbus-daemon
Jul 20 11:05:00 someapp kernel: [  385]     0   385     8671       83      21        0             0 systemd-logind
Jul 20 11:05:00 someapp kernel: [  386]     0   386    31573      153      15        0             0 crond
Jul 20 11:05:00 someapp kernel: [  391]   999   391   128531     2440      48        0             0 polkitd
Jul 20 11:05:00 someapp kernel: [  400]     0   400     9781       23       8        0             0 iprdump
Jul 20 11:05:00 someapp kernel: [  419]     0   419    27501       32      10        0             0 agetty
Jul 20 11:05:00 someapp kernel: [  855]     0   855    22883      258      43        0             0 master
Jul 20 11:05:00 someapp kernel: [  862]    89   862    22926      254      44        0             0 qmgr
Jul 20 11:05:00 someapp kernel: [23631]     0 23631    20698      211      43        0         -1000 sshd
Jul 20 11:05:00 someapp kernel: [12884]     0 12884    81885     3754      80        0             0 firewalld
Jul 20 11:05:00 someapp kernel: [18130]     0 18130    33359      291      65        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18132]  1000 18132    33791      748      64        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18133]  1000 18133    28867      122      13        0             0 bash
Jul 20 11:05:00 someapp kernel: [18428]    99 18428   208627    42909     151        0             0 node
Jul 20 11:05:00 someapp kernel: [18486]    89 18486    22909      250      46        0             0 pickup
Jul 20 11:05:00 someapp kernel: [18515]  1000 18515   352905   141851     470        0             0 npm
Jul 20 11:05:00 someapp kernel: [18520]     0 18520    33359      291      66        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18522]  1000 18522    33359      294      64        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18523]  1000 18523    28866      115      12        0             0 bash
Jul 20 11:05:00 someapp kernel: Out of memory: Kill process 18515 (npm) score 559 or sacrifice child
Jul 20 11:05:00 someapp kernel: Killed process 18515 (npm) total-vm:1411620kB, anon-rss:567404kB, file-rss:0kB
14
mikemaccana

Wie dwc und Adam Jaskiewicz festgestellt haben, ist der Täter wahrscheinlich der OOM-Killer. Die nächste Frage 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 sich um eine VM handelt)
  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 (2) dank diesem Artikel besonders einfach zu implementieren. 

11
Carl

Das PAM-Modul zur Begrenzung von Ressourcen hat genau die Ergebnisse hervorgerufen, die Sie beschrieben haben: Mein Prozess ist auf mysteriöse Weise mit dem Text Killed im Konsolenfenster gestorben. Keine Protokollausgabe, weder in syslog noch in kern.log. Das Programm top hat mir dabei geholfen herauszufinden, dass genau nach einer Minute CPU-Nutzung mein Prozess beendet wird. 

8
Christian Ammer

Ein Tool wie systemtap (oder ein Tracer) kann die Signalübertragungslogik des Kernels überwachen und Berichte erstellen. z. B. https://sourceware.org/systemtap/examples/process/sigmon.stp

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

Der Filter if-Block in diesem Skript kann je nach Geschmack angepasst oder gelöscht werden, um den systemweiten Signalverkehr zu verfolgen. Die Ursachen können weiter isoliert werden, indem Rückverfolgungen gesammelt werden (fügen Sie der Sonde eine print_backtrace() und/oder print_ubacktrace() für Kernel bzw. Userspace hinzu).

7
fche

In einer lsf-Umgebung (interaktiv oder auf andere Weise), wenn die Anwendung die Speicherauslastung über einen bestimmten Schwellenwert durch die Administratoren in der Warteschlange oder die Ressourcenanforderung beim Senden an die Warteschlange überschreitet, werden die Prozesse beendet, sodass andere Benutzer nicht einem potenziellen Opfer zum Opfer fallen weglaufen. Es sendet nicht immer eine E-Mail, wenn dies der Fall ist, abhängig von der Einrichtung.

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

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

Obwohl ich mich nicht an ulimit erinnere, ist Killed schon eine Weile her, seit ich das brauchte.

4
oldman

Unter Linux hatten wir immer wieder Probleme bei einem Kunden (Red Hat, glaube ich), wobei OOMKiller (Out-of-Memory-Killer) sowohl unsere Hauptanwendung (d. H. Den Grund, warum der Server existiert) als auch seine Datenbankprozesse beendet. 

In jedem Fall entschied OOMKiller einfach, dass die Prozesse zu viele Ressourcen verbrauchen. Die Maschine konnte nicht einmal aus Mangel an Ressourcen ausfallen. Weder die Anwendung noch ihre Datenbank haben Probleme mit Speicherverlusten (oder einem anderen Ressourcenleck).

Ich bin kein Linux-Experte, aber ich habe eher einen Algorithmus zusammengestellt, um zu entscheiden, wann etwas zu töten ist und was zu töten ist komplex. Mir wurde auch gesagt (ich kann nicht sagen, wie genau das ist), dass OOMKiller im Kernel gebacken ist und man es nicht einfach ausführen kann.

2
Lawrence Dol

Dieses Problem wurde behoben, indem Swap-Größe erhöht wurde :

https://askubuntu.com/questions/1075505/how-do-i-increase-swapfile-in-ubuntu-18-04

0
Lejla

In letzter Zeit bin ich auf dieses Problem gestoßen. Schließlich fand ich heraus, dass meine Prozesse kurz nach dem automatischen Aufruf des Opensuse Zypper-Updates abgebrochen wurden. Zum Deaktivieren des Zypper-Updates wurde mein Problem behoben.

0
poordeveloper

Der Benutzer hat die Möglichkeit, seine eigenen Programme mithilfe von kill oder Control + C zu beenden. Ich habe jedoch den Eindruck, dass dies nicht der Fall ist und der Benutzer sich bei Ihnen beschwert hat.

root hat natürlich die Möglichkeit, Programme zu töten, aber wenn jemand root auf Ihrem Rechner hat und Sachen tötet, haben Sie größere Probleme.

Wenn Sie nicht der Systemadministrator sind, hat der Systemadministrator möglicherweise Kontingente für CPU-, RAM-, Speicherort- und Auto-Kill-Prozesse festgelegt, die diese Werte überschreiten.

Abgesehen von diesen Vermutungen bin ich ohne weitere Informationen zum Programm nicht sicher.

0
Tom Ritter

In meinem Fall geschah dies mit einem Laravel-Warteschlangenarbeiter. In den Systemprotokollen wurde kein Mord erwähnt, also schaute ich weiter und es stellte sich heraus, dass der Arbeiter sich im Grunde selbst tötete, weil ein Job die Speichergrenze überschritten hatte (die standardmäßig auf 128 MB eingestellt ist).

Das Ausführen des Warteschlangenarbeiters mit --timeout=600 und --memory=1024 hat das Problem für mich behoben.

0
iSWORD