pkill ne peut pas tuer les process avec l'ID de process parent 1

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.) 

Problèmes avec pkill

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. 

Méthodes alternatives

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.

Exemples

 # pgrep solution $ pgrep "run_tcp" | pkill -SIGKILL # killall killall -SIGKILL -r run_tcp 

Les references

  • page de manuel pgrep
  • page man pkill
  • killall page man

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