[Roma.pm] SIGKILL

Alessandro Merlani merlani at libero.it
Sun Jan 7 19:27:27 PST 2007


On Monday 08 January 2007 01:53, Emanuele Zeppieri wrote:
...
> > > Non c'e` niente da fare: sigkill non e` ne` trappabile ne`
> > > ignorabile, e kill -9 invia un sigkill, per cui l'unica
> > > possibilita` e` la presenza di un altro processo che
> > > riesegue lo script, come del resto ipotizzavi
> > > anche tu.
> >
> > a dire la verita' c'e' un caso in cui non e' possibile
> > uccidere un processo, neanche usando sigkill, ed e'
> > quando il processo in questione e' in uninterruptible
> > sleep (solitamente quando stava facendo I/O verso
> > qualcosa che non risponde piu').
>
> Certo, ma io non ho mai detto il contrario (leggi bene), e soprattutto
> non mi sembra un'osservazione pertinente al nostro caso.

veramente io non so neanche di che caso stiamo parlando, ho letto 
semplicemente la mail cui ho risposto e ho precisato che c'e' un caso in cui 
sigkill non ha effetto; volendo precisare ulteriormente non e' esatto dire 
che sigkill non e' ignorabile in quanto e' _sempre_ ignorabile; un processo 
che riceve sigkill puo' tranquillamente ignorarlo, stante il fatto che 
comunque il kernel uccidera' il processo (ma questo e' un discorso che 
prescinde il fatto che un processo ignori o trappi, tramite apposito handler, 
un segnale); la differenza e' sottile (ma neanche troppo), in quanto se 
parliamo di ignorare un segnale intendiamo che un processo puo' non avviare 
azioni specifiche, una volta che gli sia stato recapitato un segnale, ed e' 
quello che si puo' tranquillamente fare anche con sigkill. Sebbene 'man 7 
signal' ci dica che sigkill e sigstop non possono essere ignorati, quel che 
si intende non e' che il processo che li riceve deve per forza trapparli ma 
che a prescindere da quel che possa fare il processo, una volta ricevuto il 
segnale, il kernel intraprendera' comunque determinate azioni (che 
prescindono il discorso di ignorare o meno un segnale da parte di un 
processo)

> Infatti se e` vero che ad un processo nello stato di uninterruptible
> sleep non verrebbe recapitato neanche un sigkill,

di piu', la cosa importante non e' tanto che al processo non venga recapitato 
il segnale ma che il kernel non uccida e deallochi le risorse relative al 
processo

> e` altrettanto vero 
> che non appena il processo uscisse dallo stato di sleep, il sigkill (nel
> frattempo accodato in attesa del risveglio del processo target) gli
> verrebbe recapitato e il processo creperebbe all'istante.

dai per scontato che il processo possa uscire dallo sleep (il che il piu' 
delle volte non accade e l'unica alternativa e' il reboot)

> Quindi lo stato di uninterruptible sleep non puo` servire ne` per
> ignorare il sigkill ne` tantomeno per trapparlo.

e' ovvio che non serva per trapparlo, ma per ignorarlo non ci son dubbi che 
serva

> Al limite potrebbe 
> servire per "ritardarlo", ma sarebbe comunque un ritardo del tutto
> inutile, giacche` il processo in sleep non potrebbe *fare nulla*,
> perche` non appena dovesse risvegliarsi gli verrebbe subito recapitato
> il sigkill.

nessuno ha detto che un processo in status D e' un modo per evitare che il 
kernel lo ammazzi dopo un sigkill e permettergli di continuare a lavorare; 
quel che ho detto e':

"a dire la verita' c'e' un caso in cui non e' possibile
uccidere un processo, neanche usando sigkill, ed e'
quando il processo in questione e' in uninterruptible
sleep (solitamente quando stava facendo I/O verso
qualcosa che non risponde piu')."

ne piu' ne meno

> (Potrebbe rimanere per sempre in uninterruptible sleep, ma in questo
> caso sarebbe per sempre del tutto impotente).

e chi ha detto che non lo sarebbe?


-- 
Alessandro Merlani
"Aspetto che il panico cresca, quando la paura si tramuta in
visioni celestiali, inizio a staccare..." (Kevin Schwantz)


More information about the Roma mailing list