Quand ne dois-je pas tuer -9 un processus?
J'hésite toujours beaucoup à courir kill -9, mais je vois d'autres administrateurs le faire presque régulièrement.
Je pense qu'il y a probablement un juste milieu sensible, donc:
- Quand et pourquoi
kill -9être utilisé? Quand et pourquoi pas? - Que faut-il essayer avant de le faire?
- Quel type de débogage d'un processus "bloqué" pourrait causer d'autres problèmes?
En règle générale, vous devez utiliser kill (abréviation de kill -s TERM, ou sur la plupart des systèmes kill -15) avant kill -9 (kill -s KILL) pour donner au processus cible une chance de se nettoyer après lui-même. (Les processus ne peuvent pas attraper ou ignorer SIGKILL, mais ils peuvent et attrapent souvent SIGTERM.) Si vous ne donnez pas au processus une chance de terminer ce qu'il fait et de nettoyer, il peut laisser des fichiers corrompus (ou un autre état) autour qu'il ne pourra pas comprendre une fois redémarré.
strace/truss, ltrace et gdb sont généralement de bonnes idées pour savoir pourquoi un processus bloqué est bloqué. (truss -u sur Solaris est particulièrement utile; Je trouve que ltrace présente trop souvent des arguments aux appels de bibliothèque dans un format inutilisable.) Solaris a également /proc - des outils basés, dont certains ont été portés sur Linux. (pstack est souvent utile).
Randal Schwartz publiait fréquemment "Utilisation inutile de (x)" sur des listes. Un de ces messages portait sur kill -9. Il comprend des raisons et une recette à suivre. Voici une version reconstruite (cité ci-dessous).
(Citation abomination)
Non non Non. N'utilisez pas kill -9.
Cela ne donne pas au processus une chance de proprement:
1) coupez les connexions des prises
2) nettoyer les fichiers temporaires
3) informer ses enfants qu'il s'en va
4) réinitialiser ses caractéristiques de terminal
et ainsi de suite et ainsi de suite et ainsi de suite.
En général, envoyez 15, et attendez une seconde ou deux, et si cela ne fonctionne pas, envoyez 2, et si cela ne fonctionne pas, envoyez 1. Si cela ne fonctionne pas, RETIREZ LE BINAIRE parce que le programme se comporte mal!
N'utilisez pas kill -9. Ne sortez pas la moissonneuse-batteuse juste pour ranger le pot de fleurs.
Juste une autre utilisation inutile d'Usenet,
(.Signature)
Il devrait toujours être OK de faire kill -9, tout comme il devrait toujours être possible d'arrêter en tirant sur le câble d'alimentation. Il peut être antisocial et laisser un certain rétablissement à faire, mais il devrait fonctionner et est un outil puissant pour les impatients.
Je dis cela en tant que quelqu'un qui essaiera d'abord plain kill (15), car cela donne à un programme une chance de faire un peu de nettoyage - peut-être simplement en écrivant dans un journal "sortie sur sig 15". Mais je n'accepterai aucune plainte pour mauvais comportement lors d'un kill -9.
La raison: beaucoup de clients préfèrent les choses que les programmeurs préfèrent ne pas faire. Le test de destruction aléatoire -9 est un scénario de test bon et équitable, et si votre système ne le gère pas, votre système est en panne.
J'utilise kill -9 de la même manière que je jette des ustensiles de cuisine au lave-vaisselle: si un ustensile de cuisine est ruiné par le lave-vaisselle, je n'en veux pas.
Il en va de même pour les programmes la plupart (même les bases de données): si je ne peux pas les tuer sans que les choses tournent mal, je ne veux pas vraiment les utiliser. (Et s'il vous arrive d'utiliser une de ces non-bases de données qui vous encourage à prétendre qu'elles ont persisté des données alors qu'elles ne l'ont pas: eh bien, je suppose qu'il est temps que vous commenciez à penser à ce que vous faites).
Parce que dans le monde réel, les choses peuvent baisser à tout moment pour n'importe quelle raison.
Les gens devraient écrire un logiciel tolérant aux plantages. En particulier sur les serveurs. Vous devez apprendre à concevoir un logiciel qui suppose que les choses vont se briser, planter, etc.
Il en va de même pour les logiciels de bureau. Lorsque je veux fermer mon navigateur, il faut généralement AGES pour le fermer. Il y a rien mon navigateur besoins pour ce faire, cela devrait prendre plus que quelques secondes au maximum. Quand je lui demande de fermer, il devrait réussir à le faire immédiatement. Quand ce n'est pas le cas, eh bien, nous retirons kill -9 et le faisons.
Non mentionné dans toutes les autres réponses est un cas où kill -9 Ne fonctionne pas du tout, quand un processus est <defunct> Et ne peut pas être tué:
Comment puis-je tuer un processus <defunct> dont le parent est init?
Qu'est-ce qui est défunt pour un processus et pourquoi il n'est pas tué?
Donc, avant d'essayer de kill -9 Un processus <defunct> Exécutez ps -ef Pour voir ce qu'est son parent et essayez le -15 (TERM) ou -2 (INT) et enfin -9 (KILL) sur son parent.
Remarque: ce que fait ps -ef .
Modification ultérieure et mise en garde: Procédez avec prudence lorsque vous tuez des processus, leurs parents ou leurs enfants, car ils peuvent laisser des fichiers ouverts ou corrompus, des connexions inachevées, peuvent corrompre bases de données, etc., sauf si vous savez ce que kill -9 fait pour un processus, utilisez-le uniquement en dernier recours, et si vous devez exécuter kill, utilisez les signaux spécifiés ci-dessus avant d'utiliser -9 (KILL)
Ne jamais faire un kill -9 1. Évitez également de tuer certains processus comme mount`. Quand je dois tuer beaucoup de processus (disons par exemple qu'une session X se bloque et que je dois tuer tous les processus d'un certain utilisateur), j'inverse l'ordre des processus. Par exemple:
ps -ef|remove all processes not matching a certain criteria| awk '{print $2}'|Ruby -e '$A=stdin.readlines; A.reverse.each{|a| puts "kill -9 #{a}"}'|bash
Gardez à l'esprit que kill n'arrête pas un processus et ne libère pas ses ressources. Tout ce qu'il fait, c'est envoyer un signal SIGKILL au processus; vous pourriez vous retrouver avec un processus qui est bloqué.
Tuer bon gré mal gré des processus n'est pas une chose facile: des données peuvent être perdues, des applications mal conçues peuvent se briser de manière subtile qui ne peut pas être corrigée sans réinstallation .. mais cela dépend complètement de savoir ce qui est et ce qui n'est pas sûr dans un situation donnée. et ce qui serait en danger. L'utilisateur doit avoir une idée de ce qu'un processus est ou devrait être en train de faire et de ses contraintes (IOPS disque, rss/swap) et être en mesure d'estimer combien de temps un processus de longue durée devrait prendre (disons une copie de fichier, réencodage mp3, migration des e-mails, sauvegarde, [votre horloge préférée ici].)
De plus, envoyer SIGKILL à un pid n'est pas une garantie de le tuer. S'il est bloqué dans un appel système ou déjà zombié (Z dans ps), il peut continuer à être zombié. C'est souvent le cas de ^ Z, un processus de longue haleine et d'oubli de bg avant d'essayer de kill -9 il. Un simple fg reconnectera stdin/stdout et débloquera probablement le processus, généralement suivi de la fin du processus. S'il est bloqué ailleurs ou dans une autre forme de blocage du noyau, seul un redémarrage peut supprimer le processus. (Les processus zombies sont déjà morts après que SIGKILL est traité par le noyau (aucun autre code utilisateur ne s'exécutera), il y a généralement une raison pour le noyau (similaire à être "bloqué" en attente d'un appel système pour se terminer) pour que le processus ne se terminant.)
De plus, si vous voulez tuer un processus et tous ses enfants, prenez l'habitude d'appeler kill avec le PID annulé, pas seulement le PID lui-même. Il n'y a aucune garantie que SIGHUP, SIGPIPE ou SIGINT ou d'autres signaux soient nettoyés après cela, et avoir un tas de processus désavoués à nettoyer (rappelez-vous bâtard?) Est ennuyeux.
Bonus mal: kill -9 -1 est légèrement plus dommageable que kill -9 1 (Ne faites pas non plus en tant que root, sauf si vous voulez voir ce qui se passe sur une machine virtuelle non importante à jeter)
J'ai créé un script qui aide à automatiser ce problème.
Il est basé sur ma réponse complète 2 dans une question très similaire à stackoverflow .
Vous pouvez y lire toutes les explications. Pour résumer, je recommanderais simplement SIGTERM et SIGKILL, ou même SIGTERM, SIGINT et SIGKILL. Cependant, je donne plus d'options dans la réponse complète.
N'hésitez pas à le télécharger (cloner) depuis le github référentiel à tuer avec gratitude1
Pourquoi vous ne voulez pas kill -9 un processus normalement
Selon man 7 signal:
Les signaux SIGKILL et SIGSTOP ne peuvent pas être capturés, bloqués ou ignorés.
Cela signifie que l'application qui reçoit l'un de ces signaux ne peut pas les "intercepter" pour effectuer un comportement d'arrêt.
Ce que vous devez faire avant d'exécuter kill -9 sur un processus
Vous devez vous assurer qu'avant d'envoyer le signal au processus que vous:
- Assurez-vous que le processus n'est pas occupé (c.-à-d. Faire du "travail"); envoi d'un
kill -9au processus entraînera essentiellement la perte de ces données. - Si le processus est une base de données non réactive, assurez-vous qu'il a d'abord vidé ses caches. Certaines bases de données prennent en charge l'envoi d'autres signaux au processus pour forcer le vidage de son cache.