Blocco Debian

[psimem]

E' da una settimana che su una delle macchine nelle quali gira debian (lenny amd64) succede una cosa strana: quando tento di sbloccare la macchina dallo screen saver non mi risponde piu' (monitor spento) e l'unica possibilita' e' un reset manuale.
Tanto per cominciare a capirci qualcosa, dov'e' che posso trovare eventuali messaggi di errore del server X?

[Gimli[2BV!2B]]

Potresti trovare qualcosa nel log di Xorg relativo all'avvio precedente: /var/log/Xorg.0.log.old
Se i messaggi sono a livello kernel potresti trovare qualcosa in /var/log/dmesg.0
Ttrattandosi di un problema ripetibile, potresti collegarti in ssh e tenere aperta una sessione root, oppure sparare i messaggi su di un altro pc via UDP (in teoria 'sta cosa andrebbe fatta con una console seriale, con la rete di mezzo i messaggi potrebbero non arrivare...).

Immagino la terrai aggiornata; in tal caso, avendo coordinate temporali, puoi controllare il log di apt (/var/log/apt/history.log) per cercare di individuare l'aggiornamento che potrebbe aver introdotto il problema.

P.S. non citi né terminali virtuali (Ctrl Alt F1, F2, ...) né Magic SysRq, hai provato ad utilizzarli?

[psimem]

Ciao Gimli, dunque:

Originariamente inviato da Gimli[2BV!2B]

Potresti trovare qualcosa nel log di Xorg relativo all'avvio precedente: /var/log/Xorg.0.log.old

In Xorg.0.log.old non mi sembra di vedere nulla di strano.

Se i messaggi sono a livello kernel potresti trovare qualcosa in /var/log/dmesg.0

Neppure in dmesg nulla.

Ttrattandosi di un problema ripetibile, potresti collegarti in ssh e tenere aperta una sessione root, oppure sparare i messaggi su di un altro pc via UDP (in teoria 'sta cosa andrebbe fatta con una console seriale, con la rete di mezzo i messaggi potrebbero non arrivare...).

Qui andiamo sul complicato, teniamola come ultima spiaggia. PS: chiedo scusa, ma non ho specificato che non sempre si verifica il problema, anzi il tutto e' piuttosto casuale.

Immagino la terrai aggiornata; in tal caso, avendo coordinate temporali, puoi controllare il log di apt (/var/log/apt/history.log) per cercare di individuare l'aggiornamento che potrebbe aver introdotto il problema.

Si' la distro e' aggiornata anche se spero il problema non dipenda da questo, dato che gli utlimi aggiornamenti fatti erano tutti relativi alla sicurezza .

P.S. non citi né terminali virtuali (Ctrl Alt F1, F2, ...) né Magic SysRq, hai provato ad utilizzarli?

I terminali virtuali non riesco ad utilizzarli (nessuna combinazione normale di tasti sembra funzionare). La Magic SysRq non la conoscevo, appena si ripresenta il blocco provo ad utilizzarla.

[Gimli[2BV!2B]]

Ok, nel tuo caso utilizzerei solo la Magic SysRq r per cercare di riprendere il controllo della tastiera, poi proverei ad accedere al primo terminale virtuale:

1. Alt Stamp r -> (unRaw) Cambia modalità della tastiera
2. Ctrl Alt F1

Se non dovesse funzionare prova comunque a terminare la sequenza di spegnimento/riavvio eisuo/b (se funziona almeno non stressi inutilmente la macchina).

Aspetta qualche secondo tra ogni combinazione di tasti e tendi l'orecchio/controlla le lucine per capire se effettivamente scatenano qualcosa; il sistema potrebbe essere molto occupato a fare qualcosa e potrebbero essere necessari vari minuti per completare con successo lo spegnimento/riavvio.

[psimem]

Allora, il problema si e' ripresentato e nessuna combinazione dei tasti sembra funzionare .
Ho notato pero' che il blocco sembra presentarsi solo quando lascio il pc acceso (e quindi in seguito parte in automatico lo screen-saver) con due sessioni utente aperte (sulla stessa macchina ho due account).

[sacarde]

Originariamente inviato da Gimli[2BV!2B]

Ok, nel tuo caso utilizzerei solo la Magic SysRq r per cercare di riprendere il controllo della tastiera, poi proverei ad accedere al primo terminale virtuale:

1. Alt Stamp r -> (unRaw) Cambia modalità della tastiera
2. Ctrl Alt F1

Se non dovesse funzionare prova comunque a terminare la sequenza di spegnimento/riavvio eisuo/b (se funziona almeno non stressi inutilmente la macchina).
...

non ho capito a cosa serve il tasto: r

[Gimli[2BV!2B]]

Se le SysRq vanno a vuoto vuol dire quasi certamente che il kernel è andato a farsi un giro con un panic. In questo caso, se il video è inutilizzabile, occorre tentare altre strade per leggere l'errore.

Esiste però un'altra strada potenzialmente antipatica: la possibilità che si tratti di Machine Check Exceptions.
Solitamente sono scatenati da problemi all'hardware.
Mi è anche capitato di averne a causa di software, scatenati proprio dai driver video, nel mio caso gli open per ATI svn di qualche mese fa.

Dovrebbe essere possibile trovare questi errori in /var/log/mcelog
Se il log non esiste o è vuoto è preferibile controllare se l'errore è presente ma viene ignorato: eseguire il programma mcelog al primo riavvio dopo il presentarsi del problema.

Per finire, sacarde, la SysRq r cambia la modalità in cui il kernel interpreta l'input della tastiera, passando dalla raw/scancode (che converte i codici in un modo particolare e li passa ad Xorg) alla XLATE/ascii, in modo tale che il kernel interpreti direttamente i codici che gli comunichi con i tasti.

'r' - Turns off keyboard raw mode and sets it to XLATE.

[psimem]

Ok, solo un aggiornamento della situazione: confermo che il problema si presentava solo nel caso lasciassi loggati entrambi gli utenti, ma la ragione penso rimarra' sepolta nel tempo... Infatti in questi giorni ho deciso di far pulizia in modo radicale (anche causa cambio hardware), per cui ho installato ex-novo una bella squeeze amd64 con kde4.
Grazie ancora a gimli per il tempo dedicato .

[Gimli[2BV!2B]]

Bene, almeno ti ho introdotto alla magica ma noiosa arte di "sollevare gli elefanti"

Ciao!