Rozwiązywanie problemów z rozruchem maszyny wirtualnej z systemem Linux Azure z powodu pełnego dysku systemu operacyjnego

Dotyczy: ✔️ maszyny wirtualne z systemem Linux

Podsumowanie

W pewnych okolicznościach i konfiguracjach pełny dysk systemu operacyjnego może powodować problemy z rozruchem maszyn wirtualnych Azure z systemem Linux. Ten artykuł przedstawia przyczyny i rozwiązania problemów związanych z uruchamianiem systemu.

Symptomy

Podczas normalnych operacji systemowych, jeśli dysk systemu operacyjnego lub krytyczne partycje systemowe staną się pełne, mogą wystąpić następujące problemy:

• Maszyna wirtualna zostanie nieoczekiwanie zamknięta.
• Maszyna wirtualna nie uruchamia się pomyślnie.

Wymagania wstępne

Aby rozwiązać problemy z rozruchem i zakończyć naprawę systemu, należy spełnić następujące wymagania:

• Uprawnienia do tworzenia migawki dysku lub obsługi niektórych narzędzi do tworzenia kopii zapasowych i przywracania.

  W tym artykule dane lub dyski są zmieniane, więc możliwość przywracania maszyny wirtualnej do poprzedniego stanu jest krytycznym składnikiem bezpiecznej administracji systemu.

• Diagnostyka rozruchu , która jest włączona i skonfigurowana.

  Ta konfiguracja umożliwia przyszłe przeglądanie pamięci dziennika konsoli oraz interakcję z interfejsem konsoli szeregowej VM.

• Uprawnienia do tworzenia maszyny wirtualnej w przypadku, gdy maszyna wirtualna ratownicza jest potrzebna w dowolnym momencie.

• Uprawnienia do tworzenia, odłączania i dołączania dysków w razie potrzeby wymiany dysków.

Scenariusz 1. Maszyna wirtualna jest nieoczekiwanie zamykana i nie można jej uruchomić

Wiele rozwiązań dotyczących wzmacniania zabezpieczeń może prowadzić do trudności w utrzymywaniu systemów. Jeśli podczas zapisywania w dzienniku inspekcji wystąpi błąd, jedna typowa konfiguracja wymaga natychmiastowego zamknięcia systemu. Aby sprawdzić, czy ten scenariusz jest przyczyną zamknięcia systemu, wykonaj następujące czynności:

• Sprawdź komunikaty zamykania systemu w dzienniku konsoli szeregowej.

  Jeśli system jest uruchomiony, zostanie wyświetlony komunikat "Uruchamianie usługi inspekcji zabezpieczeń...". Ten komunikat nie wskazuje, że usługa została uruchomiona. Zamiast tego maszyna wirtualna natychmiast przechodzi do zamknięcia, a wyświetlany jest komunikat "Wyłączenie zasilania". Jeśli system jest uruchomiony i niespodziewanie zostanie zamknięty, konsola szeregowa może wyświetlić uporządkowany proces zamykania systemu kończący się komunikatem "Wyłączenie zasilania". Zobacz następujące zrzuty ekranu jako przykład:

  

  

• Zamontuj dysk systemu operacyjnego za pomocą poleceń az vm repair, ręcznej maszyny wirtualnej do odzyskiwania lub trybu pojedynczego użytkownika. Następnie sprawdź wykorzystanie dysku przy użyciu df narzędzia wiersza polecenia i sprawdź, czy dysk zawierający katalog /var/log/audit jest zbliżony do 100% wykorzystania.

• Uzyskaj dostęp do systemu plików systemu operacyjnego przy użyciu poleceń az vm repair , ręcznej maszyny wirtualnej odzyskiwania lub trybu pojedynczego użytkownika i sprawdź, czy plik /etc/audit/auditd.conf zawiera następujące konfiguracje:

  [root@linux /]# grep action /etc/audit/auditd.conf
  admin_space_left_action = HALT
  disk_full_action = HALT
  disk_error_action = HALT
  

Rozwiązanie: Tymczasowo wyłącz konfigurację HALT

Jeśli konfiguracja auditd powoduje zamknięcie systemu w przypadku błędów dziennika inspekcji, tymczasowe wyłączenie konfiguracji HALT pozwala maszynie wirtualnej na uruchomienie pełnego systemu operacyjnego w celu dokonania korekcji.

Aby rozwiązać ten typowy problem z auditd i kilka innych powszechnych problemów, uruchom rozszerzenie az vm repair automatycznie w Azure CLI, używając akcji auditd w narzędziu Azure Linux Automatic Repair (ALAR). Aby wykonać tę samą procedurę ręcznie, wykonaj następujące kroki:

1. Utwórz migawkę dysku systemu operacyjnego, aby zapewnić stan odzyskiwania.

2. Uzyskaj dostęp do pliku konfiguracji przy użyciu poleceń az vm repair, ręcznie stworzonej maszyny wirtualnej odzyskiwania lub trybu pojedynczego użytkownika.

3. Zanotuj bieżącą konfigurację, ponieważ miejsce może nie być dostępne do utworzenia kopii zapasowej pliku na maszynie wirtualnej.

4. Zmień poprzednie konfiguracje w pliku /etc/auditd.conf z HALT na dowolną inną prawidłową wartość z wyjątkiem SINGLE. W tym scenariuszu wartości mogą być IGNORE, SUSPEND lub dowolnymi innymi wartościami wymienionymi na stronie man systemu Linux dla pliku auditd.conf, które określają odpowiednie parametry dla wersji oprogramowania używanego na maszynie wirtualnej.

   [root@linux /]# grep action /etc/audit/auditd.conf
   admin_space_left_action = SUSPEND
   disk_full_action = SUSPEND
   disk_error_action = SUSPEND
   

• Jeśli używasz maszyny wirtualnej odzyskiwania, postępuj zgodnie z instrukcjami w temacie Odinstalowanie i odłączenie oryginalnego wirtualnego dysku twardego, aby zamienić z powrotem dysk systemu operacyjnego na problematycznej maszynie wirtualnej i spróbować normalnie uruchomić tę maszynę wirtualną. Jeśli używasz trybu pojedynczego użytkownika, zakończ pracę, a następnie uruchom ponownie maszynę wirtualną.

• Po pełnym uruchomieniu maszyny wirtualnej przejrzyj system plików i zwolnij trochę miejsca przy użyciu narzędzi wiersza polecenia, takich jak df i du. Około 10% systemu plików zawierającego katalog /var/log/audit powinien być dobrym początkowym celem.

Po rozwiązaniu problemu przywróć zawartość pliku /etc/auditd.conf do oryginalnych wartości i uruchom ponownie maszynę wirtualną.

Scenariusz 2: rozmiar dysku maszyny wirtualnej jest zmieniany w Azure, ale nie można zmienić rozmiaru systemu operacyjnego, a maszyna wirtualna nie jest w pełni uruchamiana

Po zidentyfikowaniu pełnego dysku i zamknięciu maszyny wirtualnej w celu zmiany rozmiaru dysku systemu operacyjnego maszyna wirtualna może nie zostać pomyślnie uruchomiona. Ten scenariusz może być mylący w niektórych dystrybucjach, w których system operacyjny próbuje automatycznie zmienić rozmiar głównego systemu plików (/) po ponownym uruchomieniu. Jeśli dysk jest pełny, operacja zmiany rozmiaru może zakończyć się niepowodzeniem, ponieważ proces wymaga trochę wolnego miejsca do rozszerzenia systemu plików. Brak wolnego miejsca może spowodować niepowodzenie pakietu cloud-init, a następnie maszyna wirtualna nie zakończy rozruchu.

Aby zidentyfikować ten problem, przejrzyj dzienniki rozruchu w konsoli szeregowej i sprawdź, czy istnieją wiersze podobne do następującego tekstu:

[   15.384699] cloud-init[1142]: OSError: [Errno 28] No space left on device
[   15.384742] cloud-init[1142]: Original exception was:
[   15.384784] cloud-init[1142]: OSError: [Errno 28] No space left on device

Ponieważ określone komunikaty cloud-init mogą nie być najbardziej widocznymi zwróconymi komunikatami, poszukaj innych wierszy zawierających tekst "[Errno 28] Brak miejsca na urządzeniu" lub podobne komunikaty dotyczące braku miejsca.

Aby rozwiązać ten problem, wyczyść niepotrzebne dane, aby zwolnić niewielką ilość miejsca na dysku, a następnie rozwinąć system plików.

Scenariusz 3. Rozruch maszyny wirtualnej, ale jest niedostępny z powodu awarii usługi

Maszyna wirtualna, która wydaje się być całkowicie uruchomiona, może mieć następujące problemy:

• Problemy z usługą występują podczas rozruchu.
• Agent Azure może nie być dostępny.
• Połączenia z maszyną wirtualną mogą zakończyć się niepowodzeniem.
• Maszyna wirtualna może wydawać się być w trybie offline zgodnie z aplikacjami.

Podczas rozruchu wiele komunikatów, takich jak "[Errno 28] Brak miejsca na urządzeniu" lub inne typy komunikatów wskazują, że główny system plików jest pełny.

Jeśli maszyna wirtualna jest uruchamiana, ale jest niedostępna, sprawdź dziennik seryjny w diagnostyce rozruchu, aby wyświetlić komunikaty rozruchowe lub użyć konsoli szeregowej do interakcji z maszyną wirtualną. Jeśli miejsce jest niewystarczające, wyczyść niepotrzebne dane, aby zwolnić miejsce lub rozwinąć dyski.

Jeśli dziennik konsoli zawiera wiele komunikatów z informacją "ERROR ExtHandler /proc/net/route nie zawiera żadnych tras", pełny dysk systemu operacyjnego może być również przyczyną, ponieważ usługi sieciowe nie mogą uruchomić się całkowicie.

Rozwiązanie

Poniższe rozwiązania dotyczą dowolnego z poprzednich scenariuszy.

Rozwiązanie 1. Wyczyść niepotrzebne dane

1. Uzyskaj dostęp do dysku systemu operacyjnego i części dysku przy użyciu poleceń az vm repair, ręcznie skonfigurowanej maszyny wirtualnej do odzyskiwania lub trybie pojedynczego użytkownika, ponieważ system nie uruchamia się normalnie.

2. Zidentyfikuj duże pliki i katalogi przy użyciu standardowych narzędzi i poleceń systemu Linux:

   • du -ks /* | sort -n — Znajdź najbardziej czasochłonne pliki lub katalogi w lokalizacji. Powtarzaj w największym zgłoszonym katalogu, aż zostaną odkryte jakieś duże dane.

   • ls -altSr /var/log — Wyświetlanie listy zawartości katalogu uporządkowanego według rozmiaru w kolejności rosnącej.

   • find / -size +500M -exec ls -alFh {} \; — Znajdowanie dużych pojedynczych plików. Dostosuj wartość 500M do kilku megabajtów lub gigabajtów w razie potrzeby, aby zlokalizować najbardziej efektywne pliki do usunięcia.

3. Usuń wszystkie pliki, które można zidentyfikować jako niepotrzebne, takie jak stare dzienniki, zapomniane kopie zapasowe i podobne pliki.

4. Po zwolnieniu odpowiedniej ilości miejsca, dąż do tego, aby około 10% dysku było wolne, a następnie uruchom system ponownie.

Rozwiązanie 2. Rozwijanie systemu plików systemu operacyjnego

Jeśli nie można wyczyścić danych z systemu plików systemu operacyjnego, zalecamy rozszerzenie dysku zawierającego krytyczne woluminy systemu operacyjnego. Aby uzyskać więcej informacji, zobacz Rozwijanie wirtualnych dysków twardych na maszynie wirtualnej z systemem Linux.

Następne kroki

Jeśli określony błąd rozruchu nie jest problemem z rozruchem systemu Linux z powodu pełnego dysku systemu operacyjnego, zobacz Rozwiązywanie problemów Azure z błędami rozruchu maszyny wirtualnej z systemem Linux w celu dalszego rozwiązywania problemów.