Serwer zrestartował się po aktualizacji lub zaniku prądu i zamiast zachęty do logowania konsola pokazuje komunikat zaczynający się od "You are in emergency mode." Strony nie działają, baza danych jest niedostępna, a oczywiste następne ruchy, czyli kolejny restart albo wklejenie polecenia naprawczego znalezionego w sieci, to dokładnie te, które mogą pogorszyć sprawę. Linux emergency mode nie jest sam w sobie diagnozą. To systemd mówi, że coś, czego system potrzebuje przy starcie, zwykle dysk lub system plików, nie wstało. Ten przewodnik wyjaśnia częste przyczyny, co sprawdzić najpierw i kiedy się zatrzymać, by chronić dane.

Co oznacza Linux emergency mode

W dystrybucjach opartych na systemd, takich jak Debian, Ubuntu, AlmaLinux i Rocky Linux, rozruch zatrzymuje się na celu awaryjnym, gdy nie powiedzie się wymagany krok. Najczęściej jest to montowanie systemu plików wymienionego w /etc/fstab albo kontrola systemu plików, która wymaga decyzji człowieka. System oferuje wtedy minimalną powłokę roota, z głównym systemem plików często zamontowanym tylko do odczytu i prawie bez uruchomionych usług. Komunikat zwykle brzmi:

You are in emergency mode. After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" or "exit" to boot into default mode.

Tryb ratunkowy (rescue mode) jest jego łagodniejszym rodzeństwem: montuje lokalne systemy plików i uruchamia kilka podstawowych usług. Emergency mode robi jak najmniej, i właśnie dlatego pojawia się, gdy pamięć masowa budzi wątpliwości.

Częste przyczyny, od niegroźnych do poważnych

  • Błąd fstab. Linia w /etc/fstab wskazuje dysk, którego już nie ma: wyjęty dysk USB z kopią, wymieniony dysk z nowym UUID albo literówka z niedawnej edycji. To najczęstsza i najmniej groźna przyczyna.
  • System plików wymagający ręcznej kontroli. Po nieczystym wyłączeniu automatyczna kontrola znajduje niespójności, których sama nie naprawi, i prosi o ręczne uruchomienie fsck.
  • Macierz RAID lub wolumin LVM, który się nie zmontował. Zdegradowana macierz RAID, która nie startuje, albo brakujący wolumin fizyczny sprawiają, że system plików na nich jest niedostępny.
  • Psujący się dysk. Błędy odczytu podczas montowania albo system plików, który jądro już przełączyło w tryb tylko do odczytu, by go chronić.

Pierwsze trzy to problemy konfiguracji lub spójności. Czwarty to problem sprzętowy, który na ekranie wygląda tak samo, a traktowanie go jak pozostałych to sposób na utratę danych, które dało się odzyskać. Dlatego nasza praca przy odzyskiwaniu serwerów Linux zawsze zabezpiecza dane przed jakąkolwiek próbą naprawy.

Co sprawdzić najpierw, niczego nie zmieniając

  1. Przeczytaj log. Uruchom journalctl -xb i szukaj linii na czerwono. Jednostka montowania, która się nie powiodła, "Timed out waiting for device" lub "Dependency failed for" z punktem montowania wskazują, który system plików sprawia problem.
  2. Porównaj dyski z fstab. lsblk -f i blkid wypisują dyski i UUID widoczne dla systemu. Jeśli fstab oczekuje UUID, którego nie ma na liście, dysk zniknął lub został wymieniony.
  3. Szukaj błędów sprzętowych. dmesg pokazujący błędy I/O albo smartctl -H zgłaszający psujący się dysk zmienia plan: skopiuj dane przed jakąkolwiek naprawą.
  4. Sprawdź stan RAID. cat /proc/mdstat pokazuje, czy macierze programowego RAID są aktywne, zdegradowane czy nieaktywne.

Zrób zdjęcie ekranu lub zapisz wynik, zanim pójdziesz dalej. Te notatki to pierwsze, o co poprosi każdy, kto będzie Ci pomagał.

Bezpieczne poprawki i te, których unikać

Dobra naprawa systemu Linux to głównie diagnoza; sama poprawka bywa jedną linią. Jeśli log wskazuje dysk nieistotny, na przykład odłączony dysk z kopią, zamontuj główny system plików ponownie do zapisu poleceniem mount -o remount,rw /, zakomentuj tę linię lub dodaj opcję nofail, żeby rozruch nie zależał od tego dysku, i zrestartuj. Opcję nofail warto dodać do każdego dysku, bez którego serwer może działać.

Jeśli system plików wymaga sprawdzenia, a dysk jest zdrowy, uruchom fsck na odmontowanym systemie plików, nigdy na zamontowanym. Czego unikać:

  • Uruchamiania fsck -y raz za razem na psującym się dysku. Każde przejście może przesunąć lub odrzucić dane, które dysk z trudem odczytuje. Najpierw zrób obraz dysku, na przykład przez GNU ddrescue, i naprawiaj kopię.
  • Wymuszania zapisu na systemie plików tylko do odczytu. Gdy jądro przełącza system plików w tryb tylko do odczytu po błędach, chroni go. Ustal dlaczego, zanim znów cokolwiek zapiszesz.
  • Reinstalacji, by problem zniknął. Reinstalacja na tych samych dyskach może nadpisać to, co jeszcze dało się odzyskać.
  • Wielokrotnych restartów w nadziei, że wróci. Każda próba obciąża dysk, który może już się psuć.

Gdy konto root jest zablokowane albo nie ma konsoli

W Ubuntu i niektórych innych systemach konto root domyślnie nie ma hasła, więc emergency mode kończy się komunikatem "Cannot open access to console, the root account is locked" i brakiem powłoki. Wejściem jest wtedy system ratunkowy: tryb rescue dostawcy hostingu lub konsola KVM dla serwera hostowanego albo bootowalny pendrive dla maszyny w biurze. Stamtąd można zbadać dyski, skopiować dane i naprawić konfigurację. Tą samą drogą idzie się, gdy uszkodzony jest sam bootloader, co omawia nasza strona o naprawie rozruchu GRUB i MBR.

Przy sprzęcie w serwerowni dostęp out-of-band, taki jak IPMI, iDRAC lub iLO, oszczędza dojazd, więc skonfiguruj go i zapisz dane dostępowe, dopóki wszystko działa.

Najczęściej zadawane pytania: Linux emergency mode

Czy bezpiecznie jest nacisnąć Control-D lub wpisać exit, aby kontynuować rozruch?

Czasem system wtedy wstanie, ale wszystko, co zależało od brakującego systemu plików, zawiedzie albo, co gorsza, zacznie zapisywać do pustego punktu montowania na dysku głównym. Baza danych lub udział plików może skończyć z nowymi danymi w złym miejscu i starszymi na dysku, który się nie zamontował. Najpierw znajdź przyczynę.

Jaka jest różnica między emergency mode a rescue mode?

Rescue mode montuje lokalne systemy plików i uruchamia mały zestaw podstawowych usług, więc nadaje się do napraw na zdrowym systemie. Emergency mode montuje tylko główny system plików, często tylko do odczytu, i prawie nic nie uruchamia, dlatego jest bezpieczniejszym miejscem, gdy pamięć masowa budzi wątpliwości.

Dlaczego mój serwer przełączył dysk w tryb tylko do odczytu?

Systemy plików takie jak ext4 są zwykle skonfigurowane, by po wykryciu błędów przejść w tryb tylko do odczytu, aby uszkodzenia się nie rozszerzały. Przyczyną może być nieczyste wyłączenie, ale często jest nią psujący się dysk lub kontroler, więc przede wszystkim sprawdź dmesg i dane SMART dysku.

Serwer utknął na zachęcie awaryjnej? Nasza usługa odzyskiwania i naprawy systemu Linux zaczyna od diagnozy i ochrony danych, potem naprawia awarie rozruchu, systemu plików, RAID i usług, a kończy krótkim pisemnym podsumowaniem. Chcesz naprawy Linuksa w Long Beach i okolicach Los Angeles albo serwera hostowanego gdziekolwiek w USA? Skontaktuj się z nami, podając dystrybucję, miejsce hostowania serwera i zdjęcie ostatniego ekranu.