Risposte:
ps auxinclude l'intera riga di comando (percorso e parametri), mentre pgrep guarda solo i primi 15 caratteri dei nomi dell'eseguibileps auxrestituisce la riga di comando completa di ogni processo, mentre pgrepesamina solo i nomi degli eseguibili.
Ciò significa che l' ps aux output grepping corrisponderà a tutto ciò che si verifica nel percorso o nei parametri di un processo "binario: ad esempio"
ps aux | grep php5 corrisponderà /usr/share/php5/i-am-a-perl-script.plpgrep php5non lo faràPrendi un esempio dal mio sistema - solo noi useremo python invece di php5:
ps aux | grep python ci da: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 radice 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 giu24 1:16 / usr / bin / python / usr / bin / update-manager --no-focus-on-map radice 11729 0,0 0,9 180508 19516? S Jun25 0:00 python / usr / lib / software-properties / software-properties-dbus
pgrep pythonrestituisce solo 11729, che vedrai dall'elenco sopra è:radice 11729 0,0 0,9 180508 19516? S Jun25 0:00 python / usr / lib / software-properties / software-properties-dbus
/proc/<pid>/statma non da/proc/<pid>/cmdline . OK, @Thorsen, si vince lo spray, si tratta di un bug: P
pgrepnon è un comando irragionevole. Funziona bene e come progettato. Il problema è semplicemente che ti mancava un'opzione quando la esegui, non puoi incolparla pgrep. L'uso ps aux | grep xxxè inaffidabile, quindi è necessario hack per filtrare grepse stesso dall'output e potrebbe dare falsi positivi come con ps aux | grep root.
Il ps aux | grep xcomando fornisce risultati "migliori" rispetto pgrep xessenzialmente perché manca un'opzione con quest'ultimo.
Basta usare l' -fopzione per pgrepcercare l'intera riga di comando e non solo il nome del processo che è il suo comportamento predefinito, ad esempio:
pgrep -f php5A differenza della ps | grepcostruzione con cui è necessario filtrare la greplinea o utilizzare trucchi con motivi, pgrepsemplicemente non si sceglierà dal punto di vista del design.
Inoltre, se il tuo modello appare nella ps USERcolonna, otterrai processi indesiderati nell'output, pgrepnon soffre di questo difetto.
Se desideri dettagli completi anziché solo i pid, puoi utilizzare:
ps wup $(pgrep -f python)che è più semplice e più affidabile di
ps aux | grep python | grep -v grepo
ps aux | grep p[y]thon-a( --list-full) se vuoi vedere l'intera riga di comando e non solo il pid. (I precedenti pgrep no -a, lo facevano-fl .)
pgrepdi giocare bene la soluzione. +1
/proc/self/cmdlineper essere "descrittivi", pgrep -fa rubynon corrisponderanno ad es. puma 3.3.0 (tcp://localhost:3000) [MIQ: Web Server Worker], mentre il "più scemo" lo pgrep -a rubyfarà. Non sono sicuro che anche quest'ultimo possa essere ingannato.
pgrepe ps.
diff <(ps aux|grep x) <(pgrep x) # :)In questo momento, psfornirà un output più completo di pgep -fquanto pgrep sia limitato ai primi 4.096 caratteri (spesso interessano gli utenti Java che cercano la classe di ingresso di un programma Java con un percorso di classe lungo). Il bug tracking è questo: https://gitlab.com/procps-ng/procps/issues/86