Diagnozowanie serwera SUSE zawieszającego się na ekranie wyłączania systemd

Jeśli system SUSE Linux Enterprise Server zawiesza się podczas wyłączania systemu systemd, zidentyfikuj jednostkę z uruchomionym zadaniem zatrzymania lub sprawdź ostatnie komunikaty z poprzedniego rozruchu, a następnie napraw tę jednostkę lub jej zależności. Jednostka to zasób zarządzany przez systemd, taki jak usługa lub punkt montowania; zadanie zatrzymania to żądanie systemu systemd o jego zamknięcie. Nie obniżaj globalnego limitu czasu ani nie wymuszaj wyłączenia zasilania jako pierwszej metody naprawy, ponieważ usługa lub system plików może nadal zamykać pliki lub zapisywać dane.

Niniejszy przewodnik jest oparty na dokumentacji SLES 15 SP7 sprawdzonej w październiku 2026 r. Dokładna polityka zatrzymywania zależy od dostawcy usługi i magazynu, dlatego należy korzystać z jego wskazówek w przypadku wszelkich zmian specyficznych dla danej jednostki.

1. Bezpiecznie przestrzegaj wyłączenia

Krok 1: Zapisz dokładną wiadomość i czekaj na przydatne dowody

Jeśli w konsoli pojawi się komunikat „Zadanie zatrzymania jest uruchomione dla…” z odliczaniem, zapisz nazwę usługi lub montowania oraz informację o zmianie timera. Oznacza to, że systemd oczekuje na operację zatrzymania danej jednostki, a niekoniecznie na awarię systemu operacyjnego; bazy danych i zdalne magazyny danych mogą potrzebować czasu na prawidłowe zamknięcie.

Obserwuj za pomocą konsoli zdalnej lub szeregowej albo innego dostępnego terminala. Unikaj poleceń resetowania i zasilania podczas operacji zapisu. Jeśli system przestanie reagować, zapisz ostatnią widoczną linię i kontynuuj po uruchomieniu.

2. Znajdź jednostkę, która czeka

Krok 2: Sprawdź zadania systemd, czy komputer nadal akceptuje polecenia

Jeśli SSH lub drugi terminal nadal działa, zapytaj systemd, które zadania są uruchomione lub oczekujące, a następnie sprawdź nazwę jednostki na ekranie:

sudo systemctl list-jobs
sudo systemctl status SERVICE.service

Zastąp SERVICErzeczywistą nazwą jednostki. Uruchomione zadanie zatrzymania zawęża zakres wyszukiwania, ale nie wyjaśnia, dlaczego proces nie został zakończony. Przed zmianą konfiguracji zapoznaj się z jego statusem i dziennikami. Jeśli systemd nie odpowiada, nie anuluj zadań bezmyślnie; sprawdź poprzedni dziennik po powrocie hosta.

3. Użyj poprzedniego rozruchu, aby zidentyfikować przyczynę

Krok 3: Przeczytaj koniec dziennika poprzedniego buta

Dziennik to indeksowany dziennik systemd zawierający komunikaty jądra, usług i systemu. Po kolejnym pomyślnym uruchomieniu wyświetl listę zarejestrowanych rozruchów i sprawdź zakończenie poprzedniego:

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

Poszukaj ostatniego komunikatu „Stopping”, przekroczenia limitu czasu, ponownych prób lub nazwanego urządzenia lub montażu. Ostatni wiersz to tylko wskazówka: polecenie wyłączenia może pozostawić inną jednostkę oczekującą. Porównaj znaczniki czasu i komunikaty w pobliżu.

Krok 4: Filtruj dzienniki pod kątem podejrzanej usługi

Gdy ekran lub dziennik nazwie usługę, zapytaj tylko o poprzednie wpisy rozruchowe tej jednostki. Sprawdź również jej załadowaną konfigurację:

sudo journalctl -b -1 -u SERVICE.service --no-pager
sudo systemctl cat SERVICE.service

Sprawdź, czy ExecStopw haku zamykania nie występuje niestandardowy plik wykonywalny, skrypt, który czeka w nieskończoność, zawieszony proces potomny lub błąd aplikacji. W przypadku jednostek dostawcy, przed edycją porównaj pakiet i konfigurację z obsługiwanymi wytycznymi.

Krok 5: Sprawdź uchwyty i miejsca do przechowywania tylko wtedy, gdy dowody na to wskazują

Jeżeli dziennik wymienia punkt montowania, urządzenie lub zdalny system plików, sprawdź tabelę montowania i odpowiadający jej wpis w /etc/fstab:

sudo findmnt --verify --verbose

Sprawdź, czy NFS, CIFS, iSCSI lub inna zdalna zależność jest dostępna i oczekiwana podczas zamykania systemu. Usuń przestarzały wpis montowania dopiero po potwierdzeniu, że jest nieużywany. Nie wymuszaj odmontowania aktywnego systemu plików tylko na podstawie powolnego restartu.

4. Usuń przyczynę, nie ukrywając jej

Krok 6: Napraw usługę lub dostosuj jedynie udokumentowaną politykę zatrzymywania

W przypadku usługi, która się nie zamyka, należy najpierw naprawić problem ze skryptem zamykającym, konfiguracją aplikacji lub pakietem. Wartość drop-in na jednostkę sudo systemctl edit SERVICE.servicejest przechowywana w /etc/systemd/system/pliku dostawcy bez konieczności edycji pliku. Dokumenty SUSE TimeoutSecdotyczące uruchamiania i zatrzymywania usługi; dla tego obciążenia należy użyć wartości zatwierdzonej przez dostawcę.

Po udokumentowanej edycji przeładuj definicje jednostek systemd za pomocą sudo systemctl daemon-reloadi sprawdź wynik za pomocą sudo systemctl cat SERVICE.service. Dłuższy limit czasu może pozwolić na prawidłowe zakończenie zamykania systemu, ale może również wydłużyć nieudany restart. Krótszy limit może zakończyć działanie usługi przed opróżnieniem stanu. Nie zmieniaj globalnych ustawień domyślnych, aby ukryć defekt jednej jednostki.

Krok 7: Zachowaj dzienniki na wypadek kolejnego incydentu

/run/log/journal/SLES domyślnie przechowuje dane dziennika w tym katalogu , a ten katalog zmienny jest czyszczony po ponownym uruchomieniu. Jeśli journalctl -b -1nie ma żadnych wpisów z poprzedniego rozruchu, włącz trwałe przechowywanie dziennika na potrzeby przyszłej diagnostyki:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix=/var/log/journal
sudo journalctl --flush

Trwałe logi zajmują przestrzeń w systemie plików /var; SUSE zauważa, że ​​dziennik może domyślnie zajmować do 10 procent tego systemu plików. Sprawdź ilość wolnego miejsca i retencję, szczególnie na małych /varwolumenach.

5. Sprawdź kolejny planowany restart

Krok 8: Potwierdź, że zatrzymanie zostało zakończone i serwer powrócił do działania

Po usunięciu podejrzewanej przyczyny zaplanuj jeden kontrolowany restart z dostępem do konsoli. Po powrocie komputera sprawdź ostatnie komunikaty z poprzedniego rozruchu i sprawdź aktualny stan usługi:

sudo journalctl -b -1 -e
sudo systemctl status SERVICE.service

Problem rozwiązuje się, gdy serwer wyłącza się bez oczekiwania na tę samą jednostkę, uruchamia się normalnie, a usługa lub montowanie działa. Jeśli logi nagle się kończą lub wskazują na błędy jądra, kontrolera lub sprzętu, należy je zachować i zbadać problem z pomocą SUSE lub dostawcy sprzętu, zamiast dostrajać limity czasu.

Szczegóły dotyczące poleceń można znaleźć w podręczniku systemd dla systemu SLES 15 SP7 oraz w podręczniku SUSE dotyczącym dzienników trwałych i filtrów journalctl . Te kroki identyfikują prawdopodobne blokady; właściwy sposób rozwiązania problemu z usługą, systemem plików lub sprzętem zależy od jednostki wskazanej w logach komputera.