Ten wątek źródłowy prowadzi do mocnego, zależnego od wersji wniosku. Po aktualizacji ZimaBoard 832 do ZimaOS 1.4.3 Docker nie uruchamiał się automatycznie, sklep aplikacji nie mógł instalować nowych aplikacji, a istniejące aplikacje nie mogły się uruchamiać. Zima-Giorgio powiedział, że zespół wiedział o problemie z usługą Docker i podał tymczasowe polecenie ręcznego ponownego uruchomienia.
Autor oryginalnego wpisu potwierdził, że polecenie ponownego uruchomienia rozwiązało bieżący problem, ale zgłosił również, że Docker ponownie nie uruchamiał się po każdym ponownym uruchomieniu hosta. Kolejne wydanie IceWhale dostarcza brakującego potwierdzenia: ZimaOS 1.4.4 oficjalnie naprawił błąd uruchamiania Dockera spowodowany zbyt krótkim odstępem czasu na uruchomienie usługi.
Awaria pojawiła się natychmiast po aktualizacji do wersji 1.4.3
Użytkownik źródłowy zgłosił:
- aktualizacja Prowlarr zawieszała się;
- istniejące aplikacje nie uruchamiały się;
- instalacje nowych aplikacji w sklepie aplikacji kończyły się niepowodzeniem;
- interfejs zgłaszał brak możliwości połączenia z demonem Docker.
/var/run/docker.sock, uniemożliwiając instalowanie i uruchamianie aplikacji.IceWhale określiło to jako znany problem z usługą Docker
26 sierpnia Zima-Giorgio napisał, że zespół uznał to za znany problem z usługą Docker i poinformował, że zostanie wydana poprawka.
Przekazał tymczasowe oficjalne obejście:
sudo -i
systemctl restart docker docker.socketTo polecenie stanowi historyczną, prawidłową wskazówkę IceWhale dotyczącą przypadku ze źródła dla wersji 1.4.3.
Autor oryginalnego wpisu potwierdził, że ręczne ponowne uruchomienie Dockera zadziałało
Użytkownik odpowiedział, że ponowne uruchomienie Dockera jako root z poziomu interfejsu wiersza poleceń całkowicie rozwiązało bieżący problem. Jest to potwierdzony przez źródło sukces, a nie przypuszczalne obejście.
Jednak ten sam użytkownik ponownie uruchomił ZimaBoard i stwierdził, że Docker znów nie uruchomił się automatycznie.
Panel mógł pokazywać aplikacje jako uruchomione, gdy Docker nie działał poprawnie
Ponowne uruchomienie Dockera przywróciło rzeczywisty stan aplikacji
Ręczne ponowne uruchomienie aplikacji nie rozwiązało niezawodnie problemu przy kolejnym uruchomieniu systemu
Zima-Giorgio stwierdził, że niektóre zgłoszenia sugerowały, iż ręczne uruchomienie i ponowne uruchomienie każdej aplikacji może pomóc przy kolejnych ponownych uruchomieniach systemu. Autor oryginalnego wpisu przetestował ten pomysł, ale po ponownym uruchomieniu nadal obserwował ten sam pozorny stan uruchomienia.
Dlatego ważne jest, aby nie przedstawiać ponownego uruchamiania poszczególnych aplikacji jako ostatecznej poprawki problemu opisanego w źródle.
ZimaOS 1.4.4 naprawił problem z czasem uruchamiania Dockera
Oficjalne informacje o wydaniu ZimaOS 1.4.4 obejmują:
- poprawkę aplikacji pozostających w stanie ładowania po uruchomieniu;
- poprawkę niewystarczającego czasu uruchamiania usługi Docker, powodującego niepowodzenie uruchamiania;
- dodatkowe poprawki dotyczące stanu aplikacji i kart instalacji.
Zobacz historyczne rozwiązania problemów z uruchamianiem Dockera w ZimaOS 1.4.4.
Obecni użytkownicy nie powinni traktować polecenia systemctl restart jako trwałej poprawki
W nowoczesnym wydaniu ZimaOS demon Dockera, który wielokrotnie nie uruchamia się po ponownym uruchomieniu systemu, wskazuje na bieżący problem z usługą, pamięcią masową, środowiskiem uruchomieniowym lub konfiguracją. Ponowne uruchomienie Dockera może być działaniem diagnostycznym, ale przed uznaniem ręcznego restartu za czynność wykonywaną przy każdym uruchomieniu systemu należy zebrać informacje o rzeczywistej awarii.
Przydatne bieżące informacje obejmują:
-
systemctl status docker.service; -
journalctl -u docker.service; - wolne miejsce na dysku systemowym;
- niedawne nadpisania konfiguracji GPU/środowiska uruchomieniowego lub modyfikacje hosta;
- dokładną bieżącą wersję ZimaOS.
Podobny objaw może mieć inną przyczynę
W innej dyskusji dotyczącej wersji 1.4.3 zgłoszono, że Docker nie uruchamiał się, ponieważ niestandardowe nadpisanie środowiska uruchomieniowego NVIDIA pozostało w konfiguracji systemd. Jest to inna przyczyna niż problem z czasem uruchamiania opisany w tym wątku źródłowym.
Nie usuwaj plików nadpisujących konfigurację usług, chyba że dzienniki wskazują, że konkretne nadpisanie faktycznie powoduje awarię demona.
Często zadawane pytania dotyczące demona Dockera w wersji 1.4.3
Czy IceWhale oficjalnie zaleciło ręczne ponowne uruchomienie Dockera?
Tak. Zima-Giorgio opublikował systemctl restart docker docker.socket jako tymczasowe obejście w wersji 1.4.3.
Czy użytkownik źródłowy potwierdził, że to zadziałało?
Tak, podczas bieżącego uruchomienia. Problem powrócił po ponownym uruchomieniu.
Które wydanie udokumentowało poprawkę dotyczącą uruchamiania produktu?
ZimaOS 1.4.4 naprawił niewystarczający czas uruchamiania usługi Docker, który mógł powodować niepowodzenie uruchamiania.
