Newsgroup: it.comp.os.linux.iniziare
Titolo: kill -9

Quando esco da xine in modo poco pulito, i suoi processi restano attivi, 
faccio top, do il n° del processo, do 9 (è brutale, lo so...) e li 
uccido...tutti tranne uno, che non ne vuole sapere e resta ancora 
attivo. A parte che si frega circa 25 mb di ram, con questo processo 
ancora attivo non riesco a rilanciare xine, che dice che l'audio è 
occupato...come faccio a eliminarlo?
Ciao  e grazie
Ps ho provato anche da root, ma niente, non se ne vuole andare...e si 
che top dice che non ci sono zombie	
-- 
  (o_      Edoardo "Edoloz" Carminati ("...back with Tux")
  //\     "VI" Registered Linux user #301558
  V /      "VI" = "V"ery "I"ncompetent  : )
  Debian   Per rispondere togli il_gatto_dal_forno

 occupato...come faccio a eliminarlo?
Quel processo resta vivo con il -9 ??? Non esiste programma che può ignorare
il SIGKILL, stranissimo.
-- 
"Windows cerca di fare Unix e ci riesce male, Red Hat cerca di fare Windows
e ci riesce benissimo" (Jimmy Olgeni)

 il SIGKILL, stranissimo.
Non e' vero. Ne abbiamo parlato poco tempo fa.
-- 
Enrico Bodo  -  Assistant Professor in Theoretical Chemistry 
University of Rome "La Sapienza" 
Department of Chemistry         

 Non e' vero. Ne abbiamo parlato poco tempo fa.
Da quello che ne sapevo anche io, con il -9 gli viene intimato di 
suicidarsi, se non lo fa entro un certo tempo, il S.O. lo fa fuori 
lui...potresti darmi maggiori indicazioni?
grazie


 lui...potresti darmi maggiori indicazioni?
Se da un lato e' vero che un generico processo non puo' ignorare il SIGKILL,
e' anche vero che a volte un processo puo' rimanere bloccato durante una system
call (che e' kernel). 
Se per un bug, un difetto hardware o una scelta progettuale la system
call si pianta, il processo va a finire in uno stato di "uninterruptible sleep" 
(man top, status D). Quel processo non puoi piu' ucciderlo perche' rischi di
lasciare il kernel in uno stato inconsistente. A volte l'uccisione del padre
del processo lo rende uno zombie che verra' aliminato dopo un po'. Altre
volte non c'e' nulla da fare (a parte il reboot).
Se volete testare l'effetto montate uno share nfs senza lo switch
"intr" o quello "soft" e poi tirate giu' la connessione di rete. Tutti i
processi che usavano lo share dovrebbero andare in status D fino al ripristino 
della rete. 
Se la causa dell'incartamento e' un'operazione di i/o gestita da un modulo, 
un 'rmmod' ben assestato potrebbe risolvere il problema. 


 rischi di lasciare il kernel in uno stato inconsistente. 
In che senso 'inconsistente'?
-- 
Jenny ti voglio bene e ti amerň per sempre

 In che senso 'inconsistente'?
Il kernel puo' essere lasciato in uno stato inconsistente da un driver
difettoso: questo succede sia che ci sia un baco nel driver sia che il 
driver stesso sia stato ucciso prima di avere finito quello che doveva fare
(questo succede solo su "fast" device).
Per il primo caso vedi:
http://www.xml.com/ldd/chapter/book/ch04.html
Sezione: "Debugging sistem faults"
Ma la cosa e' analoga. Il non fare un'operazione o il farla male sono
situazioni simili. 


 
Argh....roba troppo tecnica per me.
Ma è la parola 'incosistente' che non capisco: i driver lavorano in kernel
space o user space?
Inconsistente mi sembra come se...al kernel mancasse qualcosa, non so se mi
spiego.
-- 
Jenny ti voglio bene e ti amerò per sempre

 volte non c'e' nulla da fare (a parte il reboot).
Nel mio caso non c'erano zombie, comunque alla fine (dopo qualche 
minuto.....) č stato rimosso.
Ciao


 spiego.
Non devi intenderlo in quel senso, ho tradotto male dall'inglese inconsistent 
cioe' incoerente.
