Qu'est-ce qui a tué mon processus et pourquoi ?

Question

Mon application fonctionne comme un processus d'arrière-plan sous Linux. Elle est actuellement lancée à la ligne de commande dans une fenêtre Terminal.

Récemment, un utilisateur a exécuté l'application pendant un certain temps et elle est morte mystérieusement. Le texte :

Tué

était sur le terminal. Cela s'est produit deux fois. J'ai demandé si quelqu'un dans un autre terminal avait utilisé la commande kill pour tuer le processus ? Non.

Dans quelles conditions Linux déciderait-il de tuer mon processus ? Je pense que le shell a affiché "killed" parce que le processus est mort après avoir reçu le signal kill(9). Si Linux a envoyé le signal kill, devrait-il y avoir un message dans un journal système quelque part qui explique pourquoi il a été tué ?

Answer 1

Si l'utilisateur ou le sysadmin n'a pas tué le programme, le noyau peut l'avoir fait. Le noyau ne tue un processus que dans des circonstances exceptionnelles, par exemple en cas d'épuisement extrême des ressources (par exemple, épuisement de mem+swap).

Answer 2

Essayez :

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

Où -B100 signifie le nombre de lignes avant que le kill ne se produise.

Omettre -T sur Mac OS.

Answer 3

Cela ressemble à un bon article sur le sujet: Apprivoiser l'OOM killer.

L'essentiel est que Linux overcommits de la mémoire. Lorsqu'un processus demande plus d'espace, Linux va lui donner de l'espace, même si elle est demandée par un autre processus, sous l'hypothèse que personne n'utilise en fait la totalité de la mémoire qu'ils demandent. Le processus sera usage exclusif de la mémoire qu'il a alloué quand il utilise, non pas quand il le demande. Cela rend l'allocation rapide, et vous permettra peut-être de "tricher" et d'allouer plus de mémoire que vous avez vraiment. Cependant, une fois le processus de démarrage à l'aide de ce mémoire, Linux pourrait rendre compte qu'il a été trop généreux dans l'allocation de mémoire il n'a pas, et aura pour tuer un processus pour libérer de la place. Le processus d'être tué est basée sur un score tenant compte d'exécution (processus long safer), l'utilisation de la mémoire (gourmand processus sont de moins en moins sûr), et quelques autres facteurs, y compris une valeur que vous pouvez ajuster pour faire un processus moins susceptibles d'être tuées. Tout est décrit dans l'article dans beaucoup plus de détails.

Edit: Et voici un autre article qui explique assez bien comment un processus est choisi (annoté avec quelques noyau exemples de code). La grande chose à ce sujet est qu'il comprend des commentaires sur le raisonnement derrière les différents badness() règles.

Answer 4

Comme dwc et Adam Jaskiewicz l'ont dit, le coupable est probablement le tueur d'OOM. Cependant, la prochaine question qui suit est : Comment puis-je empêcher cela ?

Il y a plusieurs façons de procéder :

1. Donnez à votre système plus de RAM si vous le pouvez (facile si c'est une VM)
2. Faites en sorte que le tueur à l'arrêt choisisse un autre processus.
3. Désactiver le tueur d'OOM
4. Choisissez une distribution Linux dans laquelle le tueur d'OOM est désactivé.

J'ai trouvé que (2) était particulièrement facile à mettre en œuvre, grâce à cet article .

Answer 5

Nous avons eu des problèmes récurrents sous Linux sur le site d'un client (Red Hat, je pense), avec OOMKiller (out-of-memory killer) qui a tué à la fois notre application principale (c'est-à-dire la raison d'être du serveur) et ses processus de base de données.

Dans chaque cas, OOMKiller a simplement décidé que les processus utilisaient trop de ressources... la machine n'était même pas sur le point d'échouer par manque de ressources. Ni l'application ni sa base de données n'ont de problèmes de fuites de mémoire (ou toute autre fuite de ressources).

Je ne suis pas un expert de Linux, mais je pense que son algorithme pour décider quand tuer quelque chose et quoi tuer est complexe. De plus, on m'a dit (je ne peux pas dire si c'est exact) que OOMKiller est intégré au noyau et que vous ne pouvez pas simplement ne pas l'exécuter.