Comment puis-je terminer tous les processus avec le même nom d'une manière plus douce que le killall
fait? Je ne veux pas interrompre les processus, mais laissez-leur le temps de quitter correctement.
Voir également:
Comment tuer les processus dans Ubuntu?
Dans System Monitor, quelle est la différence entre Kill Process et End Process?
command-line
process
kill
killall
noisette sur natty
la source
la source
Réponses:
1. `killall` déjà sympa (SIGTERM)
killall
envoie par défautSIGTERM
. C'est déjà la bonne approche qui laisse aux applications la possibilité de se nettoyer après elles-mêmes. Le "allez mourir déjà, maintenant!" L'approche consiste à envoyer unSIGKILL
signal, ce qui nécessite de le spécifier en optionkillall
. De la bibliothèque GNU C: Signaux de terminaison :2. Le "processus de fin" de System Monitor est tout aussi agréable (SIGTERM aussi)
Vous créez un lien vers une question sur GNOME System Monitor. Cela vaut également
SIGTERM
pour son action "Fin du processus" (et je me rends compte que je contredit la réponse à cette question). Vous pouvez le trouver dans le code source pour vous vérifier:data / menus.ui :
Le 15 ici est le numéro du signal. Le signal 15 est
SIGTERM
. Et System Monitor a utiliséSIGTERM
bien avant cette autre question a été posée et répondue.Addendum technique (en réponse à un commentaire)
En regardant à travers la représentation Github de
git blame
, voici les changements qui ont été apportés à la façon dont les signaux sont énoncés dans le code source de GNOME System Monitor:383007f2 24 juil. 2013 Code dupliqué remplacé pour l'envoi de signaux avec les paramètres
GAction 0e766b2d 18 juil. 2013 Menu contextuel du processus de port vers GAction
97674c79 3 oct. 2012 Supprimez la structure
ProcData 38c5296c 3 juil. 2011 Uniformisez l' indentation entre les fichiers source.
Aucun de ces éléments n'est passé de
SIGQUIT
àSIGTERM
, et ce dernier date d'avant la question liée.la source
15
? Il a peut-être été modifié à un moment donné, de sorte que l'ancienne réponse pourrait être correcte à 100% par rapport à une ancienne version.git grep 'SIGQUIT'
ne révèle rien. Aucun élément lié aux signaux n'est trouvégit grep '>3<'
non plus. Je conclus que le gnome-system-monitor n'a probablement jamais été utiliséSIGQUIT
.git grep
ne recherche que l'arborescence actuelle, pas toute l'histoire. J'ai utiliségit blame
(en fait l'équivalent de Github) pour creuser un peu plus profondément, mais toujours rien.La réponse de @hvd est fondamentalement correcte. Pour sauvegarder cela encore plus, le
init
processus sera d'abord envoyéSIGTERM
aux processus lorsque vous éteignez votre ordinateur, puis après un délai sera envoyéSIGKILL
s'ils ne sont pas déjà sortis. Les processus ne peuvent pas gérer / ignorerSIGKILL
.Pour donner un peu plus de détails, la vraie réponse est que vous n'avez aucun moyen de savoir avec certitude que le programme le gère.
SIGTERM
est le signal le plus courant à utiliser pour demander poliment à un programme de quitter, mais tout traitement du signal dépend du programme qui fait quelque chose avec le signal.Pour le dire différemment, sur la base des autres réponses, si vous aviez un programme écrit par @Jos ou par @AlexGreg, ils seraient probablement en train de gérer
SIGQUIT
mais peut-être pasSIGTERM
, et donc l'envoiSIGTERM
serait moins "doux" queSIGQUIT
.J'ai écrit du code pour que vous puissiez jouer avec lui-même. Enregistrez ci-dessous sous
signal-test.c
, puis compilez avecVous pouvez ensuite l'exécuter
./signal-test
et voir ce qui se passe lorsque vous envoyez différents signaux aveckillall -s <signal>
.En l'état, le code gère à la fois SIGTERM et SIGQUIT avec élégance. Vous pouvez essayer de commenter les lignes
signal(SIG...
(en utilisant un//
au début de la ligne) pour supprimer le gestionnaire de signal, puis exécuter et envoyer à nouveau les signaux. Vous devriez pouvoir voir ces différentes sorties:selon que vous gérez ou non les signaux.
Vous pouvez également essayer d'ignorer les signaux:
Si vous faites cela, l'envoi
SIGTERM
ne fera rien, vous devrez utiliserSIGKILL
pour mettre fin au processus.Plus de détails dans
man 7 signal
. Notez que l'utilisationsignal()
de cette manière est considérée comme non portable - c'est beaucoup plus facile que l'alternative!Une autre note de bas de page mineure - sur Solaris
killall
tente de tuer tous les processus. Tous. Si vous l'exécutez en tant que root, vous pourriez être surpris :)la source
pkill
. L'autre raison est qu'il s'associe avecpgrep
, ce qui facilite la vérification exacte des processus qui seront tués et celui qui a lui-même une meilleure sémantique de correspondance queps | grep
."Tout mettre fin" serait
killall -s SIGQUIT [process name]
. Si vous voulez une solution sophistiquée, définissezalias endall='killall -s SIGQUIT'
.la source
SIGQUIT
c'est comme faire le processusabort(3)
: il vide le noyau puis tue le processus. Ce n'est en aucun cas plus agréable / plus doux / plus gentil queSIGTERM
celui par défautkillall
.SIGQUIT
(ou même mieuxSIGINT
), il pourrait être traité plus «doucement» queSIGTERM
, mais cela dépend de l'application. Non gérés, l'un d'eux entraîne une résiliation immédiate.