|
|
|
![]() |
|
Strumenti |
![]() |
#1 |
Senior Member
Iscritto dal: Oct 1999
Messaggi: 470
|
determinare le cause di un crash del sistema con linux
è possibile determinare le cause di un crash del sistema?
__________________
elsol.splinder.com |
![]() |
![]() |
![]() |
#2 |
Senior Member
Iscritto dal: Dec 2001
Città: /dev/rotfl
Messaggi: 7276
|
la maggior parte delle volte si.
Ciao.
__________________
....::::fluxbox è talmente veloce che quando digito startx, il WM aspetta che il server Xorg lo raggiunga - PiloZ::::...
|
![]() |
![]() |
![]() |
#3 |
Senior Member
Iscritto dal: Feb 2003
Messaggi: 3571
|
Approfitto di questo 3d per chiedere come capire la causa di crash o freeze. Praticamente ho installato una debian etch su un p3 con 512 di ram chipset via kt133 e ho svariati freeze mentre eseguo compiti banali, tipo stavo cambiando lo sfondo del desktop e mi si blocca (mouse fermo), potrebbe essere un problema hardware?, che log devo leggere?, praticamente questi blocchi non fanno crashare x o un programma in particolare ma rimane propio tutto bloccato.
|
![]() |
![]() |
![]() |
#4 | |
Senior Member
Iscritto dal: Sep 2001
Città: Roma
Messaggi: 1944
|
Quote:
La prima cosa che si fa dopo un crash "inspiegato" è vedere il file /var/log/messages che alla fine contiene i messaggi più recenti, ed all'inizio i messaggi più vecchi. I primi messaggi che troverai sono quelli di avvio della nuova sessione, andando a ritroso arriverai alle prime fasi di avvio, e quindi agli ultimi messaggi della sessione precedente. La "ricchezza" del file dipende dal logger di sistema, che è un programmino dedito solo a scrivere gli eventi. Si può settare il logger per scrivere più o meno informazioni. Per esperienza, spesso i settaggi di default del logger non bastano per capire le cause di strani crash. Altro uso di quel file è quando si vuole capire se una periferica esterna viene riconosciuta: quando uno infila una pennetta USB, per esempio, gli si dice di fare prima tail -F /var/log/messages per vedere in tempo reale i cambiamenti a quel file. Se la pennetta viene riconosciuta, il logger scrive nel file qualcosa di comprensibile, e, soprattutto, in quali devices uno deve cercare il nuovo dispositivo.
__________________
"Oggi è una di quelle giornate in cui il sole sorge veramente per umiliarti" Chuck Palahniuk Io c'ero |
|
![]() |
![]() |
![]() |
#5 | |
Senior Member
Iscritto dal: Sep 2001
Città: Roma
Messaggi: 1944
|
Quote:
CTRL + ALT+F3 per passare a un altro terminale. Se funziona, e abbandoni il server grafico per ritrovarti in una shell nera in cui ti si chiede il login, alllora è solo un problema di server grafico o di KDE/Gnome. Se non funziona, si era "freezato" il kernel. Problemi del genere sono una bella gatta da pelare, perchè se si freeza il kernel, il logger spesso non registra il perchè, ma ciò che è successo appena prima: talvolta basta a capire il perchè, talvolta no.
__________________
"Oggi è una di quelle giornate in cui il sole sorge veramente per umiliarti" Chuck Palahniuk Io c'ero |
|
![]() |
![]() |
![]() |
#6 |
Member
Iscritto dal: Nov 2004
Città: pisa
Messaggi: 204
|
Per il freeze potrebbe anche venire da problemi di temperatura.. anche se sembra un gioco di parole
![]() |
![]() |
![]() |
![]() |
#7 |
Senior Member
Iscritto dal: May 2006
Messaggi: 362
|
Provate ad usare
dmesg |grep 'stringa che vi interessa' Per imparare ad usare dmesg c'è man dmesg o la documentazione in linea. Inoltre se avete una configurazione problematica e volete davvero imparare cose nuove, fate così: se riuscite a loggarvi, anche in modalità testuale, "recovery" o che altro, leggete il file di configurazione del kernel che state usando (se viene da una distro sarà quello di default), in /boot. Per leggerlo in modo comodo (e con la documentazione) installate i sorgenti del kernel e lanciate make menuconfig Andate nella sezione che vi dà problemi e leggete bene l'help di ogni voce che vi sembra interessante (driver, sottosistemi vari). Vedrete che per alcune voci è possibile settare cose come "verbose debugging", "verbose logging" e simili. Ad esempio per lo scsi (che poi è usato per il SATA) è possibile farlo. Vi viene anche detto come attivare la funzionalità, e avrete molti più messaggi di errore (nel caso), che vi aiuteranno a capire cosa succede. Comunque dmesg è la prima cosa. PS: per la compilazione del kernel non sono stato a spiegare i passaggi nei particolari, se vi serve aprite un thread e vi rispondo. |
![]() |
![]() |
![]() |
#8 | |
Senior Member
Iscritto dal: Sep 2001
Città: Roma
Messaggi: 1944
|
Quote:
dmesg è pratiacamente un "cat /var/log/messages". Non ho mai ben capito come funziona, anche perchè le differenze fra Debian, Gentoo e Fedora sono tante. Io agisco sempre sul log "fisico", perchè se c'è qualcosa, in /var/log lo trovi.
__________________
"Oggi è una di quelle giornate in cui il sole sorge veramente per umiliarti" Chuck Palahniuk Io c'ero |
|
![]() |
![]() |
![]() |
#9 | |
Senior Member
Iscritto dal: May 2006
Messaggi: 362
|
Quote:
E' importante usare dmesg, perché è vero che è una sorta di cat /proc/kmsg se non fosse che kmsg non è un file leggibile, neanche da root, ed è il KERNEL RING BUFFER cioè il log di quello che succede al kernel mentre funziona, e tutti gli altri log sono "gerarchicamente" sottostanti. E' piuttosto semplice da usare, ed allo stesso tempo potente (e insostituibile), consiglio la lettura di man dmesg è meno di una pagina, veloce veloce. Inoltre dmesg non si limita a stampare il contenuto del kernel ring buffer, ma se usato con l'opzione -nLEVEL setta il livello di "loquacità" con cui gli errori del kernel compaiono sulla console. dmesg -c pulisce il kernel ring buffer. |
|
![]() |
![]() |
![]() |
#10 | |
Senior Member
Iscritto dal: Feb 2003
Messaggi: 3571
|
Quote:
|
|
![]() |
![]() |
![]() |
#11 | |
Senior Member
Iscritto dal: May 2006
Messaggi: 362
|
Quote:
Fai così dmesg -c poi riavvii dmesg > boot.log e alleghi il file. |
|
![]() |
![]() |
![]() |
#12 |
Senior Member
Iscritto dal: May 2006
Messaggi: 362
|
Così scopriamo se è un problema del boot.
Se non ci sono problemi del boot, cerchiamo di vedere il log giusto. |
![]() |
![]() |
![]() |
#13 | |
Senior Member
Iscritto dal: Feb 2003
Messaggi: 3571
|
Quote:
|
|
![]() |
![]() |
![]() |
#14 | |
Senior Member
Iscritto dal: May 2006
Messaggi: 362
|
Quote:
D'accordo che debian è più affascinante, ma il riconoscimento e la configurazione dell'hw non è fra i suoi punti forti, almeno non sempre in modo semplice. Se i problemi continuano prova anche Knoppix, che in generale è una distro live da tenere sempre a portata di mano. |
|
![]() |
![]() |
![]() |
#15 | |
Senior Member
Iscritto dal: Feb 2003
Messaggi: 3571
|
Quote:
|
|
![]() |
![]() |
![]() |
#16 |
Senior Member
Iscritto dal: Jan 2003
Città: Perugia
Messaggi: 1578
|
spoonman, anche a me è capitata la stessa cosa, mi si bloccava lo schermo a random su gnome, magari quando spostavo le finestre o le ingrandivo/rimpicciolivo. Non andava neanche negli altri terminali.
Avevo una ati radeon 7000. Ho visto che: -usando i driver vesa tutto andava -usando i driver ati o i fglrx disabilitando il dri di xorg tutto funzionava alla perfezione, quindi penso che sia legata all'accelerazione 3d. prova a vedere dentro /etc/X11/xorg.conf e commenta la linea Load "dri" (oppure cambia driver in vesa) salva, riavvia e vedi se funziona |
![]() |
![]() |
![]() |
#17 | |
Senior Member
Iscritto dal: Jan 2004
Città: /dev/sda1
Messaggi: 4060
|
Quote:
![]()
__________________
![]() |
|
![]() |
![]() |
![]() |
#18 | |
Senior Member
Iscritto dal: May 2006
Messaggi: 362
|
Quote:
Il dri potrebbe essere la cusa, soprattutto con Xorg 7. Alla Ati stanno ancora lavorando alla versione dei driver per xorg7, ho trovato qualcuno che è riuscito a farli funzionare, ma ancora la procedura non è standard. Questione di poco tempo, immagino. |
|
![]() |
![]() |
![]() |
Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 18:37.