Raccolta dei crash dump mediante l'utilità Kdump
Quando un sistema Oracle Linux si verifica un kernel panic e si blocca o si blocca in modo imprevisto, le informazioni sullo stato del sistema e sulle chiamate del kernel che portano al crash possono essere utili per la risoluzione dei problemi. La funzione Kdump fornisce un meccanismo di dump per le informazioni sul crash del kernel. Nelle immagini della piattaforma di Oracle Linux, il sistema operativo è completamente configurato o parzialmente configurato per generare un crash dump, a seconda della data di rilascio dell'immagine.
Se si dispone di una propria immagine Linux o di un marketplace, è necessario installare e configurare Kdump utilizzando la riga di comando.
Kdump include un secondo kernel, che risiede in una parte riservata della memoria di sistema, in modo che possa acquisire informazioni su un kernel arrestato. Kdump utilizza la chiamata di sistema kexec per eseguire il boot nel secondo kernel, denominato capture kernel, senza dover eseguire il reboot del sistema, quindi acquisisce il contenuto della memoria del kernel arrestato come crash dump. Per ulteriori informazioni sul contenuto di un crash dump, vedere What's Inside a Linux Kernel Core Dump.
/var/oled/crash/<ip-address>-<YYYY-MM-DD>-<HH:MM:SS>
per impostazione predefinita. Per ogni crash dump viene creata una nuova directory <ip-address>-<YYYY-MM-DD>-<HH:MM:SS>
, ad esempio: [opc@<instance_name> crash] ls -a
127.0.0.1-2025-02-07-15:18:07
127.0.0.1-2025-02-07-16:28:19
La directory di dump contiene il file di crash dump, vmcore
, un file di testo e un file di log, ad esempio:[opc@<instance_name> <127.0.0.1-2025-02-07-16:28:19>] ls -a
vmcore
vmcore-dmesg.txt
kexec-dmesg.log
Se si dispone di un'istanza di Oracle Linux non raggiungibile o che non risponde, è possibile inviare un interrupt diagnostico per la risoluzione dei problemi. Un interrupt diagnostico causa l'arresto anomalo e il riavvio del sistema operativo dell'istanza. Per utilizzare la console o l'API per inviare un interrupt diagnostico, è necessario configurare Kdump per generare un crash dump. Per ulteriori informazioni, vedere Invio di un interrupt diagnostico.
Impostazione della memoria riservata per un crash dump
Se si utilizza un'immagine della piattaforma Oracle Linux, Kdump viene installato e configurato completamente o parzialmente. È possibile modificare la quantità di memoria riservata nel kernel per salvare il crash dump, anche denominato riserva di memoria crashkernel. In Oracle Linux 8 e versioni precedenti, l'assegnazione di memoria predefinita è impostata per la regolazione automatica: GRUB_CMDLINE_LINUX="crashkernel=auto"
. Tuttavia, crashkernel=auto
non è supportato per Oracle Linux 9, pertanto è necessario impostare una quantità specifica di memoria riservata utilizzando il parametro crashkernel
.
Per impostare la riserva di memoria per un crash dump:
- Da una riga di comando, utilizzando i privilegi amministrativi, connettersi all'istanza utilizzando SSH.
- Modificare il file
/etc/default/grub
per impostare la memoria riservata. Ad esempio:- Impostare la riserva di memoria su 64 MB, ad esempio:
GRUB_CMDLINE_LINUX="crashkernel=
64MB
" - Impostare la quantità di memoria riservata come variabile utilizzando la sintassi
crashkernel=<range1>:<size1>,<range2>:<size2>
. Ad esempio:GRUB_CMDLINE_LINUX="crashkernel=512M-2G:64M,2G-:128M"
- Definire un valore di offset per la memoria riservata. Poiché la prenotazione
crashkernel
si verifica nelle prime fasi del processo di boot, alcuni sistemi richiedono di riservare memoria con un determinato offset fisso. Quando viene specificato un offset fisso, la memoria riservata inizia a quel punto. Ad esempio, per riservare 128 MB di memoria, a partire da 16 MB:GRUB_CMDLINE_LINUX="crashkernel=128M@16M"
- Impostare la riserva di memoria su 64 MB, ad esempio:
- Salvare le modifiche e aggiornare la configurazione di grub:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
- Riavviare l'istanza per applicare le modifiche.
Modifica della posizione di crash dump
Utilizzando /etc/kdump.conf
, è possibile modificare la posizione in cui vengono salvati i file di crash dump, trasferirli tramite SSH o esportarli in una condivisione di rete.
- Da una riga di comando, utilizzando i privilegi amministrativi, connettersi all'istanza utilizzando SSH.
- Modificare il file di configurazione in
/etc/kdump.conf
e rimuovere il carattere di commento#
all'inizio di ogni riga che si desidera abilitare.- Spostarsi nella directory predefinita (
/var/oled/crash
) dei file di crash dump, ad esempio:path /usr/local/<cores>
- Trasferire i file di crash dump su una connessione shell sicura, ad esempio:
ssh <user@example.com> sshkey /root/.ssh/<mykey>
- Impostare i file di crash dump da esportare in una condivisione di rete compatibile, ad esempio:
nfs <example.com>:/<output>
Per ulteriori informazioni, vedere il file
kdump.conf.5
nell'archivio/usr/share/man/man5/kdump.conf.5.gz
. - Spostarsi nella directory predefinita (
- Al termine, salvare le modifiche e riavviare il servizio
kdump
.sudo systemctl restart kdump.service
- Riavviare l'istanza per applicare le modifiche.
Modifica dello stato di errore predefinito
Per impostazione predefinita, se Kdump non riesce a inviare il risultato alle posizioni di output configurate, riavvia il server. Questa azione elimina tutti i dati raccolti per il dump. Per evitare questo risultato, modificare la configurazione di Kdump.
- Da una riga di comando, utilizzando i privilegi amministrativi, connettersi all'istanza utilizzando SSH.
- Modificare
/etc/kdump.conf
per annullare il commento e modificare il valoredefault
nel file come indicato di seguito.default dump_to_rootfs
L'opzione
dump_to_rootfs
consente di salvare il risultato in una directory locale, utile se non è possibile raggiungere una condivisione di rete. È invece possibile utilizzareshell
per copiare manualmente i dati dalla riga di comando.Nota
Le opzioni
poweroff
,restart
ehalt
sono valide anche per lo stato di errorekdump
predefinito. Tuttavia, l'esecuzione di queste azioni comporta la perdita dei dati raccolti se tali azioni vengono eseguite. Per ulteriori informazioni, vedere il filekdump.conf.5
nell'archivio/usr/share/man/man5/kdump.conf.5.gz
. - Al termine, salvare le modifiche e riavviare il servizio
kdump
.sudo systemctl restart kdump.service
- Riavviare l'istanza per applicare le modifiche.
Attivazione di un crash dump
Eseguire il test della configurazione Kdump arrestando il kernel che attiva il servizio per raccogliere un crash dump. Quindi, rivedere il crash dump.
- Da una riga di comando, utilizzando i privilegi amministrativi, connettersi all'istanza utilizzando SSH.
- Assicurarsi che Kdump sia in esecuzione:
systemctl is-active kdump
- Avviare il crash dalla console o dalla riga di comando:In questo modo il kernel viene bloccato e i file di dump vengono copiati nella directory
echo 1 > /proc/sys/kernel/sysrq echo c > /proc/sysrq-trigger
/var/oled/crash/<ip-address>-<YYYY-MM-DD>-<HH:MM:SS>
, per impostazione predefinita, o nella posizione selezionata nella configurazione. - Riavviare l'istanza.
- Riconnettersi all'istanza utilizzando SSH ed esaminare i file di crash dump nel file
/var/oled/crash/<ip-address>-<YYYY-MM-DD>-<HH:MM:SS>
:- Il buffer dei messaggi del kernel include le informazioni più essenziali sul crash di sistema e viene sempre scaricato per primo nel file
vmcore-dmesg.txt
. Ciò è utile quando un tentativo di ottenere il filevmcore
completo non riesce, ad esempio a causa della mancanza di spazio nella posizione di destinazione. - Quando lo strumento
kexec
viene avviato nel secondo kernel e acquisisce il contenuto della memoria del kernel bloccato, scrive anche nel filekexec-dmes.log
in modo da poter tracciare il processo. Ad esempio, alla fine del file è possibile visualizzare il processo di salvataggio del crash dump:... Feb 07 16:28:19 linux9 systemd[1]: Starting Kdump Vmcore Save Service... Feb 07 16:28:19 linux9 kdump[504]: Kdump is using the default log level(3). Feb 07 16:28:19 linux9 kdump[541]: saving to /kdumproot/var/oled/crash/127.0.0.1-2025-02-07-16:28:19/ Feb 07 16:28:19 linux9 kdump[546]: saving vmcore-dmesg.txt to /kdumproot/var/oled/crash/127.0.0.1-2025-02-07-16:28:19/ Feb 07 16:28:19 linux9 kdump[552]: saving vmcore-dmesg.txt complete Feb 07 16:28:19 linux9 kdump[554]: saving vmcore Feb 07 16:28:21 linux9 kdump.sh[555]: Checking for memory holes : [ 0.0 %] / ... Copying data : [100.0 %] \ eta: 0s Feb 07 16:28:21 linux9 kdump.sh[555]: The dumpfile is saved to /kdumproot/var/oled/crash/127.0.0.1-2025-02-07-16:28:19//vmcore-incomplete. Feb 07 16:28:21 linux9 kdump.sh[555]: makedumpfile Completed. Feb 07 16:28:21 linux9 kdump[559]: saving vmcore complete Feb 07 16:28:21 linux9 kdump[561]: saving the /run/initramfs/kexec-dmesg.log to /kdumproot/var/oled/crash/127.0.0.1-2025-02-07-16:28:19//
- Il file
vmcore
contiene le informazioni sul crash dump. Per analizzare il crash dump, è necessaria una utility in grado di leggere il formato del filevmcore
. Per informazioni sull'uso della utilitycrash
, vedere Analisi dei crash dump.
- Il buffer dei messaggi del kernel include le informazioni più essenziali sul crash di sistema e viene sempre scaricato per primo nel file
Analisi dei crash dump
È possibile utilizzare la utility crash
per analizzare i crash dump raccolti da Kdump. Nelle immagini della piattaforma Oracle Linux, crash
viene installato per impostazione predefinita. Per altre istanze Linux, utilizzare la riga di comando per installarla: sudo dnf install crash
.
Configurare un'istanza di Oracle Linux per utilizzare la utility di arresto anomalo
Per analizzare un crash dump con crash
, completare le attività di configurazione indicate di seguito.
- Da una riga di comando, utilizzare i privilegi amministrativi e connettersi all'istanza utilizzando SSH.
- Abilitare il repository
debuginfo
di Oracle Linux creando il file/etc/yum.repos.d/debuginfo.repo
con privilegi root e i seguenti contenuti, ad esempio:[debuginfo] name=Oracle Linux 8 Debuginfo Packages baseurl=https://oss.oracle.com/ol8/debuginfo/ gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle gpgcheck=1 enabled=1
- Aggiornare il sistema:
sudo dnf update -y
- Installare il pacchetto
kernel-uek-debuginfo
:sudo dnf install -y kernel-uek-debuginfo-$(uname -r)
Importante
Eseguire il comando di installazione ogni volta che il kernel viene aggiornato tramite Package Manager. Il pacchettodebuginfo
funziona solo quando corrisponde al kernel in esecuzione e non viene sostituito automaticamente quando sul sistema è installata una versione più recente del kernel.
Analizzare un crash dump utilizzando l'utilità di crash
Per analizzare un crash dump, fornire le informazioni su vmcore
a crash
, quindi utilizzare le opzioni della shell crash
per recuperare le informazioni sul crash dump. Per informazioni dettagliate sull'uso della utility crash, digitare man crash
al prompt dei comandi o consultare la documentazione relativa al crash.
- Da una riga di comando, utilizzare i privilegi amministrativi e connettersi all'istanza utilizzando SSH.
- Fornire la posizione del modulo
debuginfo
del kernel e la posizione del dump core come parametri della utility crash, ad esempio:sudo crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/oled/crash/<ip-address>-<YYYY-MM-DD>-<HH:MM:SS>/vmcore
$(uname -r) identifica la versione del kernel in esecuzione nel comando,
<ip-address>-<YYYY-MM-DD>-<HH:MM:SS>
rappresenta la directory creata per i file di crash dump e il filevmcore
contiene il crash dump.La shell
crash
avvia e visualizza alcune informazioni sul crash di sistema, ad esempio:KERNEL: /usr/lib/debug/lib/modules/5.15.0-302.167.6.el9uek.x86_64/vmlinux DUMPFILE: /var/oled/crash/127.0.0.1-2025-02-07-16:28:19/vmcore [PARTIAL DUMP] CPUS: 2 DATE: Fri Feb 7 16:28:15 GMT 2025 UPTIME: 01:09:58 LOAD AVERAGE: 0.00, 0.02, 0.00 TASKS: 204 NODENAME: oci-linux9 RELEASE: 5.15.0-302.167.6.el9uek.x86_64 VERSION: #2 SMP Mon Nov 4 23:41:59 PST 2024 MACHINE: x86_64 (2445 Mhz) MEMORY: 16 GB PANIC: "Kernel panic - not syncing: NMI: Not continuing" PID: 0 COMMAND: "swapper/0" TASK: ffffffffb761a980 (1 of 2) [THREAD_INFO: ffffffffb761a980] CPU: 0 STATE: TASK_RUNNING (PANIC) crash>
- Al prompt
crash
, immettere un'opzione per ottenere maggiori informazioni sul crash dump, ad esempio:bt -a
visualizza uno stack trace dei task attivi quando si verifica un errore grave nel kernel, ad esempio:crash> bt -a PID: 286 TASK: c0b3a000 CPU: 0 COMMAND: "in.rlogind" #0 [c0b3be90] crash_save_current_state at c011aed0 #1 [c0b3bea4] panic at c011367c #2 [c0b3bee8] tulip_interrupt at c01bc820 #3 [c0b3bf08] handle_IRQ_event at c010a551 #4 [c0b3bf2c] do_8259A_IRQ at c010a319 #5 [c0b3bf3c] do_IRQ at c010a653 #6 [c0b3bfbc] ret_from_intr at c0109634 EAX: 00000000 EBX: c0e68280 ECX: 00000000 EDX: 00000004 EBP: c0b3bfbc DS: 0018 ESI: 00000004 ES: 0018 EDI: c0e68284 CS: 0010 EIP: c012f803 ERR: ffffff09 EFLAGS: 00000246 #7 [c0b3bfbc] sys_select at c012f803 #8 [c0b3bfc0] system_call at c0109598 EAX: 0000008e EBX: 00000004 ECX: bfffc9a0 EDX: 00000000 DS: 002b ESI: bfffc8a0 ES: 002b EDI: 00000000 SS: 002b ESP: bfffc82c EBP: bfffd224 CS: 0023 EIP: 400d032e ERR: 0000008e EFLAGS: 00000246
ps -A
visualizza solo il task attivo su ogni CPU, ad esempio:crash> ps -A PID PPID CPU TASK ST %MEM VSZ RSS COMM > 10 2 1 ffff880212969710 IN 0.0 0 0 [migration/1] > 0 0 3 ffff884026d43520 RU 0.0 0 0 [swapper] > 6582 1 2 ffff880f49c52040 RU 0.0 42202472 33368 oracle > 9497 1 0 ffff880549ec2ab0 RU 0.0 42314692 138664 oracle
vm
visualizza le informazioni di base sulla memoria virtuale del contesto corrente, ad esempio:crash> vm PID: 30986 TASK: c0440000 CPU: 0 COMMAND: "bash" MM PGD RSS TOTAL_VM c303fe20 c4789000 88k 1728k VMA START END FLAGS FILE c0d1f540 8048000 80ad000 1875 /bin/bash c0d1f400 80ad000 80b3000 1873 /bin/bash c0d1f880 80b3000 80ec000 77 c0d1f0c0 40000000 40012000 875 /lib/ld-2.1.1.so c0d1f700 40012000 40013000 873 /lib/ld-2.1.1.so c0d1fe00 40013000 40014000 77 c0d1f580 40014000 40016000 73 ...
files
visualizza informazioni sui file aperti nel contesto corrente.crash> files PID: 720 TASK: c67f2000 CPU: 1 COMMAND: "innd" ROOT: / CWD: /var/spool/news/articles FD FILE DENTRY INODE TYPE PATH 0 c6b9c740 c7cc45a0 c7c939e0 CHR /dev/null 1 c6b9c800 c537bb20 c54d0000 REG /var/log/news/news 2 c6df9600 c537b420 c5c36360 REG /var/log/news/errlog 3 c74182c0 c6ede260 c6da3d40 PIPE 4 c6df9720 c696c620 c69398c0 SOCK 5 c6b9cc20 c68e7000 c6938d80 SOCK 6 c6b9c920 c7cc45a0 c7c939e0 CHR /dev/null 7 c6b9c680 c58fa5c0 c58a1200 REG /var/lib/news/history 8 c6df9f00 c6ede760 c6da3200 PIPE
kmem -i
visualizza le informazioni sull'uso della memoria del kernel, ad esempio:crash> kmem -i PAGES TOTAL PERCENTAGE TOTAL MEM 1974231 7.5 GB ---- FREE 208962 816.3 MB 10% of TOTAL MEM USED 1765269 6.7 GB 89% of TOTAL MEM SHARED 365066 1.4 GB 18% of TOTAL MEM BUFFERS 111376 435.1 MB 5% of TOTAL MEM CACHED 1276196 4.9 GB 64% of TOTAL MEM SLAB 120410 470.4 MB 6% of TOTAL MEM TOTAL HUGE 524288 2 GB ---- HUGE FREE 524288 2 GB 100% of TOTAL HUGE TOTAL SWAP 2498559 9.5 GB ---- SWAP USED 81978 320.2 MB 3% of TOTAL SWAP SWAP FREE 2416581 9.2 GB 96% of TOTAL SWAP COMMIT LIMIT 3485674 13.3 GB ---- COMMITTED 850651 3.2 GB 24% of TOTAL LIMIT
- Una volta completata l'analisi del dump di base, uscire dalla shell digitando exit o q.