Cum analizezi un kernel panic în Linux: kdump, crash și interpretarea unui vmcore

Un kernel panic nu este același lucru cu blocarea unei aplicații. Kernelul ajunge într-o stare din care nu mai poate continua în siguranță, iar serverul se oprește sau repornește. Logurile pot oferi indicii, dar pentru o analiză serioasă ai nevoie de imaginea memoriei din momentul incidentului: fișierul vmcore.

kdump folosește kexec pentru a porni un al doilea kernel, rezervat capturării. Memoria kernelului prăbușit este păstrată, apoi kernelul de captură o salvează local sau pe o destinație de rețea. Fără această configurare făcută înaintea incidentului, nu poți reconstrui ulterior un vmcore complet.

Confirmă că mecanismul kdump era pregătit

După repornirea serverului, verifică parametrii de boot și memoria rezervată:

uname -r
cat /proc/cmdline
dmesg | grep -i crashkernel

Parametrul crashkernel rezervă memoria în care este încărcat kernelul de captură. Verifică și serviciul potrivit distribuției:

systemctl status kdump
systemctl status kdump-tools

Primul nume este întâlnit în special pe RHEL, Rocky Linux și AlmaLinux, iar al doilea pe Ubuntu și Debian.

Caută fișierele rezultate:

sudo find /var/crash -maxdepth 3 -type f \
  \( -name vmcore -o -name 'vmcore-dmesg.txt' \) -ls

Tratează vmcore ca pe un fișier sensibil. Acesta conține pagini din memoria sistemului și poate include fragmente aparținând proceselor, aplicațiilor și sesiunilor active.

Adună artefactele corecte

Pentru o analiză completă ai nevoie de:

vmcore
vmlinux cu simboluri de depanare
versiunea exactă a kernelului prăbușit
modulele și informațiile sistemului afectat

Fișierul vmlinux trebuie să corespundă exact kernelului capturat în dump. Nu folosi automat simbolurile kernelului pornit după incident dacă între timp serverul a primit actualizări.

Pe sistemele RHEL-like, simbolurile sunt furnizate de pachetul kernel-debuginfo. Documentația Red Hat arată că utilitarul crash trebuie pornit cu imaginea vmlinux corespunzătoare și cu fișierul vmcore.

Verifică artefactele:

file /var/crash/INCIDENT/vmcore
ls -lh /var/crash/INCIDENT/

Analiza ar trebui făcută pe o copie, ideal pe alt sistem, nu direct pe serverul afectat.

Extrage rapid mesajele kernelului

Înainte să deschizi sesiunea interactivă, extrage bufferul kernelului:

makedumpfile --dump-dmesg \
  /var/crash/INCIDENT/vmcore \
  incident-dmesg.txt

Această utilizare a opțiunii --dump-dmesg este documentată pentru extragerea mesajelor kernelului dintr-un dump.

Caută evenimente relevante:

grep -iE \
'panic|oops|bug:|watchdog|soft lockup|hard lockup|out of memory|I/O error' \
incident-dmesg.txt

Nu te limita la ultima linie. Mesajul final despre panică poate fi doar consecința unei probleme anterioare: un CPU blocat, o eroare de I/O, o dereferențiere invalidă, coruperea memoriei sau un modul defect.

Deschide vmcore cu crash

Pornește utilitarul folosind calea reală către simbolurile kernelului:

sudo crash \
  /cale/catre/vmlinux-cu-debug \
  /var/crash/INCIDENT/vmcore

crash combină analiza specifică kernelului cu funcționalități GDB și poate investiga dump-uri produse de kdump sau procesate cu makedumpfile.

Dacă primești o eroare privind nepotrivirea simbolurilor, oprește analiza și verifică versiunea kernelului, arhitectura și pachetul de debug. Simbolurile greșite pot produce stack trace-uri înșelătoare.

În promptul crash, începe cu:

sys
log
bt
ps
kmem -i
mod

sys afișează kernelul, uptime-ul și informațiile generale. log arată bufferul kernelului. bt prezintă backtrace-ul contextului panicii și este, de regulă, prima comandă importantă. ps afișează taskurile, iar mod listează modulele încărcate.

Pentru un proces suspect:

task PID
bt PID
files PID

Caută prima funcție relevantă înaintea cadrelor generice precum panic sau mecanismele de excepție. Dacă apare un modul extern, verifică versiunea și furnizorul lui. Simplul fapt că modulul apare în stack nu demonstrează că el este cauza.

Scrie concluzia fără presupuneri

Raportul final trebuie să includă kernelul exact, ora incidentului, mesajul panicii, stack trace-ul principal, procesul activ, modulele implicate și evenimentele care au precedat oprirea.

Separă observațiile confirmate de ipoteze. Un raport bun spune „stack-ul indică funcția X din modulul Y”, nu „modulul Y a provocat sigur incidentul” fără dovezi suplimentare.

Testează kdump numai într-o mașină virtuală sau într-o fereastră de mentenanță aprobată. Testarea mecanismului poate provoca intenționat un kernel panic și nu trebuie făcută pe producție fără backup, acces la consolă și un plan de revenire.

Surse folosite

Linux Kernel Documentation — Kdump, kexec, crashkernel și capturarea vmcore.

Crash Utility — utilizarea crash, cerințele pentru vmlinux și comenzile principale de analiză.

Red Hat Enterprise Linux 10 Documentation — analiza unui core dump și potrivirea simbolurilor de debug.

Debian Manpages — extragerea mesajelor kernelului cu makedumpfile --dump-dmesg.