Când un server Linux pare „înghețat”, primul impuls este să îl repornești forțat. În producție, însă, o repornire fără date de diagnostic poate transforma o problemă rară într-un incident imposibil de explicat. Blocajele de kernel trebuie tratate metodic: ce CPU este blocat, ce task a rămas în stare D, dacă întreruperile mai rulează și dacă există loguri sau dump-uri utile înainte de reboot.
Trei mecanisme sunt importante pentru investigație: Magic SysRq, detectorii de lockup, inclusiv NMI watchdog, și hung task detector. Ele nu repară singure sistemul, dar pot oferi urme esențiale în loguri sau într-un vmcore.
Magic SysRq este o interfață prin care kernelul poate răspunde la anumite comenzi chiar și când sistemul de utilizator nu mai reacționează. Documentația kernelului precizează că funcționează indiferent ce face kernelul, cu excepția cazului în care acesta este complet blocat. Pentru a fi disponibilă, kernelul trebuie compilat cu CONFIG_MAGIC_SYSRQ, iar funcțiile permise sunt controlate prin /proc/sys/kernel/sysrq.
Valoarea 0 dezactivează funcția, 1 permite toate funcțiile, iar valorile mai mari de 1 sunt interpretate ca bitmask. De exemplu, 8 permite dump-uri de debugging, 16 permite sync, 32 remontează read-only, iar 128 permite reboot sau poweroff. Într-un mediu administrat, nu este recomandat să activezi totul fără motiv. Mai sigur este să permiți doar funcțiile necesare pentru diagnostic și recuperare controlată.
Pe sisteme unde ai acces administrativ, /proc/sysrq-trigger permite declanșarea unei comenzi SysRq. Documentația oferă și forma cu underscore pentru mai multe comenzi într-o singură scriere, de exemplu echo _reisub > /proc/sysrq-trigger. Aceasta trebuie folosită cu prudență: include pași care sincronizează, remontează read-only și repornesc sistemul. Înainte de astfel de acțiuni, colectează logurile disponibile și verifică dacă există politici interne de incident response.
Dacă declanșezi o comandă SysRq și în consolă apare doar antetul, nu înseamnă automat că nu s-a întâmplat nimic. Conform documentației, cauza probabilă poate fi loglevel-ul prea mic; ieșirea se poate afla în dmesg sau în /proc/kmsg. Pentru investigație, verifică jurnalul kernelului imediat după revenirea sistemului sau după boot.
NMI watchdog și detectorii de lockup ajută la identificarea situațiilor în care CPU-ul rămâne prea mult timp în kernel mode. Softlockup înseamnă că kernelul rulează mai mult de 20 de secunde fără să lase alte taskuri să ruleze; de obicei apare un stack trace în log și, dacă sistemul este configurat astfel, se poate declanșa panic. Hardlockup este mai sever: CPU-ul rulează în kernel mode mai multe secunde fără să lase întreruperile să ruleze. Pe unele platforme, mecanismul folosește evenimente Perf/NMI pentru avertizare sau panic.
Parametrul watchdog_thresh controlează perioada de bază, iar valoarea implicită documentată este 10 secunde. Pragul pentru softlockup este 2 * watchdog_thresh. Sysctl-urile relevante includ kernel.watchdog, kernel.soft_watchdog, kernel.nmi_watchdog, kernel.watchdog_thresh și kernel.watchdog_cpumask. Pe x86, nmi_watchdog controlează hard lockup detector: 0 îl dezactivează, 1 îl activează. În unele guest-uri KVM poate fi dezactivat implicit, dar poate fi suprascris prin nmi_watchdog=1 în linia de comandă a kernelului, dacă există justificare operațională.
Un detaliu important pentru sisteme optimizate este NO_HZ_FULL. În această configurație, watchdog-ul rulează implicit doar pe housekeeping cores, pentru a reduce perturbarea workload-urilor sensibile. Dacă investighezi blocaje pe CPU-uri izolate, verifică dacă kernel.watchdog_cpumask urmărește procesoarele relevante.
Hung task detector urmărește taskurile blocate în stare D, adică sleep neîntreruptibil, mai mult decât valoarea configurată în hung_task_timeout_secs. Acest lucru apare frecvent în probleme de I/O, storage, drivere sau filesystem. hung_task_warnings limitează numărul de avertizări, iar valoarea -1 raportează nelimitat. hung_task_panic poate transforma detectarea într-un panic, iar hung_task_all_cpu_backtrace poate trimite NMI către toate CPU-urile pentru backtrace, dacă opțiunea există în kernel.
Pentru un plan defensiv, începe prin a verifica sysctl-urile existente și politica distribuției, nu prin a schimba agresiv setări în producție. Activează doar ce poți monitoriza, trimite logurile kernelului către un sistem extern și documentează pragurile folosite. Dacă incidentul este critic și trebuie analizată memoria kernelului, Kdump este mecanismul standard: folosește kexec pentru a porni rapid un kernel de captură la panic și păstrează imaginea memoriei. Fișierul vmcore poate fi analizat ulterior cu unelte precum crash sau GDB.
Concluzia practică este simplă: repornirea rezolvă temporar simptomul, dar nu explică blocajul. Magic SysRq poate oferi o cale controlată de diagnostic și recuperare, NMI watchdog poate semnala CPU-uri blocate, iar hung task detector poate indica procese blocate în I/O. Folosite împreună, cu logare externă și, unde este necesar, Kdump, aceste mecanisme transformă un freeze opac într-un incident analizabil.
