Newsgroup: it.comp.os.linux.sys
Titolo: Re: Incredibile: un processo mt erase bloccato non rilascia /dev/tape

 Mt è sempre fra i processi, ed il tape (scsi) è ancora busy!!!
Se sta attraversando il kernel, mi sa che non lo killi
neanche se ti metti a pregare in aramaico...
bye G.L.

 questo cavolo di comando bloccato.
Mi sa che non ti rimane molta speranza.
Davide
-- 
Windows: an Unrecoverable Acquisition Error! 

 questo cavolo di comando bloccato.
Non hai molte possibilità.
Se il processo si blocca per errori nell'I/O e si è freezzato 
nell'esecuzione di una syscall, non lo ammazzi più...

 questo cavolo di comando bloccato.
fai un ps aux , se è in stato "D" ti tocca riavviare.
al limite puoi resettare lo scsi bus se hai il tasto. ( non proprio
bello....)
-- 
Ma questo era un gol cosi' facile che non saremmo riusciti a segnarlo
neppure noi.
                -- Fabio Noaro, telecronista sportivo, ripreso in
                   "Mai Dire Gol"

 
COn la 2.6 non dovrebbe succedere più, vero?
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
	Prima di parlare collegare la spina del cervello,
	 leggere e in caso di schermata blu riavviare.

 COn la 2.6 non dovrebbe succedere più, vero?
non so' se hanno fatto una patch o qualcosa di simile , ma la soluzione non
è banale, anche se mandi un sigkill ad un processo è normale che pretenda
di finire di scrivere i dati su un device.....
-- 
        Hessiano o non hessiano,
        questo e' il teorema.

 
Ok, ma se non ricordo male un eventuale errore non era bloccante e prima 
o poi il processo veniva terminato


 o poi il processo veniva terminato
non so' bisognerebbe vedere se sta cosa è stata implementata , la
definizione di "bloccante" in questo caso pero' non è molto chiara...
-- 
Le persone spesso trovano piu' facile essere un effetto del passato
piuttosto che una causa del futuro.

 
Mi era capitato una decina di mount  con carico segnalato dall'apposito 
applet di afterstep che era arrivato ad e


 o poi il processo veniva terminato
Il problema mi sa che (prendilo con beneficio di inventario) e'
l'i/o sincrono tipico di tutti gli unix: finche' per un motivo o
per l'altro il processo rimane nel kernel, sulla syscall, in
quello stato il processo non si puo' killare. Si puo' killare
quando questo torna in user space. Qui ho l'impressione che non
sia una questione di errore, quanto di un deadlock della routine
nel kernel.
Mi capitava su sco unix quando ad esempio un nastro, (che so,
un archive), era configurato con un irq sballato. Il tar si
piantava e non era possibile killarlo, ed il motivo era facilmente
intuibile: la routine si aspetta un interrupt su un numero di irq
dove il segnale ovviamente non arriva mai, e il processo rimane
li' "come un fesso" sul kernel.
Non so se l'i/o asincrono dei nuovi kernel serie 2.6.x possa
risolvere il problema: nella mia ignoranza, non so se i
programmi vadano riscritti o meno per sfruttare queste nuove
features. Per i/o asincrono suppongo si intenda che il processo
puo' tranquillamente fare la chiamata a sistema e ritornare subito
in user space, dove puo' attendere il completamento della stessa,
o sbaglio? Ma per far cio', il programma non dovrebbe essere
appositamente concepito?
bye G.L.