spoonman
09-06-2006, 00:37
è possibile determinare le cause di un crash del sistema?
View Full Version : determinare le cause di un crash del sistema con linux
PiloZ
09-06-2006, 00:51
la maggior parte delle volte si.
Ciao.
Ciao.
Hall999
09-06-2006, 01:14
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.
Scoperchiatore
09-06-2006, 09:50
è possibile determinare le cause di un crash del sistema?
Nella directory /var/log sono presenti vari log relativi al sistema, ai suoi avvi e spegnimenti.
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.
Nella directory /var/log sono presenti vari log relativi al sistema, ai suoi avvi e spegnimenti.
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.
Scoperchiatore
09-06-2006, 09:52
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.
Quando è così, la prima cosa che devi fare è premere
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.
Quando è così, la prima cosa che devi fare è premere
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.
aik
09-06-2006, 11:42
Per il freeze potrebbe anche venire da problemi di temperatura.. anche se sembra un gioco di parole :D
To-shi-baaa
09-06-2006, 11:55
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.
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.
Scoperchiatore
09-06-2006, 14:35
Per il freeze potrebbe anche venire da problemi di temperatura.. anche se sembra un gioco di parole :D
A me riavvia di blocco, e basta.
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.
A me riavvia di blocco, e basta.
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.
To-shi-baaa
09-06-2006, 15:08
A me riavvia di blocco, e basta.
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.
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.
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.
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.
Hall999
09-06-2006, 16:22
Quando è così, la prima cosa che devi fare è premere
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.
eh si ma intendo propio bloccato, non riesco a passare a un'altro terminale.
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.
eh si ma intendo propio bloccato, non riesco a passare a un'altro terminale.
To-shi-baaa
09-06-2006, 17:06
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.
Immagino non abbia usato dmesg, non mi hai risposto.
Fai così
dmesg -c
poi riavvii
dmesg > boot.log
e alleghi il file.
Immagino non abbia usato dmesg, non mi hai risposto.
Fai così
dmesg -c
poi riavvii
dmesg > boot.log
e alleghi il file.
To-shi-baaa
09-06-2006, 17:08
Così scopriamo se è un problema del boot.
Se non ci sono problemi del boot, cerchiamo di vedere il log giusto.
Se non ci sono problemi del boot, cerchiamo di vedere il log giusto.
Hall999
09-06-2006, 19:00
Così scopriamo se è un problema del boot.
Se non ci sono problemi del boot, cerchiamo di vedere il log giusto.
non avevo letto la tua risposta mi era sfuggita, cmq ora ci installo debian sarge e vedo se fa gli stessi scherzi di etch
Se non ci sono problemi del boot, cerchiamo di vedere il log giusto.
non avevo letto la tua risposta mi era sfuggita, cmq ora ci installo debian sarge e vedo se fa gli stessi scherzi di etch
To-shi-baaa
09-06-2006, 21:10
non avevo letto la tua risposta mi era sfuggita, cmq ora ci installo debian sarge e vedo se fa gli stessi scherzi di etch
Perché non provi anche Ubuntu?
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.
Perché non provi anche Ubuntu?
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.
Hall999
09-06-2006, 21:15
Perché non provi anche Ubuntu?
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.
knoppix ci va alla grande ma secondo me debian non è difficile da configurare e installare anzi, ho provato una volta anche suse e praticamente non riuscivo ad orizzontarmi con tutte le personalizzazioni fatte
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.
knoppix ci va alla grande ma secondo me debian non è difficile da configurare e installare anzi, ho provato una volta anche suse e praticamente non riuscivo ad orizzontarmi con tutte le personalizzazioni fatte
Macche
10-06-2006, 10:29
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
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
Artemisyu
10-06-2006, 13:11
la maggior parte delle volte si.
Ciao.
Questa risposta, in tutta la sua sintesi e profondità, è davvero geniale :)
Ciao.
Questa risposta, in tutta la sua sintesi e profondità, è davvero geniale :)
To-shi-baaa
10-06-2006, 14:03
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
Con il driver vesa funziona praticamente sempre tutto (anche il dispositivo usb per fare le uova sode), però non è proprio il massimo della bellezza.
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.
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
Con il driver vesa funziona praticamente sempre tutto (anche il dispositivo usb per fare le uova sode), però non è proprio il massimo della bellezza.
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.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.