Remediați un server SUSE Linux care se blochează la repornire la închiderea systemd

Dacă un server SUSE Linux pare să se blocheze în timpul repornirii la un mesaj de închidere systemd, cea mai utilă primă presupunere nu este că comanda de repornire în sine este defectă. În majoritatea cazurilor, systemd așteaptă finalizarea unei unități, a unei monturi, a unui proces sau a unui hook de închidere. Prin urmare, cea mai sigură soluție este identificarea exactă a jobului care încă rulează, inspectarea motivului pentru care nu se oprește și corectarea acelei componente, în loc să scurtăm global timeout-urile de închidere.

Acest ghid folosește un exemplu ipotetic pe tot parcursul: un server numit lab-sles01rulează SUSE Linux Enterprise Server și se întrerupe în timpul repornirii, afișând un mesaj similar cu A stop job is running for backup.service. Exemplul este doar o ilustrare a metodei de diagnosticare; nu este un raport al unui test real sau o afirmație că o anumită versiune de SUSE are un defect într-un serviciu numit backup.service.

Remedierea în patru pași pe scurt

Pasul 1: Înregistrați exact unde se oprește oprirea

Urmăriți consola locală, consola mașinii virtuale, consola BMC/IPMI sau consola hypervisor în timpul unei reporniri planificate. O linie care denumește o unitate este mult mai utilă decât o descriere generală, cum ar fi „systemd a fost blocat”. În cazul ipotetic lab-sles01, să presupunem că consola arată că backup.servicesystemd se oprește în continuare, în timp ce alte unități s-au oprit deja.

Exemplu ilustrativ: consola de închidere identifică backup.serviceunitatea pe care systemd o așteaptă încă.

Dacă consola denumește în schimb o .mountunitate, un sistem de fișiere de rețea, un dispozitiv sau un alt serviciu, urmați acel nume în loc să aplicați un timeout generic pentru serviciu. Unitatea afișată în partea de jos a consolei este un indiciu, nu automat cauza principală: este posibil să aștepte un proces copil, un spațiu de stocare, o rețea I/O sau o altă dependență.

Ghidul systemd actual al SUSE menționează că o repornire sau o oprire prelungită poate fi cauzată de un serviciu care nu se încheie și recomandă verificarea joburilor systemd. Consultați SUSE Linux Enterprise Server 16.0: Introducere în noțiunile de bază despre systemd .

Pasul 2: Folosește jurnalul de pornire anterior după ce serverul returnează

După ce mașina pornește din nou, inspectați închiderea care tocmai a avut loc. SUSE documentează offset-urile de pornire în jurnal: boot 0este pornirea curentă, -1este pornirea anterioară și așa mai departe. Începeți cu:

sudo journalctl --list-boots
sudo journalctl -b -1

Pentru un jurnal mare, ordinea inversă poate afișa ultimele mesaje mai rapid:

sudo journalctl -b -1 -r

Exemplu ilustrativ: jurnalul pornirii anterioare arată serviciul ipotetic de backup care primește SIGTERM și expiră ulterior.

Căutați expresii precum Stopping, stop job, timed out, Failed with result, Unmounting, Dependency failed, sau mesaje de la serviciul suspect. Puteți restrânge vizualizarea odată ce cunoașteți numele unității:

sudo journalctl -b -1 -u backup.service

Documentează SUSE journalctl -b -1pentru analiza pornirii anterioare în documentația sa de jurnal SLES 15 SP7 . Dacă journalctl --list-bootsnu conține pornirea anterioară, nu trageți concluzii din istoricul lipsă; verificați cum este configurată stocarea journald și utilizați înregistrarea în consolă sau la distanță pentru următoarea reproducere.

Pasul 3: Identificați dacă blocantul este un serviciu, o montare, un inhibitor sau un hook de închidere târzie

Dacă puteți reproduce problema într-o fereastră de întreținere, păstrați disponibilă o a doua consolă administrativă. Înainte ca conectivitatea să dispară, executați:

sudo systemctl list-jobs
sudo systemctl status backup.service

Exemplu ilustrativ: backup.serviceare o operațiune de oprire în execuție în timp ce ținta de repornire așteaptă în urma ei.

Ghidul de depanare systemd din amonte explică faptul că joburile afișate ca runningtrebuie să se termine înainte ca joburile dependente afișate ca waitingsă poată continua. SUSE recomandă, de asemenea, systemctl list-jobssituațiile în care închiderea sau repornirea durează prea mult. Acest lucru face ca această comandă să fie deosebit de utilă atunci când serverul nu este complet înghețat și PID-ul 1 este încă receptiv.

Dacă un serviciu se oprește prea încet

Inspectați definiția unității și comportamentul acesteia la oprire:

sudo systemctl cat backup.service
sudo systemctl status backup.service
sudo journalctl -u backup.service -b

Verificați dacă serviciul are o ExecStop=acțiune, dacă procesul său gestionează SIGTERM și dacă așteaptă resurse de stocare sau de rețea. O bază de date, un agent de backup sau un serviciu middleware ar putea avea nevoie în mod legitim de timp pentru a goli datele, așa că închiderea lor mai devreme nu este automat o soluție.

Dacă este implicat un sistem de fișiere montat sau de rețea

Căutați operațiuni de demontare eșuate și identificați sursa montării:

findmnt
systemctl list-units --type=mount
sudo journalctl -b -1 | grep -Ei 'unmount|umount|mount|nfs|cifs'

Pentru NFS sau CIFS, investigați accesibilitatea serverului, sesiunile învechite și dacă opțiunile de montare corespund cerințelor de oprire ale serverului. Dacă unitatea blocată este generată din /etc/fstab, remediați configurația de montare în loc să aplicați un timeout specific serviciului unei unități fără legătură.

Dacă solicitarea de repornire este inhibată

Înainte de începerea închiderii, puteți lista inhibitorii activi ai sistemului systemd:

systemd-inhibit --list

Blocările inhibitoare pot bloca sau întârzia cererile de închidere în timp ce o aplicație execută o activitate care nu ar trebui întreruptă. Acestea sunt cele mai relevante atunci când cererea de repornire în sine este întârziată înainte ca sistemul să intre în secvența finală de închidere. Consultați manualul systemd-inhibit din amonte .

Dacă blocarea apare după ce serviciile sunt deja nefuncționale

O blocare într-o etapă ulterioară merită o investigație diferită. systemd rulează executabile cu /usr/lib/systemd/system-shutdown/puțin timp înainte de repornirea sau oprirea finală și așteaptă finalizarea acestora. Dacă jurnalul și consola arată că serviciile obișnuite sunt deja oprite și blocarea are loc în etapa finală de închidere, verificați directorul respectiv și orice hook-uri instalate de furnizor. Documentația serviciului de închidere systemd din amonte descrie acest comportament.

Pasul 4: Remediați componenta, apoi testați o repornire normală

Revenim la ipoteza lab-sles01. Să presupunem că jurnalele arată că backup.serviceignoră terminarea normală după ce procesul de backup s-a finalizat deja. Prima opțiune este remedierea serviciului sau a comenzii de oprire a acestuia. Dacă se știe că serviciul se poate termina în siguranță după o perioadă delimitată, o suprascriere systemd per unitate poate limita timpul de așteptare al systemd.

Creați o suprascriere în loc să editați o unitate de furnizor sub /usr/lib/systemd/system:

sudo systemctl edit backup.service

De exemplu:

[Service]
TimeoutStopSec=30s

Apoi reîncărcați configurația unității systemd:

sudo systemctl daemon-reload

Exemplu ilustrativ: o expirare per serviciu se aplică numai după ce serviciul ipotetic a fost identificat drept blocant.

Nu copiați valoarea de 30 de secunde orbește. Timeout-ul corect depinde de ceea ce serviciul real trebuie să finalizeze în siguranță. Reducerea acestuia pentru o bază de date, un daemon de stocare, un serviciu în cluster sau un proces de backup poate întrerupe curățarea legitimă. Un timeout este o barieră de siguranță, nu un substitut pentru remedierea unei ExecStop=acțiuni defecte sau a unei aplicații care nu se termină corect.

Când sunteți mulțumit de modificare, testați o repornire normală:

sudo systemctl reboot

După ce mașina revine, verificați din nou pornirea anterioară și confirmați că unitatea s-a oprit complet, în loc să dispară pur și simplu din consolă.

Când ar trebui să folosești o repornire forțată?

O repornire forțată este o opțiune de recuperare, nu o strategie de depanare. Documentația systemd din amonte precizează că o repornire --forcecu systemctl reboot[data] omite închiderea normală a serviciilor, dar totuși oprește procesele și încearcă să demonteze sau să remonteze sistemele de fișiere în modul read-only. Furnizarea --forcede două ori este mai periculoasă, deoarece poate reporni fără a termina procesele sau a demonta sistemele de fișiere, cu riscul de pierdere a datelor.

Dacă serverul este deja blocat și nu există o modalitate mai sigură de a restabili serviciul, o repornire forțată poate fi justificată conform procedurilor operaționale:

sudo systemctl reboot --force

Evitați să tratați systemctl reboot --force --force, o repornire virtuală sau o resetare fizică ca pe o soluție normală. Aceste acțiuni pot elimina dovezile de care aveți nevoie și pot pune în pericol scrierile în timpul operațiunii. Documentația systemctl din amonte distinge în mod explicit comportamentele cu forță simplă și dublă.

Ce se întâmplă dacă fiecare repornire se blochează și nu poți depana problema în modul normal?

Folosește o consolă de mentenanță și pornește în modul de salvare (rescue mode). SUSE documentează adăugarea systemd.unit=rescue.targetla linia de comandă a kernelului din editorul GRUB. Modul de salvare oferă o sesiune root cu sisteme de fișiere locale și servicii de bază, lăsând rețeaua inactivă, ceea ce te poate ajuta să dezactivezi sau să repari serviciul sau configurația de montare problematică.

Consultați Ghidul de administrare SLES 15 SP7 pentru procedura oficială de salvare. Pe sistemele în care problema apare numai după o anumită modificare a pachetului, kernelului, driverului sau spațiului de stocare, examinați și istoricul de întreținere SUSE relevant înainte de a efectua modificări permanente ale timeout-ului.

Tabel de decizie rapidă

Concluzie

Pentru un server SUSE Linux care se blochează la închiderea systemd, soluția durabilă este identificarea jobului pe care systemd îl așteaptă și corectarea acelei unități sau a dependenței sale. Înregistrați mesajul de închidere, inspectați journalctl -b -1, utilizați systemctl list-jobsși systemctl statuspentru a izola blocatorul și abia apoi modificați o configurație de timeout sau de montare per serviciu. Păstrați metodele de repornire forțată pentru situații de recuperare, nu pentru operațiuni de rutină.