Gemenskapslösning

ZimaOS-appar startar inte automatiskt efter omstart: kontroller av Docker-körmiljön

After upgrading to ZimaOS 1.4.3, multiple apps could be started manually but returned to a stopped state after reboot. One contributor traced a broader Docker startup failure to an NVIDIA runtime systemd override.

Den här tråden började som ett klagomål på automatisk programstart, men ett senare svar identifierade ett djupare fel: Docker kunde själv misslyckas med att starta eftersom en systemd-override tvingade fram nvidia-container-runtime på en värd där den körvägen var inkompatibel.

Skärmbild av ZimaOS-instrumentpanelen som visar containerprogram gråtonade efter omstart på version 1.4.3
En av de ursprungliga skärmbilderna som visar program som kunde startas manuellt men inte förblev aktiva efter omstart.
ZimaOS-programlista som visar ytterligare appar som inte startade automatiskt efter uppdateringen till 1.4.3
Den ursprungliga tråden dokumenterade flera Docker-baserade program som påverkades efter uppdateringen.
Mobil vy av ZimaOS-instrumentpanelen med flera containerappar som inte körs automatiskt efter omstart
Ännu en ursprunglig skärmbild från rapporten om automatisk appstart.
ZimaOS-appinstrumentpanel som visar de berörda containrarnas tillstånd efter systemomstart på version 1.4.3
Ursprungliga bevis från communityn som visar det återkommande programtillståndet efter omstart.

Kontrollera först om Docker startar

Om flera orelaterade appar slutar fungera efter en omstart bör du kontrollera Docker-tjänsten innan du redigerar varje program. Dockers felsökning av Docker-daemonen beskriver startfel för daemonen som orsakas av motstridig konfiguration och systemd-overrides.

Kraven för ZimaOS App Store hjälper till att klargöra vilka program som är Docker-baserade, medan det första Docker-programmet beskriver det normala containerarbetsflödet i ZimaOS. Ett problem som påverkar många containrar samtidigt beror sannolikt på daemon- eller körskiktsnivå, snarare än på nio oberoende programfel.

Omstartspolicy är inte det enda lagret

Dockers omstartspolicyer förklarar vad daemonen gör med stoppade containrar. De hjälper inte om Docker-daemonen själv inte kan starta korrekt.

NVIDIA-korrigeringen var systemspecifik

En användare inaktiverade en systemd-override för Docker som uttryckligen lade till nvidia-container-runtime. Efter omstart fungerade Docker igen, men stöd för NVIDIA-GPU:er konfigurerades inte längre via den overriden.

NVIDIAs NVIDIA Container Toolkit rekommenderar för närvarande att Docker konfigureras med nvidia-ctk runtime configure --runtime=docker, varefter Docker startas om. Det är viktig bakgrundsinformation: att byta namn på en override-fil från en äldre community-tråd bör inte betraktas som det universella moderna sättet att konfigurera eller ta bort NVIDIA-körmiljön.

Kontrollera ledigt utrymme innan du ändrar systemfiler

En senare användare försökte byta namn på overriden och fick meddelandet No space left on device. Det är en annan grundorsak och måste åtgärdas först. Ändringarna i ZimaOS 1.5 ger versionssammanhang för ändringar i ZimaOS, medan felsökningsarbetsflödet för ZimaOS är användbart när ett bredare värdfel uppstår efter en uppdatering.

En säkrare felsökningsordning

  1. Kontrollera om Docker är aktivt och granska de senaste loggarna.
  2. Bekräfta att systemdisken inte är full.
  3. Kontrollera omstartspolicyerna för containrar först när daemonen fungerar korrekt.
  4. Om loggarna nämner inläsning av NVIDIA-körmiljön, granska den aktuella körmiljökonfigurationen innan du ändrar den.
  5. Säkerhetskopiera anpassade systemd-overrides innan du ändrar dem.

Sammanfattning

Källtråden bevisar inte att alla problem med automatisk appstart i ZimaOS 1.4.3 hade samma orsak. På ett system hindrade en NVIDIA-override för Docker daemonen från att starta normalt; på ett annat avslöjade det fulla systemdisken det misslyckade åtgärdsförsöket. Diagnostisera Docker-daemonen och lagringstillståndet innan du använder den historiska override-lösningen.