Pourquoi “ps aux | grep x "donne de meilleurs résultats que" pgrep x "?

82

Je viens d'essayer la commande suivante sur mon Ubuntu, cela ne montre rien:

pgrep php5

ne devrait-il pas renvoyer l'ID de processus de php5 (que la commande suivante ne fait que)?

ps aux | grep php5

Alors, quelle est la différence entre ces deux commandes?

command-line bash text

— xczzhh
source

75

`ps aux`inclut la ligne de commande complète (chemin et paramètres), tandis que pgrep ne regarde que les 15 premiers caractères du nom de l'exécutable

ps auxrenvoie la ligne de commande complète de chaque processus, alors que pgrepne regarde que les noms des exécutables.

Cela signifie que la sortie de greps ps aux correspondra à tout ce qui se produit dans le chemin ou dans les paramètres d'un processus 'binaire: par exemple `

ps aux | grep php5 correspondra /usr/share/php5/i-am-a-perl-script.pl
mais pgrep php5pas

Prenons un exemple de mon système - seulement nous allons utiliser python à la place de php5:

ps aux | grep python nous donne:

izx 2348 0,0 0,7 514928 15644? Sl Jun24 0:00 / usr / bin / python / usr / lib / unité-objectif-vidéo / unité-objectif-vidéo
izx 2444 0,0 0,9 547392 18864? Sl Jun24 0:01 / usr / bin / python / usr / lib / unity-scope-video-remote / unity-scope-video-remote
racine 2805 0,0 0,5 95436 12204? S juin24 0:00 / usr / bin / python / usr / lib / service-système / système-service-d
izx 6272 0,0 2,9 664400 60320? SNl Jun24 1:16 / usr / bin / python / usr / bin / update-manager --no-focus-on-map
racine 11729 0,0 0,9 180508 19516? Juin 25 0:00 python / usr / lib / logiciels-propriétés / logiciels-propriétés-dbus

Mais pgrep pythonrenvoie uniquement 11729, ce que vous verrez dans la liste ci-dessus est:

racine 11729 0,0 0,9 180508 19516? Juin 25 0:00 python / usr / lib / logiciels-propriétés / logiciels-propriétés-dbus

— ish
source

3

"pgrep -l" tronque également le processus à 15 caractères, ce qui est probablement un bogue mais en est ainsi depuis des lustres

— Thorsen le

1

C'est dans le tableau de bord en tant que bogue amont à compter de 2008 :) "commande top et ps truncate après 15 caractères" bugs.launchpad.net/ubuntu/+source/procps/+bug/295876

— Thorsen

2

Hah, cela l'explique, à partir du commentaire n ° 3: Cela est dû au fait que certaines procédures de procs obtiennent le nom de la commande /proc/<pid>/statmais pas à partir/proc/<pid>/cmdline . OK, @Thorsen, vous gagnez le bogue, c'est un bogue: P

— ish

2

@xczzhh pgrepn'est pas une commande déraisonnable. Cela fonctionne bien et comme prévu. Le problème est simplement qu'il vous manquait une option lorsque vous l'exécutez, vous ne pouvez pas en vouloir pgrepà cela. L'utilisation ps aux | grep xxxn'est pas fiable, il est donc nécessaire que des outils informatiques se filtrent grepde la sortie et risquent de donner des faux positifs comme avec ps aux | grep root.

— jeudi

1

Cela devrait être dans une publicité anti-drogue, les créateurs d'outils bash étaient tellement impressionnés par le LSD qu'ils pensaient que ce genre de choses était bien conçu

— Andy Ray

78

La ps aux | grep xcommande donne de "meilleurs" résultats pgrep xqu'essentiellement car il vous manque une option avec cette dernière.

Utilisez simplement l’ -foption pour pgreprechercher dans la ligne de commande complète et pas uniquement dans le nom du processus qui est son comportement par défaut, par exemple:

pgrep -f php5

Contrairement à la ps | grepconstruction avec laquelle vous devez filtrer la grepligne ou utiliser des tours de modèle, vous pgrepne vous choisissez pas tout seul.

De plus, si votre modèle apparaît dans la ps USERcolonne, vous obtiendrez des processus indésirables dans la sortie, pgrepsans souffrir de cette faille.

Si vous voulez des détails complets au lieu des pids, vous pouvez utiliser:

ps wup $(pgrep -f python)

qui est plus simple et plus fiable que

ps aux | grep python | grep -v grep

ou

ps aux | grep p[y]thon

— jlliagre
source

3

Ajoutez également l' option -a( --list-full) si vous voulez voir la ligne de commande complète et pas seulement le pid. (Plus ancien pgrep n'avait pas -a, a fait cela-fl .)

— Beni Cherniavsky-Paskin

1

La question initiale concernait la différence, mais cela donne en fait à ceux d'entre nous qui essaient pgrepde jouer la bonne solution. +1

— 2rs2ts

@ 2rs2ts Merci, il me manquait effectivement de répondre à la question posée. Correction maintenant.

— jlliagre

Dans certains cas, lorsque les programmes se modifient /proc/self/cmdlinepour être "descriptifs", pgrep -fa rubyils ne correspondent pas, par exemple. puma 3.3.0 (tcp://localhost:3000) [MIQ: Web Server Worker]tandis que le "bête" le pgrep -a rubyfera. Je ne sais pas si ce dernier peut être dupe aussi.

— Beni Cherniavsky-Paskin

@ BeniCherniavsky-Paskin je suppose que cela aurait pu être un commentaire à la question, car il applique à la fois pgrepet ps.

— Franklin Yu

3

diff <(ps aux|grep x) <(pgrep x) # :)

— Thorsen
source

12

Cela peut répondre à la question, mais vous pouvez peut-être développer votre réponse pour expliquer le rôle de cette commande sur une ligne.

— fossfreedom

1

À ce stade , psdonnera une sortie plus complète que pgep -fpgrep est limité aux 4 096 caractères (affectant souvent les utilisateurs Java à la recherche de la classe d’entrée d’un programme Java avec un long chemin de classes). Le suivi des bogues est le suivant: https://gitlab.com/procps-ng/procps/issues/86

— Clay B.
source

Cherché pour toujours.

— Tresf

Pourquoi “ps aux | grep x "donne de meilleurs résultats que" pgrep x "?

ps auxinclut la ligne de commande complète (chemin et paramètres), tandis que pgrep ne regarde que les 15 premiers caractères du nom de l'exécutable

`ps aux`inclut la ligne de commande complète (chemin et paramètres), tandis que pgrep ne regarde que les 15 premiers caractères du nom de l'exécutable