Analiza kernel panic în 2026: Citirea core dump-ului pentru a găsi cauza reală

Un kernel panic este o eroare fatală de sistem din care kernelul Linux nu se poate recupera în siguranță. Când se întâmplă acest lucru, sistemul de operare oprește orice execuție pentru a preveni coruperea datelor. Singura modalitate de a găsi cauza reală a unui kernel panic este citirea fișierului core dump generat exact în momentul crash-ului. A ghici cauza pe baza logurilor de sistem sau a graficelor de monitorizare este o pierdere absolută de timp, deoarece procesele daemon de logging se opresc în secunda în care kernelul dă halt.

Din experiența noastră în administrarea serverelor de producție, administratorii presupun adesea că un restart aleatoriu a fost cauzat de o defecțiune hardware. Ei înlocuiesc module RAM, migrează mașini virtuale sau refac întregi stack-uri fără nicio dovadă. Un core dump îți oferă exact instruction pointer-ul, procesul care rula pe CPU și conținutul memoriei de sistem la milisecunda în care a avut loc eroarea. Citirea acestui dump transformă un downtime imprevizibil într-un bug clar, software sau hardware, pe care îl poți repara.

Mecanismele din spatele kernel panic și kdump

Când kernelul Linux detectează o eroare internă irecuperabilă, apelează funcția panic(). Această funcție afișează un mesaj de eroare pe consolă, face flush la bufferele de disc dacă subsistemul de stocare este încă considerat stabil și oprește procesorul. Logurile de sistem din /var/log/syslog sau /var/log/messages nu vor conține detaliile crash-ului, deoarece serviciul syslog se bazează pe kernel pentru a scrie pe disk. Odată ce intră în panică, kernelul nu se mai poate baza pe propriile drivere de filesystem.

Pentru a capta starea mașinii, Linux folosește un mecanism numit kexec. Acesta permite unui kernel blocat să booteze un kernel secundar de captură, direct din memorie, fără a mai trece prin secvența de boot hardware BIOS sau UEFI. Acest kernel secundar rulează într-o zonă izolată și rezervată de RAM. Singura sa sarcină este să monteze sistemul de fișiere, să copieze starea memoriei kernelului blocat într-un fișier numit vmcore, iar apoi să declanșeze un restart normal.

Întregul proces se bazează pe serviciul kdump. Dacă kdump nu este configurat și pornit înainte să aibă loc eroarea, starea memoriei este pierdută pentru totdeauna la restart. Pe serverele virtuale dedicate KVM, cum ar fi planul vm.Ready, ai control complet asupra kernelului și poți aloca memoria necesară pentru kdump. În mediile partajate bazate pe containere (LXC), nu poți declanșa sau face debug pe un kernel panic, deoarece containerul partajează kernelul host-ului. Nodul gazdă se protejează singur de erorile de kernel provocate de alți clienți (tenants).

Configurarea kdump pe serverele de producție

Înainte de a putea analiza un crash, trebuie să configurezi serverul pentru a-l capta. Primul pas este rezervarea memoriei pentru kernelul de crash în configurația bootloader-ului. Trebuie să editezi fișierul de configurare GRUB și să adaugi parametrul crashkernel la argumentele liniei de comandă.

Deschide /etc/default/grub în editorul de text preferat. Caută linia care începe cu GRUB_CMDLINE_LINUX_DEFAULT. Trebuie să adaugi crashkernel=auto pentru sistemele bazate pe RHEL sau să specifici o alocare exactă de memorie pentru sistemele Debian și Ubuntu. O valoare implicită sigură pentru serverele moderne cu peste 4GB de RAM este alocarea a 256MB.

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash crashkernel=256M"

După modificarea fișierului, actualizează bootloader-ul. Pe Debian sau Ubuntu, execută update-grub. Pe RHEL, AlmaLinux sau CentOS, rulează grub2-mkconfig -o /boot/grub2/grub.cfg. Trebuie să dai restart la server pentru ca noul kernel să rezerve acest bloc de memorie.

Odată ce serverul este din nou online, instalează instrumentele kdump. Pe distribuțiile derivate din Debian, instalează pachetul kdump-tools. Pe sistemele bazate pe RHEL, instalează kexec-tools. Activează și pornește serviciul folosind systemctl enable kdump urmat de systemctl start kdump. Poți verifica rezervarea memoriei citind linia de comandă a kernelului din /proc/cmdline sau verificând statusul serviciului.

Pentru a te asigura că sistemul chiar captează un dump în timpul unui kernel panic, ar trebui să îl testezi. Poți declanșa manual un kernel panic folosind secvența de taste magice SysRq. Asigură-te că nu faci asta pe un server care deservește activ trafic de producție. Executarea următoarei comenzi ca root va da crash imediat serverului și va forța crearea unui dump.

echo c > /proc/sysrq-trigger

Serverul va întrerupe conexiunile SSH, se va restarta și va boota înapoi în kernelul principal. După ce redevine online, navighează în /var/crash/. Vei găsi un director marcat cu data și ora exactă a crash-ului, care conține fișierul vmcore și output-ul dmesg.

Pregătirea mediului de analiză

Un fișier vmcore este o copie binară brută a memoriei RAM a sistemului. Nu îl poți citi cu un editor de text. Ai nevoie de utilitarul crash și de simbolurile de debug (debug symbols) exacte pentru versiunea de kernel care a dat crash. Utilitarul crash traduce adresele brute de memorie în nume de funcții, variabile și stack trace-uri lizibile.

Mai întâi, verifică versiunea exactă de kernel care a generat dump-ul. Aceasta este adesea diferită de kernelul curent dacă a avut loc un update automat în timpul restartului. Citește fișierul dmesg.txt generat împreună cu vmcore pentru a găsi string-ul versiunii de kernel. Apoi, instalează pachetul crash folosind managerul de pachete al distribuției tale.

Trebuie să descarci pachetele debuginfo corespunzătoare kernelului blocat. Pe Ubuntu, trebuie să adaugi repository-ul de simboluri de debug (ddebs) în sursele APT și să instalezi linux-image-$(uname -r)-dbgsym. Pe AlmaLinux sau RHEL, activezi repository-ul de debug și instalezi kernel-debuginfo. Aceste pachete sunt enorme, depășind adesea câțiva gigabytes, deoarece conțin binarul vmlinux unstripped, care mapează fiecare linie a codului sursă din kernel la offset-ul său exact de memorie.

Dacă gestionezi infrastructura la un furnizor unmanaged, păstrarea acestor pachete de debug consumă spațiu prețios pe disc. Pentru administratorii care preferă să se concentreze pe aplicații în loc de debugging-ul pe kernel, o abordare managed a infrastructurii preia această povară. În centrele noastre de date, administratorii de sistem se ocupă direct de mentenanța hypervisorului KVM (motiv pentru care am explicat anterior de ce tehnologiile vechi de virtualizare sunt depășite), oferindu-ți libertatea de a ignora diagnosticarea la nivel low-level.

Executarea utilitarului crash

Cu simbolurile de debug instalate și fișierul vmcore pregătit, lansezi utilitarul crash. Trebuie să furnizezi binarul unstripped vmlinux și fișierul vmcore ca argumente. Calea către fișierul vmlinux variază în funcție de distribuție, dar de obicei se află în /usr/lib/debug/lib/modules/ sau /usr/lib/debug/boot/.

crash /usr/lib/debug/lib/modules/5.15.0-100-generic/vmlinux /var/crash/202602251050/vmcore

Utilitarul încarcă simbolurile, mapează spațiul de memorie și te trimite într-un prompt interactiv. Output-ul inițial afișează contextul critic al sistemului. Vei vedea mesajul exact de kernel panic, uptime-ul serverului dinaintea crash-ului, load average-ul, numărul total de task-uri care rulau și ID-ul procesului (PID) care se executa pe procesor în momentul opririi.

Fii foarte atent la linia PANIC din acest output inițial. Mesajele tipice includ "Oops: 0000 [#1] SMP" pentru erori de memorie de tip page fault nepreluate, sau "Kernel panic - not syncing: out of memory" pentru epuizarea fatală a resurselor. Linia COMMAND îți spune numele executabilului care rula în momentul crash-ului. Deși procesul enumerat în COMMAND nu este întotdeauna cauza principală, el indică ce făcea CPU-ul atunci când starea kernelului a devenit invalidă.

Citirea stack trace-ului

Cea mai importantă comandă din interiorul utilitarului crash este bt (backtrace). Această comandă printează call stack-ul taskului activ. Stack trace-ul arată exact secvența de funcții C pe care kernelul o executa chiar până la momentul intrării în panică. Un stack trace se citește de jos în sus. Intrările de jos arată apelul inițial de sistem (system call) din user-space, iar intrările de sus arată funcția fatală din kernel.

crash> bt
PID: 14592  TASK: ffff888123456000  CPU: 2   COMMAND: "php-fpm"
 #0 [ffffc90001234b58] machine_kexec at ffffffff8105c3b1
 #1 [ffffc90001234bb0] __crash_kexec at ffffffff8110b252
 #2 [ffffc90001234c78] panic at ffffffff8166d123
 #3 [ffffc90001234cf8] oops_end at ffffffff81031f0d
 #4 [ffffc90001234d18] no_context at ffffffff8106f2d4
 #5 [ffffc90001234d70] __bad_area_nosemaphore at ffffffff8106f521
 #6 [ffffc90001234db8] bad_area_nosemaphore at ffffffff8106f574
 #7 [ffffc90001234dc8] __do_page_fault at ffffffff8106fbe8
 #8 [ffffc90001234e28] do_page_fault at ffffffff8106fdf2
 #9 [ffffc90001234e58] page_fault at ffffffff818018d5
    [exception RIP: ixgbe_clean_rx_irq+142]
#10 [ffffc90001234f08] ixgbe_poll at ffffffffa015b678 [ixgbe]
#11 [ffffc90001234f40] net_rx_action at ffffffff815617a1
#12 [ffffc90001234fb8] __do_softirq at ffffffff810a08e3

În acest output, poți urmări calea de execuție. La pasul 12, kernelul gestiona un software interrupt pentru traficul de rețea. La pasul 10, a apelat ixgbe_poll, care este driverul pentru o placă de rețea Intel 10 Gigabit. La pasul 9, a apărut un page fault în interiorul ixgbe_clean_rx_irq. Acest lucru înseamnă că driverul de rețea a încercat să acceseze o adresă de memorie care nu exista sau care era protejată. Kernelul a prins această accesare invalidă prin __do_page_fault, a determinat că eroarea este irecuperabilă și a declanșat secvența de panică începând cu pasul 2.

Linia marcată exception RIP reprezintă Instruction Pointer-ul. Acesta indică exact funcția în care a avut loc încălcarea. În centrele noastre de date din Salt Lake City și Beauharnois, folosim strict hardware enterprise pentru a evita bug-urile obscure din drivere. Cu toate acestea, când se implementează module de rețea personalizate pe servere unmanaged, întâlnirea unor null pointer dereferences în driverele de rețea este o problemă operațională frecventă. Upgrade-ul driverului specific sau al kernelului rezolvă de obicei această categorie de erori.

Identificarea erorilor hardware vs software

Un core dump poate face diferența clară între un bug software și o componentă hardware defectă. În interiorul utilitarului crash, rulează comanda log. Aceasta afișează kernel ring buffer-ul înregistrărilor care au condus la crash. Caută excepții de tip MCE (Machine Check Exceptions). Un MCE este o eroare hardware raportată direct de către procesor sistemului de operare.

Dacă logurile arată mesaje care conțin "Hardware Error" sau "Machine check events logged", acel kernel panic a fost doar un simptom secundar al unei defecțiuni fizice. S-ar putea să vezi erori legate de defecte de memorie ECC corectabile sau necorectabile. Noi echipăm infrastructura exclusiv cu procesoare Xeon și RAM ECC tocmai pentru a detecta și corecta erorile de tip single-bit. Dacă apare o eroare de memorie multi-bit, hardware-ul forțează intenționat un kernel panic pentru a opri sistemul de operare din a scrie date corupte pe disc.

Când core dump-ul indică o problemă hardware, nicio configurare software nu o va rezolva. Nodul fizic necesită înlocuirea componentelor. Dacă citești acest dump de pe un server bare-metal din propriul datacenter, trebuie să programezi o intervenție de mentenanță și să schimbi RAM-ul sau CPU-ul. Dacă operezi pe o mașină virtuală managed, furnizorul de hosting ar fi trebuit deja să prindă MCE-ul prin interfețele de management out-of-band și să fi migrat live instanța ta pe un alt nod.

Investigarea epuizării resurselor (OOM)

Mecanismul Out of Memory (OOM) killer este conceput pentru a închide procese cu scopul de a elibera RAM. În mod normal, OOM killer nu cauzează un kernel panic. El sacrifică un proces din user-space, cum ar fi PHP-FPM sau MySQL, pentru a menține sistemul în funcțiune. Cu toate acestea, administratorii modifică uneori greșit setările sysctl, forțând kernelul să dea panic în loc să invoce OOM killer-ul.

Poți verifica acest lucru în utilitarul crash examinând variabilele kernelului. Rulează comanda p sysctl_panic_on_oom. Dacă output-ul returnează valoarea 1, sistemul este configurat explicit să dea crash la epuizarea memoriei. Vei vedea de asemenea "Out of memory: Compacting and killing" urmat de un apel panic() în buffer-ul de log.

Ne întâlnim frecvent cu acest scenariu atunci când clienții migrează site-uri WordPress foarte mari pe servere virtuale entry-level. Pe un VPS cu 2GB de RAM care rulează WooCommerce, vei epuiza rapid workerii PHP și memoria RAM sub load. În loc să dai crash complet serverului, ar trebui să configurezi sistemul să-și gestioneze memoria corect, aspect pe care l-am detaliat în ghidul nostru pentru optimizarea VPS-urilor pentru WooCommerce. Pentru a repara această problemă specifică de OOM panic, editează /etc/sysctl.conf, setează vm.panic_on_oom = 0 și rulează sysctl -p.

Verificarea modulelor tainted

Kernelul Linux ține evidența faptului dacă drivere proprietare sau third-party nesuportate sunt încărcate în memorie. Acest lucru poartă denumirea de "tainted kernel". Un kernel panic apărut într-un kernel tainted este semnificativ mai greu de făcut debug, deoarece dezvoltatorii open-source nu pot analiza un cod sursă proprietar. În interiorul utilitarului crash, folosește comanda sys pentru a verifica statusul de taint.

crash> sys
      KERNEL: /usr/lib/debug/lib/modules/5.15.0-100-generic/vmlinux
    DUMPFILE: /var/crash/202602251050/vmcore
        CPUS: 4
        DATE: Wed Feb 25 10:50:00 2026
      UPTIME: 45 days, 04:12:30
LOAD AVERAGE: 2.15, 1.95, 1.88
       TASKS: 215
    NODENAME: web01.internal
     RELEASE: 5.15.0-100-generic
     VERSION: #100-Ubuntu SMP Wed Feb 10 14:15:20 UTC 2026
     MACHINE: x86_64
      MEMORY: 8 GB
       PANIC: "Oops: 0000 [#1] SMP NOPTI"
       TAINT: P (PROPRIETARY_MODULE)

Linia TAINT indică faptul că acest kernel funcționează cu restricții. Un indicator 'P' arată că este încărcat un modul proprietar. Exemplele comune includ drivere GPU closed-source, module proprietare de controllere RAID sau software de securitate comercial (agenți EDR). Pentru a identifica exact ce module sunt active, rulează comanda mod în consola crash și analizează coloana din dreapta pentru flag-urile taint.

Dacă stack trace-ul te conduce direct într-un modul tainted, kernelul în sine este stabil, dar driverul third-party are un defect major. Trebuie să elimini modulul, să îl actualizezi de la vendor sau să înlocuiești complet hardware-ul care necesită acel driver. Acesta este un punct de eșec masiv la controllerele hardware vechi și explică de ce implementările noastre KVM se bazează exclusiv pe drivere open-source și configurații cu stocare NVMe direct atașată.

Evaluarea stării memoriei cu kmem

Dacă mesajul de panică face referire la coruperea sau epuizarea memoriei, trebuie să afli cum era alocată memoria RAM chiar la momentul prăbușirii. Comanda kmem -i oferă un instantaneu al utilizării memoriei corespunzător milisecundei exacte în care CPU-ul a primit halt. Afișează memoria totală, memoria liberă, utilizarea partiției swap și alocările din cache-ul slab.

Uită-te cu atenție la coloana Slab. Slab allocator-ul gestionează obiecte din structura internă a kernelului precum inodes, dentry-uri și buffere de rețea. Dacă cache-ul slab îți consumă majoritatea memoriei RAM, ai un memory leak în interiorul unui driver din kernel. Pe de altă parte, dacă memoria din user-space este complet epuizată dar cache-ul slab se încadrează în limite normale, presiunea a fost generată la nivel de aplicație. Pentru a găsi un leak în zona slab trebuie să rulezi kmem -S, comandă ce inspectează direct structurile care consumă memorie, indicându-ți clar ce subsistem e vinovat.

Realități operaționale și decizii

Citirea unui core dump necesită o înțelegere solidă a programării în C, a arhitecturii hardware și a internelor nucleului Linux. Când un server de producție dă crash, prima prioritate este restaurarea serviciului. Mecanismul kdump îți permite păstrarea automată a dovezilor astfel încât să poți da un restart imediat și să investighezi fișierul vmcore offline, fără a prelungi downtime-ul.

Dacă munca ta zilnică implică instalarea de simboluri de debug și corelarea adreselor hexazecimale pe un stack trace, faci treaba unui inginer de sisteme low-level. Pentru echipele tehnice a căror sarcină este implementarea aplicațiilor, analiza de kernel panic reprezintă o distragere costisitoare. Prin mutarea aplicațiilor pe o infrastructură administrată, furnizorul de hosting devine responsabil pentru stabilitatea hypervisorului, mitigarea defectelor hardware și testarea driverelor. Te bazezi pe stabilitatea virtualizării în loc să faci debug la nivel bare-metal.

Diferența dintre a înlocui componente hardware la întâmplare și a demonstra cauza reală a unui incident stă în procesul tău de diagnosticare. Configurează kdump. Asigură-te că memoria este alocată corect în GRUB. Imediat ce serverul dă halt, folosește utilitarul crash pentru a analiza instruction pointer-ul. Verifică stack trace-ul pentru a localiza funcția care a cedat, scanează logurile hardware după evenimente MCE și verifică alocările slab. Un kernel panic reflectă un eșec logic la nivel de sistem, iar fișierul core dump îți oferă de fiecare dată dovada exactă a acelui eșec.