Newsgroup: it.comp.os.linux.sys
Titolo: Killare un processo con codice "D"

Ciao,
per caso sapete se esiste un sistema per killare un processo a cui è
associato il codice "D" (da "man ps": "D   Uninterruptible sleep (usually
IO)").
Non credo che quei processi ignorino totalmente i segnali, senza contare
che il sistema deve essere in grado di interrompere un processo quando
necessario.
Per farvi un esempio, stamattina ho commesso l'errore madornale di
lanciare il benchmark con hdparm su una partizione montata.
Il sistema continuava a funzionare, ma quel processo è entrato in uno
stato di sleep appunto non interrompibile, al punto che comandi come
"halt" o "reboot" non arrivavano alla fine (quindi ho dovuto resettare in
maniere poco gentili).
Io uso Debian Etch con kernel 2.6.12.
Grazie per ogni eventuale delucidazione!
-- 
      ______________
(*)--[::::::::::::::]--(*)
(*)--[>::d1s4st3r::<]--(*)
(*)--[::::::::::::::]--(*)
(*)--[::wonder'ing::]--(*)
(*)--[::what's::::::]--(*)
(*)--[::^happening::]--(*)
(*)--[::|^::::::::::]--(*)
(*)--[__||__________]--(*)
 |......................|
http://xoomer.virgilio.it/
 +------> mental_insomnia/
(*) <-------------------+

 Non credo che quei processi ignorino totalmente i segnali
Invece lo fanno, perché sono in sleep dentro il kernel.
Se un processo rimane in quello stato per sempre, è un baco nel kernel.
Ciao,
-- 
Daniele Orlandi

 indica un problema hardware.
Un problema hardware[1] NON DEVE lasciarmi un processo in stato D per
sempre. Il kernel deve reagire al problema e ritornare un errore al
processo.
[1] Che non sia grave al punto di corrompere qualcosa. Un disco rotto, una
periferica USB che impazzisce, etc.. non sono gravi da questo punto di
vista.
Ciao,
-- 
Daniele Orlandi

> Per caso stavi facendo hdparm su NFS e questo e' crollato?
come si fa' a fare hdparm su nfs ?
-- 
- Cosa separa l'uomo dalla scimmia?
- Il Mediterraneo.
                -- Da it.hobby.umorismo

 indica un problema hardware.
quoto , nella fattispecie i dischi.....
-- 
I 10 anni piu' lunghi per una donna sono quelli che vanno dai 39 ai 40.

 Non e' che il disco o controller stiano andando a donnine allegre?
No, niente NFS, l'ho fatto sul mio disco dove è montata la directory
radice. Ho aspettato qualche minuto, poi mi sono reso conto che si era
bloccato. La stessa cosa l'ho poi fatta 5 minuti dopo da una Knoppix sul
disco smontato e tutto ha funzionato a dovere.
Non credo che il disco e/o il controller mi stiano abbandonando, non mi
hanno mai dato problemi di nessun tipo.
A riguardo ho due domandine:
1) c'è un timeout oltre il quale il kernel provvede a rimuovere quel
processo in stato D e a rilasciare la periferica di I/O (bugs a parte)?
O per default, quello stato persiste ad libitum?
Perchè se ciò dovesse capitare su un server di produzione, è un bel
gran problema.
2) esiste qualche sistema per bypassare il problema (mi riferisco a
qualche tecnica di kernel hardening o a qualche hack che non rientra nel
ramo ufficiale)?
Grazie per l'aiuto (anche a Daniele Orlandi)!


 ramo ufficiale)?
Bugfixing :)
Se intendi qualche workaround, non ne sono a conoscenza, se non usando un
kernel debugger con risultati abbastanza imprevedibili.
Ciao,
-- 
Daniele Orlandi

 processo.
Ammesso che sia possibile.
Se il timer (per il timeout) non funziona (problema HW), come
si fa a sapere se una periferica non risponde per un errore
od e` solo lenta.
bye,
-- 
piergiorgio

 timeout. La mancanza (o il malfunzionamento) del meccansimo è un baco.
Scusa, ma se vi sono _tanti_ processi in attesa di I/O
dallo stesso dispositivo (disco, per esempio), come fai
a distinguere un timeout causato dalla lunga coda (di
processi), da un timeout causato da un difetto HW?
Non e` proprio banale, il problema.
bye,
-- 
piergiorgio

 Se il timer (per il timeout) non funziona (problema HW)
Il timer per il timeout è implementato con il timer di sistema. Non
considererei un guasto al system timer come un problema "non grave" :)
Ciao,
-- 
Daniele Orlandi

 serio.
E' possibile... ma rimane un baco del kernel quello di non essere in grado
di gestire la situazione.
Ciao,
-- 
Daniele Orlandi

 cura.
Orco boia!
Allora inizio a passare al setaccio tutto l'hardware che presumibilmente
potrebbe avere dei problemi. Accidenti, spero non sia quello (anche
perchè il PC è recente, l'ho preso nuovo l'anno scorso).
Io uso un kernel 2.6.12, e ti dirò una cosa: stamattina mi è capitato
questo problema per la seconda volta. La prima volta risale a 4/5 mesetti
fa, e il processo incriminato in quel caso era Firefox.
Vedrò di andare a fondo di questa faccenda... conoscete dei tools in
grado di effettuare dei test mirati per questo tipo di problema?
Io per ora ho provato Memtest86+ per la RAM, poi ho usato hdparm per il
benchmark dei dischi, stress e crashme (ora voglio provare anche spew).
Se c'è qualcosa che si sta scassando, spero sia la RAM (il meglio del
peggio).
Grazie per queste preziose info e ciao!


 considererei un guasto al system timer come un problema "non grave" :)
Per prima cosa, una moderna CPU ha piu` di un timer, magari
solo uno non funziona correttamente.
Secondo, il "funzioanare male" non vuol dire che non funzioni proprio,
magari e` solo piu` veloce (o lento).
Infine, per il problema timeout, si potrebbe anche non usare un timer,
sapendo che non funziona, ovviamente.
Il problema e` legato all'interazione driver/processo.
bye,
-- 
piergiorgio

 Il problema e` legato all'interazione driver/processo.
Certo, è il driver che deve avere sempre una scappatoia da un
uninterruptible sleep.
Ciao,
-- 
Daniele Orlandi

 questo problema per la seconda volta
Magari prima che capitasse avevi un altro kernel?
Cmq, SysRq+t ti farà capire qual è il subsystem incriminato.
Ciao!
-- 
Daniele Orlandi

 processi), da un timeout causato da un difetto HW?
Il timeout dev'essere sulla richiesta al disco che ha una coda molto
piccola. Quando il disco smette di risponderti, il processo che ha fatto la
richiesta riceve un errore e, già che ci sei, tutte le richieste in coda
per quel disco fanno la stessa fine.
Ciao,
-- 
Daniele Orlandi

 IO)").
mmhh ... come funziona?
Il processo e' in sleep perche' aspetta qualcosa da un altro processo. Se
per qualche raggione il processo che deve mandare l'input muore allora
addio. In questo caso dovrebbe nascere il processo <defunct>
--
Massimiliano
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 uninterruptible sleep.
Ma cosa succede se hai una periferica che, correttamente, potrebbe
non rispondere mai?
In realta` essere in "D" e` proprio quello che si vuole, in quel caso.
bye,
-- 
piergiorgio

 per quel disco fanno la stessa fine.
Ma esistono periferiche, per esempio SCSI, dove si possono
accodare piu` richieste, non e` neanche detto che il driver
debba sapere quante, in teoria.
Inoltre potrebbe essere, come detto altrove, che una perificare
non risponda mai e che questo sia il suo funzionamento corretto.
Ovviamente, nel caso di dischi, il problema non si pone, ma
non tutte le periferiche sono dischi.
Poi dipende anche da cosa e` il "driver".
Se per esempio questo aspetta dati dalla seriale, che magari arrivano
da una tastiera, puo` aspettare fino a quando l'utente non tocca un
tasto, il che vuol dire anche per sempre.
In questo caso e` possibile implementare il tutto a livello kernel
ed avere un driver che, per sua natura, aspetta e lascia i processi
in stato "D", finche` non si verifica un evento.
Ovviamente un'alternativa su tale driver e` dividerlo in due parti,
una kernel ed un altra user, ma cio` non toglie che potrebbe anche
(ed e` successo) essere implementato come sopra.
bye,
-- 
piergiorgio

 In realta` essere in "D" e` proprio quello che si vuole, in quel caso.
  Si, ma non per sempre.
-- 
Alessandro Selli
http://alessandro.route-add.net
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.

 non rispondere mai?
Il kernel generalmente si mette in attesa con un
wait_event_uninterruptible_timeout(), se l'hardware non risponde, allora
scatta il timeout che è implementato con il fondamentalissimo system timer.
Ciao,
-- 
Daniele Orlandi

 in stato "D", finche` non si verifica un evento.
No, non ha senso lasciarli in stato D perché non sarebbero killabili.
Ciao,
-- 
Daniele Orlandi