killall mi dà "nessun processo trovato" ma ps

È su Linux?

In realtà ci sono alcune versioni leggermente differenti del nome del comando che sono usate da ps , killall , ecc.

Le due varianti principali sono:1) il nome lungo del comando, che è ciò che ottieni quando esegui ps u; e 2) il nome breve del comando, che è quello che ottieni quando esegui ps senza flag.

Probabilmente la più grande differenza si verifica se il tuo programma è uno script di shell o qualcosa che richiede un interprete, ad es. Python, Java, ecc.

Ecco uno script davvero banale che dimostra la differenza. L'ho chiamato mycat :

#!/bin/sh
cat

Dopo averlo eseguito, ecco i due diversi tipi di ps .

Innanzitutto, senza u :

$ ps -p 5290
  PID TTY      ... CMD
 5290 pts/6    ... mycat

In secondo luogo, con u :

$ ps u 5290
USER       PID ... COMMAND
mikel     5290 ... /bin/sh /home/mikel/bin/mycat

Nota come la seconda versione inizia con /bin/sh ?

Ora, per quanto ne so, killall in realtà legge /proc/<pid>/stat , e prende la seconda parola tra le parentesi come nome del comando, quindi è proprio quello che devi specificare quando esegui killall . Logicamente, dovrebbe essere uguale a ps senza u flag dice, ma sarebbe una buona idea controllare.

Cose da controllare:

1. cosa significa cat /proc/<pid>/stat diciamo che il nome del comando è?
2. cosa significa ps -e | grep db2 diciamo che il nome del comando è?
3. fai ps -e | grep db2 e ps au | grep db2 mostrare lo stesso nome di comando?

Note

Se stai usando anche altri flag ps, potresti trovare più semplice usare ps -o comm per vedere il nome breve e ps -o cmd per vedere il nome lungo.

Potresti anche trovare pkill un'alternativa migliore. In particolare, pkill -f cerca di trovare una corrispondenza usando il nome completo del comando, cioè il nome del comando stampato da ps u o ps -o cmd .

killall cerca di trovare una corrispondenza con il nome di un processo (ma non è molto bravo nella parte corrispondente).

E poiché "ps | grep" e "ps | grep | kill" fanno un lavoro molto migliore, qualcuno ha semplificato questo e ha creato pgrep e pkill. Leggi quei comandi come "ps grep" e "ps kill", poiché quel comando prima ps poi grep e se vuoi uccide.

Ho avuto un problema simile ma /proc/<pid>/stat conteneva la stringa prevista. Usando strace ho potuto vedere che killall accedeva anche a /proc/<pid>/cmdline .

Ho continuato a indagare utilizzando gdb per scoprire che nel mio caso non è riuscito a controllare il mio comando al comando completo inclusi tutti gli argomenti trovati in /proc/<pid>/cmdline . Sembrava che quel percorso del codice fosse attivato perché il nome del file era più lungo di 15 caratteri (che è un valore hardcoded nella fonte di killall). Non ho indagato a fondo se potessi in qualche modo farlo funzionare con killall.

Ma come accennato in altri commenti qui pkill è un'alternativa migliore che non presenta gli stessi problemi.

Il codice sorgente di pkill può essere trovato qui https://github.com/acg/psmisc per gli interessati.