Por que "ps aux | grep x ”dá melhores resultados que“ pgrep x ”?

82

Eu apenas tentei o seguinte comando no meu Ubuntu, ele não mostra nada:

pgrep php5

não deveria retornar a identificação do processo do php5 (que o comando a seguir apenas faz) ?:

ps aux | grep php5

Então, qual é a diferença entre esses dois comandos?

command-line bash text

— xczzhh
fonte

75

`ps aux`inclui a linha de comando completa (caminho e parâmetros), enquanto o pgrep olha apenas os 15 primeiros caracteres dos nomes dos executáveis

ps auxretorna a linha de comando completa de cada processo, enquanto pgrepolha apenas os nomes dos executáveis.

Isso significa que a saída grepping ps aux corresponderá a qualquer coisa que ocorra no caminho ou nos parâmetros do binário de um processo: por exemplo, `

ps aux | grep php5 vai combinar /usr/share/php5/i-am-a-perl-script.pl
mas pgrep php5não

Tomemos um exemplo do meu sistema - somente usaremos python em vez de php5:

ps aux | grep python nos dá:

izx 2348 0,0 0,7 514928 15644? Sl Jun24 0:00 / usr / bin / python / usr / lib / unity-lens-video / unity-lens-video
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
raiz 2805 0,0 0,5 95436 12204? S Jun24 0:00 / usr / bin / python / usr / lib / system-service / system-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
raiz 11729 0,0 0,9 180508 19516? S Jun25 0:00 python / usr / lib / software-properties / software-properties-dbus

Mas pgrep pythonretorna apenas 11729, que você verá na lista acima é:

raiz 11729 0,0 0,9 180508 19516? S Jun25 0:00 python / usr / lib / software-properties / software-properties-dbus

— ish
fonte

3

"pgrep -l" também trunca o processo de 15 caracteres, o que provavelmente é um bug, mas tem sido assim por muito tempo

— Thorsen

1

Bem, é na barra de lançamento como um bug a montante a partir de 2008 :) "comando superior e truncar ps depois de 15 caracteres" bugs.launchpad.net/ubuntu/+source/procps/+bug/295876

— Thorsen

2

Hah, isso explica, a partir do comentário 3: Isso se deve ao fato de que alguns procedimentos de procs obtêm o nome do comando, /proc/<pid>/statmas não de/proc/<pid>/cmdline . OK, @Thorsen, você ganha o repelente de insetos, é um inseto: P

— ish

2

@xczzhh pgrepnão é um comando irracional. Funciona bem e como projetado. O problema é simplesmente você estava perdendo uma opção quando a executava, não pode ser responsabilizado pgreppor isso. O uso ps aux | grep xxxnão é confiável, portanto, é necessário que os hacks se filtrem grepda saída e possam fornecer falsos positivos, como com ps aux | grep root.

— Jlliagre

1

Esta deve ser em um anti-droga comercial, os criadores de ferramentas festança foram tão brilhou no LSD eles pensavam coisas como esta foram bem projetados

— Andy Ray

78

O ps aux | grep xcomando fornece resultados "melhores" do que pgrep xessencialmente porque você está perdendo uma opção com o último.

Basta usar a -fopção para pgreppesquisar a linha de comando completa e não apenas o nome do processo, que é o comportamento padrão, por exemplo:

pgrep -f php5

Ao contrário da ps | grepconstrução com a qual você precisa filtrar a greplinha ou usar truques de padrão, pgrepsimplesmente não se escolhe por design.

Além disso, se seu padrão aparecer na ps USERcoluna, você obterá processos indesejados na saída, pgrepnão sofrerá com essa falha.

Se você quiser detalhes completos em vez de apenas os pids, pode usar:

ps wup $(pgrep -f python)

que é mais simples e mais confiável do que

ps aux | grep python | grep -v grep

ou

ps aux | grep p[y]thon

— jlliagre
fonte

3

Adicione também a opção -a( --list-full) se quiser ver a linha de comando completa e não apenas o pid. (Pgrep Older não tinha -a, fiz isso em-fl .)

— Beni Cherniavsky-Paskin

1

A pergunta original estava perguntando sobre a diferença, mas isso realmente dá a nós aqueles que tentamos pgrepjogar bem a solução. 1

— 2rs2ts

@ 2rs2ts Obrigado, estava realmente faltando responder à pergunta. Corrigido agora.

— jlliagre

Em alguns casos, quando os programas modificam /proc/self/cmdlinepara serem "descritivos", pgrep -fa rubynão coincidem, por exemplo. puma 3.3.0 (tcp://localhost:3000) [MIQ: Web Server Worker], enquanto o "mais burro" pgrep -a rubyserá. Não tenho certeza se o último também pode ser enganado.

— Beni Cherniavsky-Paskin

@ BeniCherniavsky-Paskin Acho que poderia ter sido um comentário para a pergunta, uma vez que se aplica a ambos pgrepe ps.

— Franklin Yu

3

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

— Thorsen
fonte

12

Isso pode responder à resposta da pergunta - mas talvez você possa expandir sua resposta para explicar o que esse comando de uma linha faz.

— fossfreedom

1

No momento, psele fornecerá uma saída mais completa do pgep -fque o pgrep limitado aos 4.096 caracteres (geralmente afetando os usuários Java que procuram a classe de entrada de um programa Java com um longo caminho de classe). O bug que rastreia isso é: https://gitlab.com/procps-ng/procps/issues/86

— Clay B.
fonte

Olhou para sempre por isso.

— tresf 9/10

Por que "ps aux | grep x ”dá melhores resultados que“ pgrep x ”?

ps auxinclui a linha de comando completa (caminho e parâmetros), enquanto o pgrep olha apenas os 15 primeiros caracteres dos nomes dos executáveis

`ps aux`inclui a linha de comando completa (caminho e parâmetros), enquanto o pgrep olha apenas os 15 primeiros caracteres dos nomes dos executáveis