killall ne tue pas tout et tue rarement, à quoi sert alors la commande?


12

J'utilise parfois la killallcommande pour tuer des processus. La raison pour laquelle je dis occasionnellement, c'est que dans certains cas, cela n'a pas fonctionné pour moi.

Un exemple récent était avec thunderbird où il y avait environ 5 instances en mémoire donc j'ai décidé d'utiliser la killallcommande. Il a tué 2 processus et 3 étaient encore en mémoire. J'ai encore essayé et les 3 étaient toujours là.

J'ai donc utilisé manuellement la kill -9commande pour tuer chacun des processus individuels via leurs pids. Ça a marché.

J'utilise principalement la kill -9commande car elle fonctionne. La killallcommande m'a laissé tomber tant de fois que je ne me donne même pas la peine de l'utiliser. Mais il doit y avoir une raison pour laquelle cela ne fonctionne pas. Suis-je mal utilisé?

Je sais qu'il existe d'autres commandes, pkillmais je serais reconnaissant de comprendre pourquoi la killallcommande ne fonctionne pas comme prévu. J'ai même essayé de tuer un seul processus et c'est une affaire délicate. Mais la kill -9commande fonctionne à chaque fois.

Des idées?

PS: sudocela ne fait aucune différence

Réponses:


22

Depuis la page de manuel de killall

killall envoie un signal à tous les processus exécutant l'une des commandes spécifiées. Si aucun nom de signal n'est spécifié, SIGTERM est envoyé.

Lorsque vous effectuez un kill -9, vous envoyez le signal SIGKILL. Si vous voulez envoyer un SIGKILL avec killall, vous devez faire

killall -s SIGKILL <PROCESSNAME>

Une bonne explication de la différence entre SIGKILL et SIGTERM (et pourquoi vous devriez essayer SIGTERM en premier)

Depuis http://rackerhacker.com/2010/03/18/sigterm-vs-sigkill/

L'envoi de signaux à des processus utilisant kill sur un système Unix n'est pas un nouveau sujet pour la plupart des administrateurs systèmes, mais on m'a demandé à plusieurs reprises la différence entre kill et kill -9.

Chaque fois que vous utilisez kill sur un processus, vous envoyez en fait un signal au processus (dans presque toutes les situations - j'y reviendrai bientôt). Les applications C standard ont un fichier d'en-tête qui contient les étapes que le processus doit suivre s'il reçoit un signal particulier. Vous pouvez obtenir une liste complète des signaux disponibles sur votre système en consultant la page de manuel de kill.

Considérez une commande comme celle-ci:

kill 2563

Cela enverrait un signal appelé SIGTERM au processus. Une fois que le processus a reçu l'avis, différentes choses peuvent se produire:

  • le processus peut s'arrêter immédiatement
  • le processus peut s'arrêter après un court délai après le nettoyage des ressources
  • le processus peut continuer à fonctionner indéfiniment

L'application peut déterminer ce qu'elle veut faire une fois qu'un SIGTERM est reçu. Alors que la plupart des applications nettoieront leurs ressources et s'arrêteront, certaines peuvent ne pas le faire. Une application peut être configurée pour faire quelque chose de complètement différent quand un SIGTERM est reçu. En outre, si l'application est dans un mauvais état, par exemple en attente d'E / S disque, elle peut ne pas être en mesure d'agir sur le signal envoyé.

La plupart des administrateurs système ont généralement recours au signal le plus brutal lorsqu'une application ne répond pas à un SIGTERM:

kill -9 2563

Le -9 indique à la commande kill que vous souhaitez envoyer le signal # 9, qui est appelé SIGKILL. Avec un nom comme ça, il est évident que ce signal a un peu plus de poids.

Bien que SIGKILL soit défini dans le même fichier d'en-tête de signal que SIGTERM, il ne peut pas être ignoré par le processus. En fait, le processus est même pas mis au courant du signal SIGKILL puisque le signal va droit au init noyau. À ce stade, init arrêtera le processus. Le processus ne fait jamais l'occasion de prendre le signal et agir sur elle.

Cependant, le noyau ne peut pas être en mesure de tuer avec succès le processus dans certaines situations. Si le processus est en attente d'E / S réseau ou d'un disque, le noyau ne sera pas en mesure de l'arrêter. les processus et les processus zombies pris dans un sommeil sans coupure ne peut pas être arrêté par le noyau, que ce soit. Un redémarrage est nécessaire pour effacer les processus du système.

Lorsque vous avez envoyé killall (SIGTERM) aux processus de thunderbird, vous avez demandé les processus de l'arrêt. Certains de ces processus ne fonctionnaient pas correctement (probablement pourquoi vous deviez les tuer en premier lieu), ils ne pouvaient donc pas agir sur le signal SIGTERM.


Toute spéculation sur pourquoi il n'a tué quelques - uns des instances de thunderbird?
Meer Borg

@Doogfar Voir mon article édité (ou la page que j'ai liée)
tgm4883

Merci, explique aussi pourquoi mon Thunderbird corrompu, kill -9 était trop sévère
Meer Borg

Ne fonctionne toujours pas toujours.
Craig Hicks

4

killallaccepte la plupart du même syntaxe que kill. En particulier, il n'y a pas besoin de quoi que ce soit d'écriture de fantaisie pour faire killallfaire l'équivalent de kill -9. Cela fonctionne très bien:

killall -9 thunderbird

(Bien sûr, comme discuté, vous devez généralement être réticents à utiliser killall -9ou, ce qui revient, killall -KILLà moins que d' autres mesures ont déjà été essayées sans succès.)


Ne fonctionne pas toujours là toujours aussi doit être autre chose.
Craig Hicks
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.