Debugging avansat al procesului de boot cu systemd-analyze, critical-chain și consola de urgență

Când un sistem Linux pornește lent sau rămâne blocat, cauza nu este întotdeauna serviciul care apare ultimul pe ecran. Systemd pornește multe unități în paralel, iar un serviciu poate aștepta o partiție, o interfață de rețea, un dispozitiv sau altă dependență.

Investigația corectă combină trei surse: timpii calculați de systemd-analyze, lanțul de dependențe și jurnalul bootului afectat. Dacă sistemul nu ajunge la login, poți porni direct în rescue.target sau emergency.target.

Stabilește cât a durat fiecare etapă

După ce sistemul pornește, rulează:

systemd-analyze time

Rezultatul separă timpul consumat de firmware, bootloader, kernel, initrd și userspace. Nu toate sistemele pot raporta fiecare componentă, dar valoarea pentru userspace este utilă când problema apare după preluarea controlului de către systemd.

Listează unitățile după timpul petrecut în starea de activare:

systemd-analyze blame

Exemplu:

28.442s systemd-networkd-wait-online.service
12.307s dev-mapper-data.device
 4.821s docker.service

blame nu demonstrează că prima unitate din listă este cauza bootului lent. Comanda măsoară timpul în care unitățile au fost în starea activating, iar pornirea paralelă, socket activation și dispozitivele care își schimbă direct starea pot face clasamentul incomplet.

Găsește lanțul care a întârziat ținta finală

Rulează:

systemd-analyze critical-chain

Aceasta afișează lanțul critic până la targetul implicit. Simbolul @ indică momentul în care unitatea a devenit activă, iar + arată durata pornirii sale.

Pentru o țintă sau un serviciu concret:

systemd-analyze critical-chain multi-user.target
systemd-analyze critical-chain nginx.service

Dacă vezi:

multi-user.target @48.201s
└─network-online.target @47.990s
  └─systemd-networkd-wait-online.service @12.100s +35.880s

investigația trebuie continuată la configurația rețelei și la motivul pentru care sistemul așteaptă network-online.target.

Verifică unitatea:

systemctl status systemd-networkd-wait-online.service
systemctl cat systemd-networkd-wait-online.service
journalctl -u systemd-networkd-wait-online.service -b

critical-chain poate fi și el înșelător în anumite cazuri: nu afișează complet joburile care au expirat și nu surprinde toate particularitățile pornirii paralele. Folosește-l ca hartă, nu ca verdict final.

Analizează bootul curent și bootul anterior

Pentru erorile bootului curent:

journalctl -b -p warning

Pentru bootul anterior, util după un restart forțat:

journalctl -b -1 -p warning

Vezi toate booturile disponibile:

journalctl --list-boots

Caută evenimente relevante:

journalctl -b -1 |
grep -iE 'failed|timeout|dependency|mount|fsck|firmware|error'

Verifică și unitățile eșuate:

systemctl --failed
systemctl list-jobs

Documentația systemd recomandă systemctl list-jobs pentru identificarea joburilor care rulează sau așteaptă în timpul unui boot blocat.

Poți genera și o diagramă SVG:

systemd-analyze plot > boot.svg

Aceasta arată vizual suprapunerea unităților, dar trebuie interpretată împreună cu logurile și dependențele.

Intră în rescue.target sau emergency.target

În meniul GRUB, selectează intrarea Linux, apasă e și adaugă la linia kernelului:

systemd.unit=rescue.target

Rescue mode pornește sistemul de bază și o consolă administrativă, fiind potrivit când problema apare la serviciile normale pornite ulterior.

Pentru un mediu mai minimal:

systemd.unit=emergency.target

emergency.target pornește o consolă pe terminalul principal și evită majoritatea serviciilor și mount-urilor. Este folosit inclusiv când verificarea unui filesystem necesar eșuează.

În emergency mode, partiția root poate fi read-only. Pentru modificări:

mount -o remount,rw /

Verifică frecvent:

cat /etc/fstab
mount -a
systemctl --failed
journalctl -xb

După corectarea unui /etc/fstab greșit:

systemctl daemon-reload

Systemd indică explicit această procedură pentru erorile de mount reparate din consola de urgență.

Activează temporar debug logging

Pentru un boot dificil de observat, elimină temporar quiet și adaugă în GRUB:

systemd.log_level=debug
systemd.log_target=console

Pe o consolă serială poți folosi:

systemd.log_level=debug systemd.log_target=console console=ttyS0,38400

Există și consola timpurie:

systemd.debug_shell=1

Aceasta oferă un shell root pe tty9, accesibil de regulă prin Ctrl+Alt+F9. Dezactiveaz-o imediat după investigație, deoarece o consolă root rămasă activă reprezintă un risc de securitate.

Un debugging bun nu se termină cu dezactivarea serviciului lent. Documentează unitatea, dependența care a blocat-o, mesajul exact din jurnal și modificarea aplicată. Apoi repetă măsurătorile pentru a confirma că problema a dispărut.

Surse folosite

systemd — Diagnosing Boot Problems și consolele rescue/emergency.

systemd-analyze Manual — time, blame, critical-chain și plot.

systemd.special Manual — rolul emergency.target și rescue.target.

journalctl și systemctl — analiza jurnalului și a joburilor systemd.