Dacă serverul SUSE Linux Enterprise se blochează în timpul închiderii systemd, identificați unitatea cu o operațiune de oprire care rulează sau inspectați mesajele finale de la pornirea anterioară, apoi remediați unitatea respectivă sau dependența acesteia. O unitate este o resursă gestionată de systemd, cum ar fi un serviciu sau o montare; o operațiune de oprire este o solicitare a systemd de a opri o unitate. Nu reduceți un timeout global și nu forțați oprirea ca primă remediere, deoarece un serviciu sau un sistem de fișiere poate închide fișiere sau scrie date în continuare.
Această demonstrație urmează documentația SLES 15 SP7 verificată în octombrie 2026. Politica exactă de oprire depinde de furnizorul de servicii și de stocare, așadar, utilizați îndrumările acestora pentru orice modificări specifice unității.
Dacă consola afișează mesajul „O operațiune de oprire rulează timp de…” cu o numărătoare inversă, notați serviciul sau montarea denumită și dacă temporizatorul se modifică. Aceasta înseamnă că systemd așteaptă operațiunea de oprire a unității respective, nu neapărat că sistemul de operare s-a blocat; bazele de date și stocarea la distanță pot necesita timp pentru a se închide corect.
Observați prin intermediul consolei de la distanță sau seriale sau al unui alt terminal disponibil. Evitați comenzile de resetare sau de alimentare în timp ce scrierile sunt în desfășurare. Dacă sistemul nu mai răspunde, înregistrați ultima linie vizibilă și continuați după ce pornește.
Dacă SSH sau un al doilea terminal funcționează în continuare, întrebați systemd ce joburi rulează sau așteaptă, apoi verificați unitatea numită pe ecran:
sudo systemctl list-jobs
sudo systemctl status SERVICE.service
Înlocuiți SERVICEcu numele unității reale. O operațiune de oprire care rulează restrânge căutarea, dar nu explică de ce procesul nu s-a încheiat. Citiți starea și jurnalele sale înainte de a modifica configurația. Dacă systemd nu mai răspunde, nu anulați operațiunile orbește; inspectați jurnalul anterior după ce gazda se întoarce.
Jurnalul este jurnalul indexat al systemd cu mesajele kernelului, serviciului și sistemului. După următoarea pornire reușită, listați pornirile înregistrate și verificați sfârșitul celei anterioare:
sudo journalctl --list-boots
sudo journalctl -b -1 -e
-1-ul selectează boot-ul precedent și -ese mută la cele mai recente intrări ale acestuia.Căutați ultimul mesaj „Oprire”, o expirare, reîncercări sau un dispozitiv sau o montare denumită. Ultima linie este doar un indiciu: comanda de oprire poate lăsa o altă unitate în așteptare. Comparați timestamp-urile și mesajele din apropiere.
Când ecranul sau jurnalul denumește un serviciu, interogați doar intrările de pornire anterioară ale acelei unități. Verificați și configurația încărcată:
sudo journalctl -b -1 -u SERVICE.service --no-pager
sudo systemctl cat SERVICE.service
Verificați dacă există o configurație personalizată ExecStop, un script care așteaptă la nesfârșit, un proces copil care persistă sau o eroare de aplicație în hook-ul său de închidere. Pentru unitățile furnizorului, comparați pachetul și configurația cu instrucțiunile acceptate înainte de editare.
Dacă jurnalul denumește o montare, un dispozitiv sau un sistem de fișiere la distanță, verificați tabela de montare și intrarea corespunzătoare din /etc/fstab:
sudo findmnt --verify --verbose
Verificați dacă o dependență NFS, CIFS, iSCSI sau altă dependență la distanță este accesibilă și așteptată în timpul închiderii. Eliminați o intrare de montare învechită numai după ce confirmați că este neutilizată. Nu forțați demontarea unui sistem de fișiere live doar pe baza unei reporniri lente.
Pentru un serviciu care nu se închide, remediați mai întâi problema scriptului de închidere, a configurației aplicației sau a pachetului. O modificare per unitate de la sudo systemctl edit SERVICE.serviceeste stocată în /etc/systemd/system/fără a edita fișierul furnizorului. Documentele SUSE TimeoutSecpentru pornirea sau oprirea serviciului; utilizați o valoare aprobată de furnizor pentru această sarcină de lucru.
După o editare documentată, reîncărcați definițiile unităților systemd cu sudo systemctl daemon-reloadși inspectați rezultatul cu sudo systemctl cat SERVICE.service. Un timeout mai lung poate permite finalizarea unei închideri legitime, dar poate prelungi și o repornire eșuată. Un timeout mai scurt poate termina un serviciu înainte de a goli starea acestuia. Nu modificați setările implicite globale pentru a ascunde defectul unei unități.
SLES stochează datele din jurnal în /run/log/journal/mod implicit, iar directorul volatil este șters la repornire. Dacă journalctl -b -1nu are intrări la pornirile anterioare, activați stocarea persistentă a jurnalului pentru diagnostice viitoare:
sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix=/var/log/journal
sudo journalctl --flush
Jurnalele persistente utilizează spațiu sub /var; SUSE notează că jurnalul poate utiliza până la 10% din sistemul de fișiere respectiv în mod implicit. Verificați spațiul liber și retenția, în special pe /varvolume mici.
După ce cauza suspectată este corectată, programați o repornire controlată cu acces la consolă disponibil. După ce mașina revine, inspectați mesajele finale ale bootării anterioare și verificați starea curentă a serviciului:
sudo journalctl -b -1 -e
sudo systemctl status SERVICE.service
Problema este rezolvată atunci când serverul se oprește fără a aștepta aceeași unitate, pornește normal, iar serviciul sau montarea funcționează. Dacă jurnalele se termină brusc sau afișează erori de kernel, controler sau hardware, păstrați-le și investigați-le cu SUSE sau cu furnizorul de hardware în loc să reglați timeout-urile.
Pentru detalii despre comenzi, consultați ghidul systemd pentru SLES 15 SP7 și ghidul SUSE despre jurnalele persistente și filtrele journalctl . Acești pași identifică posibilele blocante; remedierea corectă pentru serviciu, sistem de fișiere sau hardware depinde de unitatea numită de jurnalele proprii ale mașinii.
Urmați procedura SP7 a SUSE pentru a activa modul FIPS, reporniți în siguranță, verificați politica activă și verificați dacă cerința de conformitate necesită module validate.
Comparați YaST și cryptsetup pentru un nou volum de date SLES criptat, alegeți LUKS1 sau LUKS2 și verificați comportamentul de deblocare și montare în siguranță.
Configurați RMT pe SLES 15, oglindiți repozitoriile autorizate și verificați înregistrarea HTTPS și accesul la pachet de la un client de testare.
Conectați SLES 15 la AD cu ajutorul gestionării logon-ului bazate pe SSSD din YaST, apoi verificați căutarea în directoare, conectarea la domeniu și tichetele Kerberos.
Configurați calea corectă pentru Live Patching pentru SLES 16.0 sau 15 SP7, aplicați corecțiile eligibile ale kernelului și confirmați ce este activ fără a-l confunda cu o actualizare a kernelului care necesită repornire.
SLES 15 SP5 poate migra online la SP6, dar fiecare nod trebuie să repornească. Folosiți o actualizare continuă testată sau o trecere de la un sistem blue-green la altul pentru a menține accesibile sarcinile de lucru.
Creați, rafinați și verificați un profil AppArmor cu privilegii minime pe SLES 15 SP7, cu o notă clară privind setările implicite SELinux pentru SLES 16.
Folosește profilul STIG acceptat de SUSE pentru a scana SLES 15, a testa remedierea, a revizui constatările rămase și a păstra dovezile evaluării.
Urmăriți o conexiune Cockpit eșuată prin DNS, portul 9090, socketul systemd, firewalld, TLS și setările de conectare folosind instrucțiunile SUSE actuale.
Creați o conexiune Ethernet redundantă pe SLES 15 cu YaST și Wicked, configurați legătura activă de backup și verificați ambele porturi și failover-ul.
