Je veux tuer les process suivants en utilisant
pkill "run_tcp_sender.sh"
ou
pkill -SIGKILL "run_tcp_sender.sh" root 14320 1 0 2012 ? 00:00:00 bash run_tcp_sender.sh 138.96.116.22 root 14323 1 0 2012 ? 00:00:00 bash run_tcp_sender.sh 138.96.116.22 root 14325 1 0 2012 ? 00:00:00 bash run_tcp_sender.sh 138.96.116.22 root 14327 1 0 2012 ? 00:00:00 bash run_tcp_sender.sh 138.96.116.22 root 14328 1 0 2012 ? 00:00:00 bash run_tcp_sender.sh 138.96.116.22 root 14330 1 0 2012 ? 00:00:00 bash run_tcp_sender.sh 138.96.116.22
mais il est inutile que les process restnt là ce qui ne va pas avec ma command?
BTW: Je peux utiliser la command suivante pour réaliser ce que je veux
kill -9 $(ps -ef|grep "run_tcp"|grep -v "grep"|awk '{print $2}')
pkill
envoie par défaut le signal SIGTERM
aux process pour l'arrêter. Voici une list des signaux que vous pouvez envoyer un process. Vous pouvez les envoyer par nom ou par numéro typiquement:
$ kill -l 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM 16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR 31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3 38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8 43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13 48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7 58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2 63) SIGRTMAX-1 64) SIGRTMAX
Donc, vous envoyez le signal # 15. Si les process ne répondent pas à ce signal, vous devrez peut-être utiliser le signal # 9, pkill -SIGKILL
.
De la page de manuel de pkill :
-signal
Defines the signal to send to each matched process. Either the numeric or the symbolic signal name can be used. (pkill only.)
Le PO a mentionné qu'il n'avait pas réussi à faire fonctionner pkill -SIGKILL "run_tcp"
. Au départ, nous pensions que le problème était pkill
au fait que pkill
tuait potentiellement avant d'avoir fini de tuer tous les process "run_tcp".
Mais c'était difficile à accepter étant donné une note de pied dans la page man pkill
:
Le process pgrep ou pkill en cours ne se rapportera jamais comme une correspondance.
En plus de cela, @Gilles a laissé un commentaire disant essentiellement la même chose, que pkill
ne se tue pas tout seul. Puis il nous a donné une idée assez précise de ce qui se passait réellement.
Voici un exemple qui démontre ce que l'OP et moi-même avons manqué:
étape 1 – créer un script sleepy.bash
#!/bin/bash sleep 10000
étape 2 – charger quelques fausses tâches de sumil
$ for i in `seq 1 5`;do bash sleepy.bash & done [1] 12703 [2] 12704 [3] 12705 [4] 12706 [5] 12707
étape 3 – vérifier les tâches en cours d'exécution
$ ps -eaf|egrep "sleep 10000|sleepy" saml 12703 29636 0 21:48 pts/16 00:00:00 bash sleepy.bash saml 12704 29636 0 21:48 pts/16 00:00:00 bash sleepy.bash saml 12705 29636 0 21:48 pts/16 00:00:00 bash sleepy.bash saml 12706 29636 0 21:48 pts/16 00:00:00 bash sleepy.bash saml 12707 29636 0 21:48 pts/16 00:00:00 bash sleepy.bash saml 12708 12704 0 21:48 pts/16 00:00:00 sleep 10000 saml 12709 12707 0 21:48 pts/16 00:00:00 sleep 10000 saml 12710 12705 0 21:48 pts/16 00:00:00 sleep 10000 saml 12711 12703 0 21:48 pts/16 00:00:00 sleep 10000 saml 12712 12706 0 21:48 pts/16 00:00:00 sleep 10000
étape 4 – essayez d'utiliser mon pkill
$ pkill -SIGTERM sleepy.bash
étape 5 – qu'est-ce qui s'est passé?
En exécutant la command ps
ci-dessus, nous voyons qu'aucun des process n'a été tué, tout comme le problème OPs. Que se passe-t-il?
Il s'avère que c'est un problème dans la façon dont nous tentions d'utiliser pkill
. La command:
pkill -SIGTERM "sleepy.bash"
était à la search d'un process sous le nom de "sleepy.bash" . Eh bien, il n'y a pas de process de ce nom. Il y a des process qui sont nommés "bash sleepy.bash" cependant. Donc pkill
cherchait des process pour tuer et ne pas en find, puis en sortir.
Donc, si nous ajustons légèrement le pkill
que nous utilisons à ceci:
$ pkill -SIGTERM -f "sleepy.bash" [1] Terminated bash sleepy.bash [2] Terminated bash sleepy.bash [3] Terminated bash sleepy.bash [4]- Terminated bash sleepy.bash [5]+ Terminated bash sleepy.bash
Maintenant, nous obtenons l'effet que nous recherchions. Quelle est la différence? Nous avons utilisé le paramètre -f
pour pkill
ce qui fait que pkill
utilise tout le path de la command line lors de la comparaison par rapport au nom du process.
de la page man de pkill
-f The pattern is normally only matched against the process name. When -f is set, the full command line is used.
tuer, ps
Cette méthode est assez verbeuse mais fait le travail aussi:
kill -9 $(ps -ef|grep "run_tcp"|grep -v "grep"|awk '{print $2}')
pgrep w / pkill & killall
Vous pouvez utiliser pgrep
pour alimenter une list de PID à pkill
ou utiliser killall
place.
# pgrep solution $ pgrep "run_tcp" | pkill -SIGKILL # killall killall -SIGKILL -r run_tcp
Ceci n'est pas lié à l'ID du process parent. Le problème est simplement que vous tuez tous les process exécutant run_tcp_sender.sh
, mais vous n'avez pas de tels process – les process qui vous intéressent exécutent bash
.
Vous pouvez requestr à pkill
faire correspondre sur toute la command line:
pkill -f '^bash run_tcp_sender.sh'
Une autre approche serait de tuer tous les process qui ont le script ouvert. Cela pourrait causer des dommages collatéraux, par exemple à un éditeur qui venait d'ouvrir le script.
fuser -k /path/to/run_tcp_sender.sh
Tant que vous n'éditez pas le script en tant que root, tuer uniquement les process de root résoudrait ce problème:
kill $(lsof -uroot /path/to/run_tcp_sender.sh)
Essayez de tuer le process avec "signal 9", je veux dire l'utilisation
kill -9 PID
normalement le signal 9 n'est pas recommandé pour tuer le moteur de bases de données
si le process rest en memory, certains E / S sont perdus ou le process attend la fin de l'E / S