SIGKILL movimentazione

Question

Se un processo Linux è in attesa di I/O segnale (cioè è in SLEEP stato) e un segnale SIGKILL viene emesso contro di esso, al momento della cessazione (STOPPED state) intende passare attraverso RUNNING o READY stato?

In altre parole, per un processo che gestisce un interrupt di sistema come quello generato da SIGKILL è necessario passare attraverso lo stato RUNNING o READY?

Sapendo che in circostanze normali un processo in grado di gestire un interrupt dal kernel e sapendo che SIGKILL ha uno scopo del tutto contraddittorio di aver ucciso un segnale che non risponde, ero dubbioso su quanto il controllo è dato al processo di essere ucciso, se non del tutti.

Answer 1

Il segnale viene "trasmesso" a un processo dal kernel, quindi l'invio di un segnale da processA a processB utilizza il kernel. Quando viene consegnato SIGKILL, il kernel non consente alcuna attività da parte del processo (modalità utente), in particolare il processo di elaborazione: chiamate atexit, _exit. Niente. Il processo viene semplicemente distrutto dal sistema. Ciò comporta alcune attività in modalità kernel. I dati bufferizzati sono persi. I semafori SYSV e altri oggetti di memoria persistenti del kernel sono rimasti in memoria. Può essere un vero casino.

Se qualcosa nella memoria del kernel sta causando un appendere si utilizza l'interfaccia sysrq in linux:

http://tldp.org/HOWTO/Remote-Serial-Console-HOWTO/security-sysrq.html

--to eseguire qualsiasi parvenza di una chiusura ordinata si può ottenere.

Ecco perché l'utilizzo di SIGKILL è un'assoluta risorsa, perché non puoi sapere cosa stai rompendo. E non risolverà tutti gli impiccagioni.

A cosa stai lavorando esattamente?

Answer 2

Oltre alla risposta di McNamara jim:

SIGKILL (kill -9) non può essere gestito.

Vedere la risposta al numero https://stackoverflow.com/a/2541618/1456519 per ulteriori informazioni.