"Kill <PID>" non sta davvero uccidendo il processo, perché?

Sto cercando di migliorare le mie capacità da riga di comando e ho riscontrato un problema in cui non riesco a interrompere un processo. Digito kill 2200dove 2200 è il mio PID e il processo non viene ucciso. Dopo alcuni minuti l'attesa è ancora in tope ps aux. Ho anche provato a digitarlo con sudo - nessun risultato.

Qualche idea sul perché sarebbe così?

MODIFICARE

Ho trovato una dipendenza strana, dove fgaggiorna l'elenco dei processi:

x@xxx:/etc/grub.d$ ps
  PID TTY          TIME CMD
 1723 pts/0    00:00:00 bash
 2200 pts/0    00:00:00 top
 2202 pts/0    00:00:00 top
 2258 pts/0    00:00:00 ps
x@xxx:/etc/grub.d$ fg
top

x@xxx:/etc/grub.d$ ps
  PID TTY          TIME CMD
 1723 pts/0    00:00:00 bash
 2200 pts/0    00:00:00 top
 2620 pts/0    00:00:00 ps
x@xxx:/etc/grub.d$ fg
top

x@xxx:/etc/grub.d$ ps
  PID TTY          TIME CMD
 1723 pts/0    00:00:00 bash
 2621 pts/0    00:00:00 ps

I processi possono ignorare alcuni segnali. Se invii SIGKILL non sarà in grado di ignorarlo (e nemmeno catturarlo per eseguire le pulizie). Provare:

kill -9 {PID}

Scopri di più leggendo la pagina del manuale:

man kill

Se killviene richiamato senza alcun parametro, invia il segnale numero 15 ( SIGTERM). Questo segnale può essere ignorato dal processo. Questo segnale avvisa il processo per ripulire le sue cose e poi terminare correttamente da solo. Questo è il modo carino.

Puoi anche "inviare" il segnale numero 9 ( SIGKILL) che non può essere ignorato dal processo. Il processo non lo riconoscerà nemmeno, perché il kernel termina il processo, non il processo stesso. Questo è il modo malvagio.

Uno dice che kill -9 <pid>funziona sempre. Questa è un'incredulità . Ci sono situazioni in cui anche kill -9non si uccide il processo. Ad esempio quando un processo ha lo stato D(ininterrotto sleep). Un processo entra in questo stato ogni volta che attende l'I / O (normalmente non molto lungo). Pertanto, se un processo attende l'I / O (ad esempio su un disco rigido difettoso) e non è programmato correttamente (con un timeout), semplicemente non è possibile interrompere il processo . Non importa quello che fai. Puoi solo provare a rendere accessibile il file per continuare il processo.

Nonostante il suo nome non uccida effettivamente i processi, invia segnali ad esso. Dalla pagina man:

kill - send a signal to a process

Il segnale predefinito inviato da kill [pid]è SIGTERM che di solito, ma non necessariamente chiede il processo per terminare. È abbastanza possibile scrivere un programma che suona una melodia felice quando si invia il segnale SIGTERM , ma non è raccomandato.

Un altro segnale comune è SIGHUP che viene spesso utilizzato per chiedere a un programma di rileggere i suoi file di configurazione.

Se vuoi davvero uccidere un programma devi usare il segnale SIGKILL facendo kill -9 [pid].

Sembra che tu stia sospendendo un processo (forse premendo Ctrl-Z nel terminale). In questo stato, il processo non risponderà a un SIGTERM poiché è bloccato. L'esecuzione di 'fg' disattiva il processo, in modo che possa captare il segnale e terminare automaticamente. Questo potrebbe spiegare perché 'fg' sembra aggiornare l'elenco dei processi.

Dall'interno di C ++, ho eseguito:

kill(4024, SIGKILL);

E su un terminale Linux (Ubuntu),

$ ps -ax | grep my_su

L'output è stato:

4024 pts/1    Z+     0:00 [my_subscriber] <defunct>

Apparentemente, (4024) sopravvive ancora. Tuttavia, non appena ho terminato il processo genitore che ha chiamato la precedente dichiarazione "kill", 4024 non è più apparso. Ora giudico che il processo "defunto" non è altro che una riga visualizzata e ho deciso di ignorarlo. Spero che la mia esperienza possa aiutare qualcuno là fuori. Saluti!

È inoltre possibile utilizzare kill -lper visualizzare i segnali supportati dalla propria architettura e ottenere ulteriori informazioni sul segnale che si desidera utilizzare per inviare correttamente un segnale.

Nota: come altri hanno già detto, l'uso di kill -9 {PID}non è raccomandato a meno che non sia un processo di zombi. una volta che un processo riceve un SIGKILL si spegnerà immediatamente senza pulizia o altre procedure appropriate.

Questo è quello che ho usato per pillolare localhost in esecuzione sulla porta 80 (da cli angolare) Ottieni informazioni sull'app in esecuzione sulla porta 80

sudo lsof -i tcp:80

After That 
sudo kill -9 3348

dove 3348è pid del processo in esecuzione