Ten wątek rozpoczął się od zgłoszenia dotyczącego automatycznego uruchamiania aplikacji, ale w jednej z późniejszych odpowiedzi wskazano głębszy tryb awarii: sam Docker mógł nie uruchamiać się, ponieważ nadpisanie konfiguracji systemd wymuszało użycie nvidia-container-runtime na hoście, na którym ta ścieżka środowiska uruchomieniowego była niezgodna.
Najpierw sprawdź, czy Docker się uruchamia
Jeśli po ponownym uruchomieniu nie działają różne, niezależne od siebie aplikacje, przed edytowaniem każdej z nich sprawdź usługę Docker. Dokumentacja rozwiązywania problemów z demonem Docker opisuje awarie uruchamiania demona spowodowane konfliktami konfiguracji i nadpisaniami systemd.
Wymagania sklepu aplikacji ZimaOS pomagają ustalić, które aplikacje są oparte na Dockerze, natomiast pierwsza aplikacja Docker przedstawia standardowy przepływ pracy z kontenerami w ZimaOS. Problem dotyczący jednocześnie wielu kontenerów z większym prawdopodobieństwem leży w warstwie demona lub środowiska uruchomieniowego niż wynika z dziewięciu niezależnych błędów aplikacji.
Zasady ponownego uruchamiania to niejedyna warstwa
Zasady ponownego uruchamiania Dockera wyjaśniają, co demon robi z zatrzymanymi kontenerami. Nie pomogą jednak, jeśli sam demon Docker nie może się prawidłowo uruchomić.
Poprawka dotycząca środowiska uruchomieniowego NVIDIA była zależna od systemu
Jeden z uczestników wyłączył nadpisanie konfiguracji systemd dla Dockera, które jawnie dodawało nvidia-container-runtime. Po ponownym uruchomieniu Docker zaczął działać, ale obsługa procesora graficznego NVIDIA nie była już konfigurowana za pośrednictwem tego nadpisania.
Aktualna dokumentacja NVIDIA Container Toolkit zaleca skonfigurowanie Dockera za pomocą polecenia nvidia-ctk runtime configure --runtime=docker, a następnie ponowne uruchomienie Dockera. To ważny kontekst: zmiany nazwy pliku nadpisania konfiguracji z dawnego wątku społeczności nie należy traktować jako uniwersalnego, współczesnego sposobu konfigurowania lub usuwania środowiska uruchomieniowego NVIDIA.
Przed modyfikowaniem plików systemowych sprawdź wolne miejsce
Późniejszy użytkownik próbował zmienić nazwę nadpisania konfiguracji, ale otrzymał komunikat No space left on device. To inna przyczyna źródłowa, którą trzeba najpierw usunąć. Zmiany w ZimaOS 1.5 zapewniają kontekst wersji zmian w ZimaOS, natomiast proces rozwiązywania problemów z ZimaOS jest przydatny, gdy po aktualizacji pojawi się szersza awaria na poziomie hosta.
Bezpieczniejsza kolejność diagnostyki
- Sprawdź, czy Docker jest aktywny, i przejrzyj jego najnowsze dzienniki.
- Upewnij się, że dysk systemowy nie jest pełny.
- Sprawdzaj zasady ponownego uruchamiania kontenerów dopiero po upewnieniu się, że demon działa prawidłowo.
- Jeśli w dziennikach pojawia się informacja o ładowaniu środowiska uruchomieniowego NVIDIA, przed wprowadzaniem zmian sprawdź bieżącą konfigurację środowiska uruchomieniowego.
- Przed modyfikacją wykonaj kopię zapasową niestandardowego nadpisania konfiguracji systemd.
Podsumowanie
Źródłowy wątek nie dowodzi, że każdy problem z automatycznym uruchamianiem w ZimaOS 1.4.3 miał tę samą przyczynę. W jednym systemie nadpisanie konfiguracji środowiska uruchomieniowego NVIDIA dla Dockera uniemożliwiało prawidłowe uruchomienie demona; w innym próba zastosowania poprawki ujawniła zapełniony dysk systemowy. Przed zastosowaniem historycznego obejścia z nadpisaniem konfiguracji zdiagnozuj stan demona Docker i pamięci masowej.
