Mengapa “ps aux | grep x "memberikan hasil yang lebih baik daripada" pgrep x "?

82

Saya baru saja mencoba perintah berikut di Ubuntu saya, itu tidak menunjukkan apa-apa:

pgrep php5

bukankah seharusnya mengembalikan proses id dari php5 (yang hanya dilakukan perintah berikut) ?:

ps aux | grep php5

Jadi, apa perbedaan antara kedua perintah ini?

command-line bash text

— xczzhh
sumber

75

`ps aux`termasuk baris perintah penuh (jalur dan parameter), sementara pgrep hanya melihat 15 karakter pertama dari nama yang dapat dieksekusi

ps auxmengembalikan baris perintah penuh dari setiap proses, sementara pgrephanya melihat nama-nama yang dapat dieksekusi.

Itu berarti bahwa output grepping ps aux akan cocok dengan apa pun yang terjadi di path atau parameter dari proses 'binary: eg `

ps aux | grep php5 akan cocok /usr/share/php5/i-am-a-perl-script.pl
tetapi pgrep php5tidak akan

Ambil contoh dari sistem saya - hanya kami yang akan menggunakan python alih-alih php5:

ps aux | grep python memberi kita:

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
root 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 --tidak ada fokus-di-peta
root 11729 0,0 0,9 180508 19516? S Jun25 0:00 python / usr / lib / software-properties / software-properties-dbus

Tetapi pgrep pythonhanya pengembalian 11729, yang akan Anda lihat dari daftar di atas adalah:

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

— ish
sumber

3

"pgrep -l" juga memotong proses menjadi 15 karakter, yang mungkin merupakan bug tetapi sudah seperti ini sejak lama

— Thorsen

1

Baik itu di launchpad sebagai bug hulu pada tahun 2008 :) "perintah top dan ps truncate after 15 chars" bugs.launchpad.net/ubuntu/+source/procps/+bug/295876

— Thorsen

2

Hah, ini menjelaskannya, dari komentar # 3: Ini disebabkan oleh fakta bahwa beberapa prosedur procs mendapatkan nama perintah dari /proc/<pid>/stattetapi bukan dari/proc/<pid>/cmdline . OK, @Tenlen, Anda memenangkan semprotan bug, ini bug: P

— ish

2

@xczzhh pgrepbukan perintah yang tidak masuk akal. Ini bekerja dengan baik dan dirancang. Masalahnya hanyalah Anda tidak memiliki opsi saat menjalankannya, Anda tidak dapat disalahkan pgrepuntuk itu. Menggunakan ps aux | grep xxxtidak dapat diandalkan sehingga perlu retas untuk memfilter grepsendiri dari output dan mungkin memberikan hasil positif yang salah ps aux | grep root.

— jlliagre

1

Ini harus dalam iklan anti-narkoba, pencipta alat bash begitu bersemangat pada LSD mereka pikir hal-hal seperti ini dirancang dengan baik

— Andy Ray

78

The ps aux | grep xperintah memberikan "lebih baik" hasil dari pgrep xdasarnya karena Anda hilang pilihan dengan yang terakhir.

Cukup gunakan -fopsi untuk pgrepmencari baris perintah penuh dan tidak hanya nama proses yang merupakan perilaku default-nya, misalnya:

pgrep -f php5

Berbeda dengan ps | grepkonstruksi yang Anda butuhkan untuk menyaring grepgaris atau menggunakan trik pola, pgreptidak akan memilih sendiri dengan desain.

Selain itu, jika pola Anda muncul di ps USERkolom, Anda akan mendapatkan proses yang tidak diinginkan dalam output, pgreptidak menderita cacat ini.

Jika Anda menginginkan detail lengkap alih-alih hanya pids, Anda dapat menggunakan:

ps wup $(pgrep -f python)

yang lebih sederhana dan lebih dapat diandalkan daripada

ps aux | grep python | grep -v grep

atau

ps aux | grep p[y]thon

— Jlliagre
sumber

3

Juga tambahkan opsi -a( --list-full) jika Anda ingin melihat baris perintah penuh dan bukan hanya pid. (Pgrep yang lebih tua tidak punya -a, lakukan ini-fl .)

— Beni Cherniavsky-Paskin

1

Pertanyaan aslinya adalah menanyakan perbedaannya tetapi ini sebenarnya memberi kita kesempatan untuk mencoba pgrepbermain solusinya. +1

— 2rs2ts

@ 2rs2ts Terima kasih, saya memang tidak ada untuk menjawab pertanyaan yang diajukan. Diperbaiki sekarang

— jlliagre

Dalam beberapa kasus ketika program dimodifikasi /proc/self/cmdlinemenjadi "deskriptif", pgrep -fa rubytidak akan cocok misalnya. puma 3.3.0 (tcp://localhost:3000) [MIQ: Web Server Worker], sedangkan "dumber" pgrep -a rubyakan. Tidak yakin apakah yang terakhir mungkin tertipu juga.

— Beni Cherniavsky-Paskin

@ BeniCherniavsky-Paskin Saya kira itu bisa menjadi komentar untuk pertanyaan, karena itu berlaku untuk keduanya pgrepdan ps.

— Franklin Yu

3

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

— Thorsen
sumber

12

Ini mungkin menjawab jawaban pertanyaan - tetapi mungkin Anda dapat memperluas jawaban Anda untuk menjelaskan apa yang dilakukan perintah satu baris ini.

— fossfreedom

1

Pada saat ini, psakan memberikan hasil yang lebih lengkap daripada pgep -fpgrep terbatas pada 4.096 karakter pertama (sering mempengaruhi pengguna Java yang mencari kelas entri dari program Java dengan classpath yang panjang). Pelacakan bug ini adalah: https://gitlab.com/procps-ng/procps/issues/86

— Clay B.
sumber

Mencari selamanya untuk ini.

— tresf

Mengapa “ps aux | grep x "memberikan hasil yang lebih baik daripada" pgrep x "?

ps auxtermasuk baris perintah penuh (jalur dan parameter), sementara pgrep hanya melihat 15 karakter pertama dari nama yang dapat dieksekusi

`ps aux`termasuk baris perintah penuh (jalur dan parameter), sementara pgrep hanya melihat 15 karakter pertama dari nama yang dapat dieksekusi