Wątek obejmował więcej niż jeden problem z uruchamianiem aplikacji
Po uaktualnieniu z ZimaOS 1.4.1 do wersji 1.4.2 autor oryginalnego wpisu stwierdził, że niektóre aplikacje, w tym Portainer, nie uruchamiały się automatycznie. Zasady ponownego uruchamiania Dockera, takie jak unless-stopped oraz always nie zmieniło widocznego rezultatu, natomiast kliknięcie aplikacji na pulpicie ją uruchamiało.
Inni użytkownicy zgłosili następnie powiązane, lecz odrębne objawy. Jedna grupa stwierdziła, że kontenery były już dostępne pod bezpośrednim adresem internetowym, podczas gdy pulpit ZimaOS zachowywał się tak, jakby były zatrzymane. Inna grupa później potwierdziła, że wybrane kontenery rzeczywiście nie uruchamiały się, ponieważ ścieżki woluminów opartych na SMB nie były zamontowane podczas uruchamiania aplikacji.
Przypadek pierwszy: kontener działał, ale pulpit nie mógł go otworzyć
Jeden z użytkowników udokumentował sekwencję czterech kroków. Pulpit najpierw pokazał aplikację jako zatrzymaną, a następnie ostrzegł, że może być niedostępna. Użycie wyświetlonego odnośnika otworzyło nowe okno przeglądarki, w którym aplikacja działała normalnie. Bezpośrednie wklejenie tego samego adresu i portu do przeglądarki również zadziałało.
Zespół IceWhale potraktował to zachowanie jako część dochodzenia. Wątek nie potwierdza, że zmiana zasady ponownego uruchamiania Dockera rozwiązuje problem stanu wyświetlanego na pulpicie.
Przypadek drugi: aktualizacje aplikacji i ustawienia nie działały u jednego użytkownika
Inny uczestnik korzystający z wersji 1.4.3 zgłosił krótkotrwałe błędy podczas aktualizowania Radarr i Sonarr oraz poinformował, że zmiany ustawień nie były stosowane. Ponowna instalacja aplikacji nie pomogła w tym środowisku. Później uczestnik poinformował, że zmiana serwerów lustrzanych rejestru ponownie umożliwiła zmianę ustawień, a niezależnie od tego przywrócił właściciela odpowiednich folderów aplikacji, ustawiając go zgodnie ze skonfigurowanym UID 1000.
Były to zmiany zgłoszone przez użytkowników, a nie uniwersalne rozwiązanie każdego problemu z uruchamianiem po ponownym uruchomieniu. Edycja konfiguracji demona Dockera lub rekurencyjna zmiana właściciela może wpłynąć na cały host, dlatego dowodów z wątku nie należy uogólniać poza środowisko tego uczestnika.
Przypadek trzeci: pamięć masowa SMB nie była gotowa podczas uruchamiania kontenerów
Autor oryginalnego posta później zidentyfikował konkretną przyczynę dotyczącą trzech kontenerów. Ich woluminy były mapowane na udział SMB. Dzienniki pokazały, że kontenery próbowały uruchomić się, zanim system plików SMB stał się dostępny, więc uruchomienie kończyło się niepowodzeniem i pozostawały wyłączone. Późniejsze ręczne uruchomienie działało, ponieważ udział był już wtedy zamontowany.
To wyjaśnia, dlaczego zmiana always do unless-stopped nie pomogło tym kontenerom: zasada ponownego uruchamiania nie może sprawić, że niedostępna ścieżka montowania powiązania będzie gotowa wcześniej. Istotną zależnością była gotowość pamięci masowej i kolejność uruchamiania.
Co potwierdzono w wersji 1.4.3, a czego nie potwierdzono
W odpowiedzi IceWhale poproszono użytkowników o przetestowanie wersji 1.4.3. Jeden z uczestników stwierdził, że problem z pulpitem nadal występował, natomiast autor oryginalnego posta początkowo uznał, że wersja 1.4.3 pomogła, lecz później ponownie zaobserwował problem z kolejnością uruchamiania SMB. W innej odpowiedzi zauważono, że aplikację należy najpierw uruchomić, aby usługa zarządzania aplikacjami znała jej ostatni stan działania.
Wątek nie potwierdza zatem ogólnego stwierdzenia, że wersja 1.4.3 naprawiła każdy problem z uruchamianiem występujący w wersji 1.4.2. Potwierdza natomiast podział diagnostyczny: najpierw sprawdź, czy kontener rzeczywiście jest zatrzymany, a następnie przeanalizuj jego dzienniki i zależności pamięci masowej.
FAQ
Dlaczego aplikacja otwiera się po adresie URL, ale w ZimaOS wygląda na zatrzymaną?
Ten schemat wyglądał na problem z uruchamianiem pulpitu nawigacyjnego lub raportowaniem stanu. Sama usługa mogła już działać i być dostępna pod skonfigurowanym adresem i portem.
Dlaczego po ponownym uruchomieniu zawodzą tylko kontenery korzystające z udziału SMB?
W potwierdzonym przypadku te kontenery uruchomiły się, zanim montowanie SMB było gotowe. Działały po ręcznym uruchomieniu, gdy udział stał się dostępny.
Czy zmiana zasady ponownego uruchamiania Dockera rozwiązała problem?
Nie. Autor oryginalnego posta przetestował oba always oraz unless-stopped bez rozwiązywania problemu z dotkniętymi kontenerami.
