Newsgroup: it.comp.os.linux.software
Titolo: processi che si bloccano e non si risvegliano

Salve. Premetto che non ho una grande conoscenza dei processi UNIX, per 
questo vorrei chiedere il vostro parere su questo inconveniente.
Ho un disco NTFS (ahimè) contenente mp3 e un altro disco sempre NTFS 
contenente film. Spesso mi capita che cercando di ascoltare un mp3 o di 
guardare un film il lettore si blocca. Allora io chiudo la finestra con 
CTRL+ALT+ESC, vado a vedere nella lista dei processi e noto che il 
processo del lettore è finito nello stato D, che se non sbaglio 
significa che sta aspettando qualcosa da parte di una periferica 
hardware (hard disk? scheda audio?). Questo mi capita con diversi 
lettori (amaroK, Noatun, XMMS per gli mp3 e xine per i film); l'unico 
che sembra non presentare questo problema con gli mp3 è il misero Kaboodle.
Esempio di processi "addormentati":
F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY          TIME CMD
0 D  1000  2879     1  0  82   0 - 26634 lock_p ?        00:07:49 artsd
0 D  1000 15585     1  0  85   0 - 42590 lock_p ?        00:00:00 xine
In questo caso avevo provato a vedere un film e si è bloccato 
addirittura artsd.
Ora io dal basso della mia ignoranza credo che questi processi ricevano 
un segnale di tipo wait, per sbaglio, e naturalmente non si risvegliano 
più. Io non posso ucciderli in alcun modo, kill non ha effetto. Mi hanno 
detto di guardare con strace cosa succede ma francamente non ci ho 
capito molto.
Avete qualche idea sul perchè succeda questo spiacevole fatto, o almeno 
come fare per ucciderli così da poterli avviare nuovamente?
-- 
sunchild(at)sunchild(dot)name
Linux Debian 2.6.8-2-k7

 o almeno come fare per ucciderli cosě da poterli avviare nuovamente?
purtroppo quando succede cosě o attendi che il processo vada in timeout e
termini da solo (e spesso non lo fa) o fai il reboot. 
dai un occhiata qui:
http://www.linuxgazette.com/node/1211
per caso sono due dischi estraibili o esterni?
Sam.
-- 
   [God@Heaven]# tar xzf Universe-1.0.tar.gz
   [God@Heaven]# cd Universe-1.0
   [God@Heaven]# ./configure && make && make install

 per caso sono due dischi estraibili o esterni?
No, sono due normali ATA-133 di marche e dimensioni diverse.


 
Può essere che per sbaglio 2 programmi cerchino di accedere alla scheda
audio contemporaneamente e il sistema si pianti perchè non è programmato
per andare a tracce multiple...  prova a controllato se è installato un
sistema di mixer per la scheda audio....
per uccidere il programma piantato è semplice.... da shell digita prima
"ps-A" quarda il processo che si è piantato che PID ha e poi digita "kill
PID"
-- 
Potete anche fermare me, ma non potete fermarci tutti...
Dopo tutto, "Siamo tutti uguali".

 PID"
Se il programma è in "D" hai voglia a killare..
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Pensa che quand'ero piccolo ero talmente povero che anche l'arcobaleno
lo vedevo in bianco e nero.
		-- Silvio Orlando

 Se il programma è in "D" hai voglia a killare..
In alcuni casi #fuser -k "device" può funzionare! Ammesso che tu sappia su
che periferica è fermo il processo. 
-- 
Simone 
------------------------------
Per rispondermi in e_mail, togli l'anno

 che periferica è fermo il processo. 
lsof|grep /dev puo' aiutare
.a.
-- 
Il mattino ha l'oro in bocca. Il MATTino ha l'OrO In bOcca.
i lma tt ino ha l'o roin bocc a.ilmattinohal'oroinbocca. il ma tt in
oh al' or oi nb oc ca. il matti noha l'oroinbocca. IL MATtiNO Ha l'ORO
InBOCCa. I l m a t t i n o  h a l' o r o i n b o c c a . ilmattinohal'oroin
BoCcA. iLmAtTiNoHaL'oRoInBoCcA.

 lsof|grep /dev puo' aiutare
...per identificare il PID del processo e per sapere da che periferica
aspetta l'input...
...pero' se il processo è in D resta non interrompibile e non lo killi
comunque, no?
Credo che non ci sia proprio nessun modo di far morire un processo in D (se
non ha dei timeout per cui muore da solo in qualche modo)...
Ciauuu
Menez
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 non ha dei timeout per cui muore da solo in qualche modo)...
*credo* che  prima o poi dovrebbe riceve almeno un messaggio di
 errore, quindi riprendere a lavorare (o a morire).


 errore, quindi riprendere a lavorare (o a morire).
In effetti l'unica soluzione potrebbe essere quella di far pervenire al
processo (o al kernel) qualcosa "come se" pervenisse dal device da cui è in
attesa...Tra l'altro questo potrebbe essere utile anche in situazioni ben
diverse...ma non credo si riesca a fare...
Sarebbe altrettanto interessante vedere cosa succede se, ad esempio, su
prova a causare un errore sulla periferica in questione (che so...forzando
lo scaricamento di un modulo?...)...
Cmq è chiaro che SE il problema ha una soluzione "furba" ce l'ha "dal lato
della periferica" e non dal lato del processo....nel senso che la soluzione
sta nel dare una "svegliata" alla periferica e non nel tentare di killare il
processo....
hmmm....temo di non essermi spiegato molto ...:)
Ciauuuuu
