Newsgroup: it.comp.os.linux.iniziare
Titolo: Come si ammazza un processo gia morto?

Ieri sera per non so quale motivo mi è morto xmms insieme a 84 xfsound
(forse è questo il motivo? ^__^). Con ps li vedevo "D" o "DW" come stato, e
tra parentesi quadre. [maggiori dettagli in fondo]
Il problema è che non sono riuscito a ammazzare quei dannati processi.
Killall non andava, neanche kill -9 ha avuto successo, e il problema è che
provando a avviare di nuovo xmms questo non partiva, probabilmente perché
già in "esecuzione" (se così si può dire).
Ho fatto lo sciocco tentativo di passare ad un altro runlevel, con init 1,
ma init non fa altro che mandare ai processi i segnali TERM e KILL, e il
KILL già lo stavo mandando, senza effetto alcuno, con kill -9 (giusto?).
Che fare in questi casi?
E perché?
Ciao, e Grazie in anticipo.
[dettagli sul crash]
Forse perché mi è morto in una console grafica che ho chiuso? Boh? Fatto
sta che in questa console, con xfce, xmms cercando di leggere un file (che
ha riprodotto altre volte) ha smesso di rispondere, dopodiché lo schermo
dsi è riempito di messaggi di errore, di finerstre di errore che hanno
_completamente_ ricoperto lo schermo e continuavano a uscire tanto che
l'unica soluzione è stato chiudere X con un CTRL-ALT-Backspace (ho provato
a dare invio, a tenere invio premuto per chiudere al volo le finestre, ma
niente).
Ri-ciao.
-- 
Antonio :-D

 Che fare in questi casi?
I processi che sono deceduti ma ancora esistenti e' possibile che siano
bloccati in una qualche fase che coinvolge il kernel. In tal caso non
puoi ammazzarli perche' dovresti ammazzare il kernel stesso (e cio'
non e' bello). Pertanto l'unica cosa da fare e' un bel reboot.
 
Davide
-- 
| "If you've done six impossible things before breakfast, why not round 
| it off with dinner at Milliway's, the restaurant at the end of the
| universe?" 
| 

non e' bello). Pertanto l'unica cosa da fare e' un bel reboot.
Beh, reboot per reboot ci proverei a ammazzarlo, sto kernel. :-)
Però, fare un reboot per xmms, ... ora capisco perché sui server meno roba
ci sta e meglio è, anche se un sistema è sicuro e stabile come uno UNIX
vale sempre quel che diceva Henry ford, "meno roba c'è e meno se ne può
rompere". :-)
Ciao Davide.
-- 
Antonio :-D

 potesse scendere cos? in profondit?.
Se un processo legge un file su disco, il pezzo di codice che fisicamente
si interfaccia con il filesystem e' nel kernel.
Davide
-- 
| The IQ of the group is the lowest IQ of a member of the group divided 
| by the number of people in the group. 
| 
| 

 si interfaccia con il filesystem e' nel kernel.
Ora capisco l'importanza dei microkernel, e soprattutto quando si dice di
tenere il filesystem FUORI dal kernel....
-- 
Il segreto dell'eterna giovinezza è la morte prematura, perché soltanto chi
non invecchierà mai resterà per sempre giovane (in memoria di Cristiano, un
ragazzo che si uccise a 23 anni perché la sua adolescenza era finita).

  E perché?
Accantonando il caso di programmi impazziti, una spiegazione
deriva dal fatto che certe strutture dati del kernel rimangono 
utilizzati anche dopo la terminazione del programma, sinche` 
il processo padre non ha ricevuto notifica dell'avvenuta terminazione 
del figlio _E_ ha preso le opportune contromisure, tipicamente invocare 
wait(2) o waitpid(2) e altro ancora.
Conseguentemente, i "figli morti" rimangono nella tabella dei
processi.
Ora: uccidere il processo padre non e` una contromisura utile
in questo senso; d'altronde pero`, in caso di morte del processo
padre, vengono terminati (e ripuliti) anche tutti i processi
figli da esso generati. 
Come extrema ratio puo` valere la pena fare un tentativo.
I dettagli di questo procedimento mi risultano ancora in parte
oscuri (giorno di 48 ore, ci vorrebbe)
-- 
Francesco Romani - Ikitt   (signature under [re]construction)
'A geek is someone who spends time being "social" on a computer.'
'In fact, users don't read /anything/'                         -- Joel Spolsky

Ikitt wrote:

Per vedere chi e' il padre di chi puoi usare pstree.
Ciao
        Luca
-- 
<<>><<>><<>><<>><<>><<>><<<>><<>><<>><<
Luca Paredi
Computing technical supporter              
Universita' degli Studi dell'Insubria  
<<>><<>><<>><<>><<>><<>><<<>><<>><<>><<

 Per vedere chi e' il padre di chi puoi usare pstree.
Azz, e io che pensavo servisse l'esame del DNA...
;)
-- 
il Vide - ICQ# 5301833
http://www.heavy-metal.it
"There is no stronger drug than reality"

 
Io metto sempre il profilattico la modem per cui non sono stato....


 potesse scendere così in profondità.
Alla fine, il kernel da qualche parte deve entrare nella catena. Se un
processo "muore", e al momento della morte la catena è arrivata al
kernel, non ci sono speranze.
Ciao,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)                 [ 
http://www.emmanuelebassi.net
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

 tenere il filesystem FUORI dal kernel....
Non c'entra nulla. Nonostante il microkernel riduca la possibilità di
codice eseguito in kernel space, non elimina la possibilità di processi
in zombie state.


 in zombie state.
E non esiste alcun modo per evitare processi in zombie state?


oscuri (giorno di 48 ore, ci vorrebbe)
E 8 ore di sonno non te le vuoi fare? ;-)
-- 
Antonio :-D

E non esiste alcun modo per evitare processi in zombie state?
Con la Nuova patch del kernel!
Il nuovo kernel 2.6.666-DYD, con la patch del noto sviluppatore inglese Dog
Dylan, dovrebbe apportare notevoli miglioramenti al vostro sistema nel caso
di processi *zombie*, di programmi avidi di RAM che *vampirizzano* le
risorse e anche nel caso di finestre *fantasma* che compaiono e scompaiono
sullo schermo.
Ciao.
-- 
Antonio :-D

 E non esiste alcun modo per evitare processi in zombie state?
Programmare bene. *grin*
Seriamente, no: fintanto che esiste la possibilità di deadlock (o
livelock), esisterà la possibilità che un processo finisca per diventare
uno zombie.


 E 8 ore di sonno non te le vuoi fare? ;-)
E chi dorme tanto? :-D


 sullo schermo.
L'unica accortezza è creare il device node /dev/groucho, per poter
terminare i processi zombie in questo modo:
	cat < /dev/groucho > kill <pid>
Dato che non esiste la patch per kill.
Gli effetti collaterali? Galeon ci mette dieci anni prima di essere
avviato, e ad ogni kill parte un fortune cookie.


  E 8 ore di sonno non te le vuoi fare? ;-)
Anche 10, appunto.
+++
[1] e anche qui, ahime`, non ricordo le modalita` del meccanismo :(
[2] ma, come si sara` notato, la memoria tende a tradirmi ultimamente.


 tutti i processi figli[1].
Nel caso di zombie non si puo' uccidere il padre perche' e' gia' morto. I
processi zombie sono solo delle entry nella process table e verranno
cancellati da init stesso.
I processi non zombie ma bloccati possono essere uccisi sempre tranne 
nel caso in cui si siano piazzati in stato D perche' in genere stanno 
aspettando il completamento di un'operazione di i/o che e' andata male.  
 
-- 
Enrico Bodo  -  Assistant Professor in Theoretical Chemistry 
University of Rome "La Sapienza" 
Department of Chemistry         

E chi dorme tanto? :-D
Ok, se dormi quanto me facciamo 52 ore e non se ne parli più.
Adesso bisogna chiedere a "Root" se ce le concede. :-)
Comunque so per certo che se tiri troppo rischi l'account. :-)
Ciao.
-- 
Antonio :-D

avviato, e ad ogni kill parte un fortune cookie.
Già, avevo in mente i problemi di galeon ma non sapevo come spiegarli. :-)
-- 
Antonio :-D

cancellati da init stesso.
Ma quando vengono rimossi?
Io mi sono accorto di questi zombi da ps aux, eseguito perché non riuscivo
più a lanciare xmms. Ho aspettato un po' ma non sono stati eliminati.
Ciao.
-- 
Antonio :-D

Anche 10, appunto.
No, 38 non mi bastano. :-)
Ciao.
-- 
Antonio :-D

  Nel caso di zombie non si puo' uccidere il padre perche' e' gia' morto.
Depende: puo` anche darsi che il padre lazzarone non abbia ancora fatto
wait() (o non possa farlo).
In effetti probabilmente ho considerato sin troppo comune un caso
particolare.


 Comunque so per certo che se tiri troppo rischi l'account. :-)
Infatti, root è gestito da un BoFH - Bastard Operator from Heaven. ;-D


 Ma quando vengono rimossi?
Non esistendo un euristica che ci possa dire se e quando questi processi
siano effettivamente in grado di terminare da soli (dicesi "halting
problem"), allora vengono eliminati alla chiusura di init.


LoSmilzo wrote:

Ma non avevi detto che i tuoi processi erano Dead e non Zombie?
Un processo Zombie e' un processo che ha finito normalmente, rimane 
nello stato di Z finche' il padre non recupera l'exit status. Se il 
padre termina prima di farlo (perche' magari programmato male), il 
processo Z viene adottato da init che lo termina.
Un processo Dead e' morto, fine, non puoi piu' fargli niente. Accade 
quando rimane appesso durante una syscall che e' andata male. Come 
diceva Bobo molto spesso durante operazioni di i/o.
Un processo D non lo puoi terminare, ne' te ne' init :/
Un processo che finisce in uno di questi stati non occupa CPU, non so 
che succeda alla memoria allocata.
spero di non aver sbagliato mira :-)
byez
-- 
Error: Keyboard not attached. Press F1 to continue.

che succeda alla memoria allocata.
Non so, ma non riuscivo a riavviare un'altra istanza di xmms.
Ciao.
-- 
Antonio :-D

Fallo a volumi montati in RO, se vuoi provare...
Naaa, è che gusto c'è? Pensavo di aspettare quando iniziavo a sentire il
frullare di updatedb! ;-)
Ciao.
-- 
Antonio :-D

 Non so, ma non riuscivo a riavviare un'altra istanza di xmms.
Puo' darsi, ma per esserne sicuri bisognerebbe vedere i sorgenti, che 
xmms prima di partire controlli se c'e' un istanza avviata *senza* 
controllare lo stato di quest'ultima.
Non sono comunque sicuro che sia una buona idea far ripartire un 
programma se il precedente e' Dead, a causa di un qualche problema (bug?).
Per curiosita', il problema te lo ha dato mentre apri un file via rete? 
magari su un volume nfs?
byez
-- 
Documentation is like sex: when it is good, it is very, very good. And 
when it is bad, it is better than nothing. - Dick Brandon

magari su un volume nfs?
No. Un file mpc su un'altra partizione. Già lo avevo aperto dopo aver
installato il plugin almeno un paio di volte. Boh?
-- 
Antonio :-D

  Ma non avevi detto che i tuoi processi erano Dead e non Zombie?
Ecco dove sbagliavo. Dovrei dormire di piu` (o di meno).
