Qual è la differenza tra "killall" e "pkill"?


92

Dopo aver usato semplicemente kill <some_pid>su sistemi Unix per molti anni, ho imparato pkillda un giovane esperto di Linux collaboratore collega 1 .

Presto ho accettato la strada di Linux, pgrep-ing e pkill-ing per molti giorni e notti, attraverso rallentamenti e condizioni di gara. Questo è andato tutto bene.

Ma ora non vedo altro che killall. Le istruzioni sembrano solo menzionare killall, e non sono sicuro se si tratti di una sorta di sviluppo parallelo, se killallè un successore pkillo qualcos'altro.

Sembra funzionare come un obiettivo più mirato pkill, ma sono sicuro che mi manca qualcosa.

Può una persona esperta di Ubuntu / Debian 2 spiegare quando (o perché) killalldovrebbe essere usato, specialmente se dovrebbe essere usato in preferenza pkill(quando pkillspesso sembra più facile, perché posso essere più sciatto con la corrispondenza dei nomi, almeno per impostazione predefinita).

Quando parlo di killall, non sto pensando al comando che su alcuni sistemi Unix (Solaris, AIX,?) Ucciderebbe tutti i processi dell'utente. Ecco una descrizione di quella versione, da una pagina di manuale per IBM AIX :

Il comando killall annulla tutti i processi che hai avviato, ad eccezione di quelli che producono il processo killall. Questo comando fornisce un comodo mezzo per annullare tutti i processi creati dalla shell che controlli. Quando viene avviato da un utente root, il comando killall annulla tutti i processi cancellabili ad eccezione di quelli che lo hanno avviato. Se vengono specificati più segnali, solo l'ultimo è efficace.

1 "collega" è l'aggiornamento gratuito da "collega", quindi potrebbe anche.
2 Inizialmente pensavo fosse una cosa Linux o Debian, ma alcune fonti affermano che Linux killallsia derivato da Unix alla BSD.

Risposte:


68

Penso che tu veda killall nel come fare perché per impostazione predefinita richiede il nome preciso del processo, mentre pkill fa corrispondenze di pattern di base. Pertanto, killall è più sicuro per gli utenti da copiare e incollare alla cieca.

Pkill e killall hanno entrambi opzioni distintive. Killall ha una bandiera da abbinare per età del processo, pkill ha una bandiera per uccidere i processi solo su un dato tty. Etcetera ad nausea. Né è meglio , hanno solo specialità diverse.

Vedo dalle loro pagine man che killall proviene dal pacchetto psmisc , che ha diversi processi per la gestione delle utility, ma in particolare non contiene ps. È il pacchetto procps che ha ps, top, kill e pkill (tra gli altri). Scommetto che i procps non avevano originariamente pkill, quindi psmisc si è grattato un prurito e si è inventato un killall.

La pagina man pkill / pgrep dice che sono stati introdotti in Solaris 7. Come hai detto, jgbelacqua , il killall di Solaris non era l'utilità fornita da psmisc, quindi Solaris probabilmente aveva solo il pacchetto procps. Qualcuno voleva uno strumento di processo di abbinamento dei modelli, quindi pkill e pgrep. Non lo so se sia stato sviluppato dal procps dev o aggiunto successivamente. Indipendentemente da ciò, è arrivato ed è diventato parte di * nixes ovunque.

Altre fonti:


1
Hmm - esisteva un killall(vecchio?) Sistema Solaris, ma si comportava diversamente. Ha ucciso tutto.
belacqua,

6
@manish - er, c'era un killall diverso sui sistemi SysV.
belacqua,

1
@djeikyb Il pensiero che killall sia più sicuro suona bene, o almeno questo potrebbe spiegare molta della sua popolarità.
belacqua,

5
@Manish: pkill (no kill) non ha bisogno del numero pid, né del nome del processo. Patter corrisponde al nome del processo.
Javier Rivera,

3
killall is safer for users to blindly copy and paste, tranne se sei su una macchina in cui killall uccide davvero tutto. È un peccato che le due diverse utility abbiano lo stesso nome.
Sdraiati Ryan il

7

Si prega di fare attenzione con "killall". Su alcuni sistemi (dimentico quale), killall uccide tutti i processi. Ignorerà silenziosamente gli argomenti e fermerà completamente il sistema.


5
Questo non è vero. killall senza argomenti non farà nulla e killall non ignorerà gli argomenti. kill -9 -1potrebbe uccidere il tuo sistema e killall -9 -1potrebbe anche. Ma non solokillall [program]
Thomas Ward

6
È vero sui sistemi SysV, come ora menzionato nella domanda originale.
alanc,

3

se attivi / etc / bash_completion, dopo killall <part_of_process_name>e premi tab - auto completa il nome del processo dall'elenco dei processi in esecuzione


2
Lo stesso completamento automatico verrà eseguito con pgrep / pkill. Qualcosa che faccio di solito è pkill plug<tab>uccidere il plug-in flash per Firefox quando so che non ho nulla che voglio usare per un po ', ma voglio comunque usare attivamente Firefox. Questa è una funzione della shell, non una differenza tra killall e pgrep / pkill.
Arcege,

1
Non ho detto che fa differenza - solo una bella funzionalità per evitare la ricerca di PID, nomi di processi ecc.
jet

2

Se guardi le opzioni su entrambi i programmi, vedrai che entrambi fanno la stessa cosa, ma in modi diversi.

pkill eseguirà la corrispondenza su vari attributi di un processo (CMD, PID, PPID, UID ...) e invierà il segnale dato a ciascun processo corrispondente. (Per CMD, viene utilizzata un'espressione regolare, per altri è una stringa). pkill non è interattivo, ma è meglio per i programmi batch.

killall eseguirà la corrispondenza sul nome del processo (comm) o sull'utente (utente), non sull'intera stringa di comando. L'argomento è usato come una stringa semplice e deve corrispondere all'intero valore 'comm' (c'è anche un'opzione --regexp per cambiarlo). killall ha opzioni --interactive e --younger-than, che pkill non ha.

C'è anche un killall5 dai tempi di SysV ed è stato portato su altre varianti UNIX (presumibilmente sotto il pacchetto Ubuntu "sysutils"). Questo si comporta diversamente alla vecchia maniera. Questo veniva spesso utilizzato internamente agli script init per arrestare o passare alla modalità utente singolo.


2
No, né pkillkillalldovrebbe essere usato negli script, solo in modo interattivo e con cautela.
geirha,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.