ID de processus à l'aide de ps aux

9

Je suis un débutant dans la programmation de shell. En supposant que j'ai démarré un programme (par exemple NetBeans) à partir de mon terminal, si je tape

ps aux|grep netbeans

Je reçois la sortie

pre      18775  1.2  0.0  12524  1972 pts/3    S    20:17   0:00

où 18775 spécifie le PID, etc. du processus.

Ensuite, je le tue en utilisant

kill 18775.

sur lequel l'interface utilisateur NetBeans disparaît. Si j'essaye d'obtenir le pid en utilisant la première commande, j'obtiens toujours:

pre      19137  0.0  0.0   9136  1068 pts/3    S+   20:19   0:00 grep --color=auto netbeans

Si le processus a été interrompu, pourquoi affiche-t-il toujours la sortie ci-dessus?

command-line

— P Ramesh
source

1

Il ne vous montre pas le processus netbeans - il montre le processus grep par lequel ps aux est acheminé! Puisque ce processus est grep netbeans, c'est le programme que vous voyez à la fin de la ligne ( grep --color=auto netbeans)

— David Puglielli

15

grep se salue. Essayez quelque chose comme:

ps aux |grep [n]etbeans

cela empêche grep de se montrer dans la sortie

— roadmr
source

2

Cela fonctionne, mais ce n'est pas très agréable. Vous pourriez aussi le faire ps aux | grep netbeans | grep -v grep. Mais utilisez pgrep à la place.

— Martin Ueding

1

@queueoverflow pgrepserait bien, mais il ne correspond qu'au nom du processus. Le premier motif peut correspondre à n'importe quelle colonne de ps. (Par exemple, quelque chose fonctionnant sous python ou java, pgrep ne saluerait pas la bonne chose. Même chose avec pkillet ainsi de suite ..)

— Izkata

5

Ne jamais utiliser psavec grep.

Au contraire, utiliser killall netbeans, pkill netbeanspour le tuer. Pour l'ID de processus pgrep netbeans.

Plus sur ps et grep .

— Martin Ueding
source

5

C'est le conseil le plus inutile que j'aie jamais entendu. Tant que les gens savent à quoi ressemblera le processus grep dans la sortie de ps (il commence par "grep"), il n'y a absolument aucun danger à utiliser les deux ensemble. Je comprends les conseils de ne pas utiliser un kill dans un script, mais c'est à côté du point.

— ovangle

3

Et je pense que pgrep est pire, parce que cela vous supplie simplement de 'tuer $ (pgrep vi *)' ou quelque chose d'incroyablement dangereux comme ça.

— ovangle

1

C'est aussi la réponse la plus inutile sur cette page, comme pgrep, pkillet ainsi de suite le nom du processus de correspondance uniquement - quoi que ce soit interprété (java, python, bash, etc ...) ne peut être distingué des autres sous le même nom de processus en utilisant ps.

— Izkata

3

@Izkata - l'utilisation de -f pour pgrep et pkill correspondra à toute la ligne de commande. C'est parfois utile lorsque vous essayez de faire correspondre des choses exécutées sous des interprètes comme vous le mentionnez. C'est aussi un bon moyen de se tirer une balle dans le pied car il tuera avec plaisir tout ce qui fait référence à votre modèle n'importe où dans sa ligne de commande :)

— roadmr

4

Parce que c'est le PID du processus grep qui est mis en file d'attente pour s'exécuter ensuite ps aux.

— ovangle
source

@ ovangle- clignotement Je n'y ai jamais pensé! : D merci!

— P Ramesh

1

En fait, grepest déjà en cours d'exécution lors de l' ps auxexécution. Lors de l' ps auxexécution, sa sortie est envoyée à l' grepinstance en cours d'exécution en tant qu'entrée. Si le shell n'avait pas grepencore été exécuté , il n'apparaîtrait pas dans la sortie de ps.

— Eliah Kagan