Dove sono i log di panico del kernel?

Ho un problema con Handbrake / ffmpeg. Dopo ~ 5 minuti di transcodifica, il computer si blocca. Sono abbastanza sicuro che sia un panico del kernel perché il blocco maiuscole inizia a lampeggiare.

Ci sono alcune domande logiche su cosa fare e alcune su bug specifici, ma sto davvero cercando una cosa: cosa è successo prima che tutto morisse ?!

Ho controllato /var/log/kern.loge tutto ciò che vedo in quel momento sono io che inserisco un DVD e poi qualche minuto dopo, il sistema si avvia. Nessun errore, nessun avviso di panico.

Esiste un modo per forzare la registrazione del panico? Sono abbastanza sicuro di poterlo riprodurre (è successo al 100% delle volte che ho provato di recente), quindi mentre preferisco questo "appena funzionato", sono abbastanza felice di riavviare alcune volte se ciò significa che posso trova la causa del panico.

Tutti i log di sistema in Ubuntu sono gestiti da ciò rsyslogche mantiene la sua configurazione in /etc/rsyslog.confe /etc/rsyslog.d/.

Per ulteriori informazioni su come configurare rsysloge le possibili opzioni, visitare il rsyslog.conf man page.

Aprendo /etc/rsyslog.d/50-default.confpuoi vedere che una delle righe contiene

*.*;auth,authpriv.none -/var/log/syslog*

Ciò significa che il file che stai cercando in questo caso è uno degli enormi /var/log/syslogregistri che probabilmente avrai.

Puoi vedere che il nome del file inizia anche con un -, questo significa che il file viene memorizzato nella cache prima della scrittura, è fantastico ma può lasciarti con un registro errato, quello che vuoi è che il registro venga scritto non appena si verifica un problema. Rimuovere il trattino e riavviare o ricaricare, rsyslogquindi arrestare nuovamente il computer, controllare /var/log/syslog.

Se è davvero un panico del kernel, non verrà scritto in un registro tramite i metodi normali. Poiché a questo punto il kernel si è bloccato, scrivere nel filesystem è un'operazione rischiosa - non si può più fidare di gran parte del kernel, quindi le scritture nei log potrebbero effettivamente spargere schifezze casuali sul bootloader!

Al contrario, è possibile scaricare il contenuto della memoria nello swap e quindi eseguirne il debug in un secondo momento. Questo è noto come crash del kernel / core dump.

Ubuntu Wiki ha un CrashdumpRecipe che può essere utile - anche se sembra un po 'obsoleto, non penso che troppo dovrebbe essere cambiato.

Porta seriale

La porta seriale è un semplice meccanismo di comunicazione di basso livello tra computer.

vantaggi:

• configurazione semplice una volta (se hai l'hardware)
• affidabile, poiché la trasmissione dei dati dipende solo da semplici fili e API del kernel, che ha meno probabilità di essere influenzata dal panico rispetto al sottosistema TCP / IP.

Svantaggi:

• la maggior parte dei laptop moderni non ha più la porta seriale (esposta?) per risparmiare spazio. Ma i desktop e le macchine virtuali lo fanno ancora.
• è necessario anche un secondo computer con porta seriale per ricevere i dati, ma questo è praticamente il caso di tutte le schede di sviluppo integrate come Raspberry Pi.
• limitato dalla lunghezza del cavo seriale del livello fisico, a differenza delle reti TCP / IP che sono illimitate. Ciò può tuttavia essere risolto con un dispositivo che si interfaccia tra seriale e TCP / IP. Ma ci sono dispositivi che si convertono tra i due.

La porta seriale si presenta così:

e su RPI è disponibile tramite GPIO.

Quindi, se si dispone dell'hardware richiesto, connettersi dal secondo computer al computer principale con:

screen /dev/ttyS0 115200

Questo in realtà ti dà una shell.

Quindi sulla macchina principale, avvia l'operazione che va nel panico.

Quando si verifica il panico, il dump del panico viene trasmesso in streaming alla seconda macchina e puoi vedere tutto scorrendo verso l'alto sul terminale.

Altri metodi

Esistono anche altri metodi che superano i limiti hardware sopra menzionati, a costo di essere più complessi e meno affidabili. Metodi notevoli:

• netdump: trasmette il panico su TCP / IP. Si basa sul sottosistema TCP / IP non corrotto.
• kdump: sembra essere il meccanismo sottostante di linux-crashdump menzionato in: https://askubuntu.com/a/104793/52975 Avvia un secondo kernel Linux per esaminare il kernel bloccato. Che cosa potrebbe andare storto?! :-)

Vedi anche questa grande risposta: https://unix.stackexchange.com/questions/60574/determining-cause-of-linux-kernel-panic

Step debugging

Alla fine, ottenere l'output di panico richiede che alcune funzionalità del kernel funzionino e qualsiasi funzionalità del kernel potrebbe essere danneggiata dal panico.

Ma chi ha bisogno di panico se puoi usare GDB sul kernel? Se sei quel hardcore, dai un'occhiata a:

• QEMU o altre macchine virtuali: https://stackoverflow.com/a/42316607/895245
• JTAG

Ogni problema cade quando hai piena visibilità (e abbastanza tempo!).