Salvare e analizzare i crash dump di Linux con kdump

Cosa registra kdump in caso di crash del kernel

kdump prepara il backup di un’immagine di memoria del kernel Linux prima che si verifichi un crash. A tal fine, all’avvio del kernel normale viene riservata un’area di memoria. In quest’area viene creato un file separato Kernel di acquisizione caricato, che può essere avviato tramite kexec in caso di un evento di crash appropriato.

Il kernel di acquisizione funziona indipendentemente dal kernel di sistema che si è bloccato e accede alla sua immagine di memoria tramite /proc/vmcore. Può salvare questa immagine su una destinazione configurata. Il file salvato viene solitamente denominato vmcore; il fatto che contenga tutte le aree di memoria originali dipende, tra l’altro, dal filtro selezionato.

I compiti sono distinti: kdump rileva e salva lo stato, mentre il programma incidente si analizza successivamente un dump esistente. Ciò consente, ad esempio, di esaminare i messaggi del kernel e le code delle attività. Un dump rappresenta un’istantanea e non fornisce automaticamente la cronologia completa dell’errore.

Un "oops" del kernel non è sinonimo di "panic" del kernel: un "oops" può verificarsi senza che il sistema entri immediatamente in stato di "panic". Pertanto, non tutti i malfunzionamenti del kernel comportano la generazione di un file kdump. Un core dump di un'applicazione, invece, riguarda lo stato di un processo e non è un vmcore del kernel.

Questa preparazione è fondamentale per l'analisi successiva. Se al momento del crash non era stato preparato alcun kernel di cattura o non era stata salvata alcuna immagine, kdump non sarà in grado di ricostruire in un secondo momento lo stato della memoria andato perso. In tal caso, i log disponibili e gli altri dati diagnostici conservati dopo il riavvio costituiranno il punto di partenza.

Requisiti e limiti della registrazione

Chiarisci innanzitutto la distribuzione, la versione e l'architettura del server. Da questi fattori dipendono i nomi dei pacchetti, la gestione dei servizi, la configurazione di avvio e le destinazioni di archiviazione supportate. Per la configurazione, utilizza la documentazione relativa proprio a questa piattaforma, invece di combinare comandi provenienti da distribuzioni diverse; anche l'hardware e i driver installati influenzano i requisiti.

Il parametro di avvio crashkernel stabilisce la Prenotazione dello spazio di archiviazione per la registrazione dei crash. Quest’area non è disponibile per il normale funzionamento. Non è possibile stabilire un valore forfettario affidabile: orientati alle specifiche relative alla distribuzione, all’architettura e alla configurazione concreta e tieni conto dello spazio di memoria richiesto dal sistema di acquisizione.

La memoria riservata da sola non è sufficiente. Il kernel di acquisizione deve essere caricato e deve poter raggiungere la destinazione configurata. A tal fine, i driver e i componenti necessari devono essere disponibili nel suo ambiente; nel caso di una destinazione di rete, tra i prerequisiti figurano anche la connessione e la raggiungibilità del terminale remoto.

Prevedere una capacità sufficiente nella destinazione per le immagini previste e la loro archiviazione. La dimensione di un dump dipende, tra l’altro, dal contenuto della memoria e dal filtraggio. Una destinazione piena o non raggiungibile può impedire il backup, anche se la prenotazione è stata impostata correttamente.

Anche un'installazione preparata non garantisce un dump utilizzabile. Un "Oops" non provoca necessariamente un "Panic"; in caso di interruzione totale dell'alimentazione, il kernel di acquisizione non è più in grado di funzionare. Allo stesso modo, un grave errore hardware può impedirne l'avvio o la scrittura dell'immagine. L'acquisizione e l'obiettivo devono quindi essere considerati separatamente dalla causa effettiva dell'errore.

Quali file vengono presi in considerazione per l'analisi

Ai fini dell'analisi non conta solo il file di dump. Se possibile, conserva anche i file del kernel e i log correlati, in modo da poter confrontare lo stato al momento del crash con i messaggi e le modifiche. La seguente panoramica distingue l'immagine di memoria vera e propria dai file ausiliari che ne consentono l'analisi.

Questo è particolarmente importante vmlinux compatibile: L'architettura e la build esatta del kernel devono corrispondere a quelle del kernel del sistema che si è bloccato. Il kernel in esecuzione dopo il riavvio può essere un altro. L'output di uname -r sul server appena riavviato non è quindi sufficiente per selezionare il file corretto relativo al vecchio dump.

Utilizza inoltre una versione di crash compatibile con il kernel e il formato di dump. Se sono coinvolti driver esterni o aggiuntivi, tieni a disposizione anche i relativi file di modulo e le informazioni di debug. Se mancano simboli o se sono state filtrate pagine di memoria necessarie, l’analisi potrebbe risultare limitata; tali lacune devono essere riportate nella documentazione dei risultati.

Un vmcore può contenere informazioni riservate provenienti dalla memoria di lavoro. Limita pertanto l’accesso, proteggi la trasmissione e stabilisci i termini di conservazione e cancellazione. Prima di trasmettere un dump o log supplementari a un servizio di assistenza, verifica l’autorizzazione necessaria e l’ambito consentito.

Preparare kdump sul server

Il punto di partenza è costituito dalla distribuzione, dalla versione e dall'architettura del server. Controlla nella relativa documentazione quali pacchetti sono necessari per kdump e per il caricamento del kernel di acquisizione, nonché come configurare il servizio. Le istruzioni relative alle diverse distribuzioni non sono intercambiabili a piacere: i nomi dei pacchetti, la configurazione di avvio e gli strumenti di verifica possono variare.

La preparazione prevede l'uso dell'adeguato Prenotazione dello spazio di archiviazione tramite il parametro di avvio crashkernel. Scegli le dimensioni e, se necessario, altre impostazioni in base alle specifiche della piattaforma e dell'hardware in questione. La memoria riservata non è disponibile per il sistema in esecuzione normale; pertanto, specificare una dimensione universale sarebbe inutile quanto copiare senza verifica le impostazioni da un altro server.

Dopo aver configurato il boot in base alla piattaforma e, se necessario, aver riavviato il sistema, il seguente comando della shell in modalità lettura mostra i parametri del kernel attualmente in esecuzione. Cerca nell'output crashkernel. Una voce mostra l'impostazione specificata, ma non conferma né che sia stato caricato un kernel di acquisizione né che il salvataggio sia andato a buon fine.

cat /proc/cmdline

Su RHEL 9 puoi inoltre verificare lo stato utilizzando il seguente comando nella shell. Su altre distribuzioni, segui la procedura descritta nella documentazione relativa a ciascuna distribuzione. Un risultato positivo Messaggio di stato è un’indicazione importante della disponibilità, ma non sostituisce un test controllato dell’intero percorso di sicurezza.

kdumpctl status

Verifica inoltre che la destinazione prevista e i driver necessari siano disponibili nel sistema di acquisizione. Prendi nota delle impostazioni selezionate e del momento in cui è stata effettuata la verifica, in modo da poterle rivalutare in seguito a modifiche al kernel o all’infrastruttura. Prima dell’implementazione, dovresti verificare le impostazioni specifiche per la piattaforma di destinazione effettivamente utilizzata.

Selezionare l'obiettivo di backup e l'ambito del dump

Il sito Obiettivo di copertura deve essere accessibile durante l'acquisizione e disporre di spazio libero sufficiente. Una destinazione locale evita la dipendenza da una connessione di rete, ma richiede spazio di archiviazione utilizzabile sul server. Tieni inoltre presente che i vari dump archiviati e i relativi file di diagnostica possono occupare spazio.

RHEL 9 documenta, oltre alle destinazioni locali, anche quelle di rete tramite NFS o SSH. Ciò consente di archiviare il file separatamente dal server interessato; a tal fine, è necessario che la rete, la controparte e i componenti necessari nel sistema di acquisizione funzionino correttamente. Verifica le rispettive limitazioni della configurazione RHEL specifica, anziché equiparare la raggiungibilità in condizioni di funzionamento normale a quella nel sistema di acquisizione.

Con makedumpfile È possibile comprimere l'immagine e filtrarla in base ad aree di memoria selezionate. Filtraggio può consentire di risparmiare spazio di archiviazione e volume di trasmissione, ma elimina pagine che potrebbero risultare necessarie per un'analisi successiva. Adatta quindi l'ambito del dump alla diagnosi prevista e documenta i filtri utilizzati; il file più piccolo non è automaticamente il più utile.

Un file vmcore può contenere informazioni riservate provenienti dalla memoria di lavoro. Limita quindi l'accesso, proteggi la trasmissione e stabilisci per quanto tempo i file devono essere conservati e quando devono essere cancellati. Prima di trasmetterli a un servizio di assistenza, verifica che sia stata concessa l’autorizzazione necessaria; ciò vale anche per le copie archiviate separatamente.

Aprire un file vmcore esistente con crash

Per l'analisi successiva ti servirà il vmcore disponibile, compatibile con la build del kernel che si è bloccato e con l'architettura vmlinux con informazioni di debug nonché una versione di crash compatibile con il kernel e il formato di dump. Il kernel in esecuzione dopo un riavvio potrebbe essere diverso; pertanto, la sola indicazione della versione non consente di identificare in modo affidabile la build che ha subito il crash.

Il comando schematico riportato di seguito va eseguito nella shell standard del sistema di analisi. Sostituisci entrambi i percorsi con quelli dei file effettivamente presenti. Il comando apre un’immagine esistente per l’analisi; non genera alcun dump né configura kdump.

crash /pfad/zum/passenden/vmlinux /pfad/zum/vmcore

Dopo un avvio positivo, lavorerai al messaggio di errore, non più nella shell normale. Lì viene visualizzato log i messaggi del kernel disponibili. Cerca innanzitutto il messaggio di panico e i messaggi che lo precedono e lo seguono; i messaggi possono fornire un punto di partenza, ma non descrivono necessariamente la causa completa.

Con bt esamini lo stack del contesto di analisi corrente; bt -a Mostra gli stack delle attività attive sulle CPU. Confronta le catene di chiamata con i messaggi, invece di considerare un singolo frame come prova di colpa. A seconda dello stato e dell'entità del dump, potrebbero mancare alcune informazioni.

Nello stesso prompt è utile ps nella panoramica delle attività; kmem -i fornisce informazioni generali sulla memoria. Questa istantanea, di per sé, non dimostra né la presenza di una perdita di memoria né la causa della stessa. Se si desidera esaminare più approfonditamente un modulo coinvolto, potrebbero essere necessari anche i file del modulo e le informazioni di debug corrispondenti.

Classificare gli stack e le indicazioni di memoria

Se si verifica un "panic" in seguito alla modifica di un driver, annota innanzitutto l'ora, la build del kernel che ha subito il crash e i moduli coinvolti. Confronta queste informazioni con il log delle modifiche: è stato aggiornato solo il driver o è stato installato contemporaneamente anche un nuovo kernel? In questo modo potrai individuare quali modifiche sono rilevanti ai fini dell'analisi.

Continua a leggere con log i messaggi del kernel disponibili e analizzali con bt lo stack del contesto di analisi corrente. bt -a integra la visualizzazione delle attività attive delle CPU. Oltre al testo del panic, prendi nota anche dei messaggi che lo hanno preceduto; potrebbero fornire il contesto di un errore che si manifesterà in seguito.

A Telaio del driver La presenza nello stack è un indizio, ma non una prova di colpa. Ad esempio, un precedente danneggiamento della memoria potrebbe manifestarsi solo in una funzione del driver. Verifica quindi che i messaggi, i moduli coinvolti e il flusso di esecuzione coincidano, prima di individuare una modifica come causa.

In caso di sospetto di occultamento, fornisce kmem -i una panoramica delle informazioni sulla memoria, nella misura in cui il dump e lo strumento le mettono a disposizione. Considera questi valori insieme ai messaggi del kernel. Un singolo valore non è di per sé prova né di una perdita di memoria né della sua causa; inoltre, a causa dell'applicazione di filtri, potrebbero mancare alcune pagine di memoria necessarie.

Per capire se il consumo aumenta nel tempo, sono necessarie serie temporali aggiuntive. In caso di analisi separata del carico della CPU, è possibile Profilazione della CPU con lo strumento Perf di Linux aiutare. Tali misurazioni integrano il crash dump, ma non sostituiscono lo stato in esso registrato al momento del crash.

Se non è disponibile un vmcore utilizzabile

Dopo un blocco seguito da un riavvio, occorre innanzitutto verificare se si sia effettivamente verificato un “panic” e se sia stato salvato un file vmcore. Il riavvio di per sé non è sufficiente a confermare né l’uno né l’altro. Cerca i messaggi relativi a quel momento e controlla la posizione di salvataggio configurata prima di dedurre un errore specifico dalla mancanza di un file.

Esamina il Catena di registrazione A parte questo: sul sistema in questione era stato caricato un kernel di acquisizione e l'evento era tale da attivare kdump? Non tutti gli "oops" provocano un "panic". Inoltre, un'interruzione totale dell'alimentazione o un grave errore hardware possono impedire l'avvio del kernel di acquisizione o la scrittura dei dati.

Verifica quindi la destinazione del backup: era raggiungibile, c’era spazio sufficiente a disposizione e il sistema di acquisizione conteneva i driver e i componenti necessari? Nel caso di una destinazione di rete, si aggiungono come dipendenze la connessione e il terminale remoto. Su RHEL, il file kexec-dmesg.log Fornire indicazioni sulla fase di registrazione, qualora sia stata creata e salvata.

In assenza di un dump utilizzabile, i log precedenti o i messaggi persistenti della console e del kernel rappresentano alternative importanti. Tuttavia, queste fonti non forniscono un’immagine completa della memoria; lo stato perso non può essere ricostruito a posteriori con kdump.

Se le segnalazioni o altre osservazioni indicano la presenza di problemi di rete, è possibile effettuare un'ulteriore Analisi dell'utilizzo degli SoftIRQ in Linux aiutare a classificare l'elaborazione dei pacchetti. Risponde a una domanda diversa rispetto alla verifica della destinazione del dump e di per sé non dimostra né la presenza di un panico né la causa di un backup fallito.

Verificare la registrazione e confermare i risultati

Scegli l'ambito del dump in base alla domanda diagnostica prevista e alle risorse disponibili. La compressione e il filtraggio possono consentire di risparmiare spazio di archiviazione e volume di trasmissione; tuttavia, le pagine di memoria rimosse non saranno più disponibili per analisi successive. Documenta questa decisione, in modo che durante l'analisi sia chiaro quali dati potrebbero mancare.

Un file vmcore può contenere informazioni riservate presenti in memoria. Regola pertanto l'accesso, la trasmissione protetta e il periodo di conservazione, nonché l'archiviazione dei relativi file di debug. Prima di trasmettere il file a un servizio di assistenza, verifica l'autorizzazione necessaria e le modalità previste per il trattamento dei dati.

Verifica nuovamente la configurazione qualora si verifichino modifiche al kernel, ai driver, alla configurazione di avvio o all’infrastruttura di backup. Ciò include il kernel di acquisizione caricato e la raggiungibilità della destinazione selezionata. Un messaggio di stato positivo è utile, ma di per sé non indica se, nelle condizioni attuali, venga effettivamente generato un dump analizzabile.

Avviso: Un test end-to-end controllato provoca intenzionalmente un arresto anomalo e può causare riavvii e perdita di dati. Eseguirlo solo in un ambiente di test autorizzato o in una finestra di manutenzione predisposta con backup dei dati. Chiarire in anticipo le responsabilità, le conseguenze e la procedura di ripristino; a tal fine, il comando di attivazione non è stato volutamente specificato.

Un indicatore significativo Test end-to-end Non limitarti alla verifica dello stato: controlla se il file è stato consegnato alla destinazione prevista e se è possibile aprirlo con i file corrispondenti alla build registrata. Durante il debug del server, registra quindi i risultati, i dati mancanti, le incertezze e i passi successivi da verificare. Distingui chiaramente gli indizi osservati dalle cause non ancora confermate.