Le fil concernait plusieurs problèmes de démarrage des applications
Après la mise à niveau de ZimaOS 1.4.1 vers 1.4.2, l’auteur du message initial a constaté que certaines applications, dont Portainer, ne semblaient pas démarrer automatiquement. Les politiques de redémarrage Docker telles que sauf arrêt explicite toujours toujours n’a pas modifié le résultat visible, tandis que cliquer sur l’application dans le tableau de bord la démarrait.
D’autres utilisateurs ont ensuite signalé des symptômes similaires, mais distincts. Un groupe a constaté que les conteneurs étaient déjà accessibles via leur adresse web directe, tandis que le tableau de bord ZimaOS se comportait comme s’ils étaient arrêtés. Un autre utilisateur a ensuite confirmé que certains conteneurs ne fonctionnaient réellement pas, car les chemins de volumes reposant sur SMB n’étaient pas montés au démarrage de l’application.
Premier cas : le conteneur fonctionnait, mais le tableau de bord ne pouvait pas l’ouvrir
Un utilisateur a documenté une séquence en quatre étapes. Le tableau de bord a d’abord présenté l’application comme arrêtée, puis a indiqué qu’elle pourrait être indisponible. Le lien proposé a ouvert une nouvelle fenêtre de navigateur dans laquelle l’application fonctionnait normalement. Saisir directement la même adresse et le même port dans le navigateur fonctionnait également.
L’équipe IceWhale a traité ce comportement dans le cadre de l’enquête. Le fil ne permet pas d’établir que la modification d’une politique de redémarrage Docker corrige ce problème d’état du tableau de bord.
Deuxième cas : mises à jour des applications et paramètres impossibles pour un utilisateur
Un autre participant utilisant la version 1.4.3 a signalé de brèves erreurs lors de la mise à jour de Radarr et Sonarr, et indiqué que les modifications des paramètres n’étaient pas appliquées. Réinstaller les applications n’a rien changé dans cet environnement. Le participant a ensuite indiqué que le changement de miroirs de registre permettait à nouveau de modifier les paramètres, et a séparément rétabli la propriété des dossiers d’applications concernés pour qu’elle corresponde à l’UID configuré 1000.
Il s’agissait de modifications signalées par des utilisateurs, et non d’une solution universelle à tous les échecs après redémarrage. La modification de la configuration du démon Docker ou le changement récursif des propriétaires peut affecter l’ensemble de l’hôte ; les éléments de la discussion ne doivent donc pas être généralisés au-delà de l’environnement du participant.
Cas trois : le stockage SMB n’était pas prêt au démarrage des conteneurs
L’auteur du message original a ensuite identifié une cause concrète pour trois conteneurs. Leurs volumes étaient associés à un partage SMB. Les journaux montraient que les conteneurs tentaient de démarrer avant que le système de fichiers SMB soit disponible, échouaient, puis restaient à l’arrêt. Les démarrer manuellement plus tard fonctionnait, car le partage était alors monté.
Cela explique pourquoi la modification de toujours vers sauf arrêt explicite n’a pas aidé ces conteneurs : une politique de redémarrage ne peut pas rendre disponible plus tôt un chemin de montage indisponible. La dépendance concernait la disponibilité du stockage et l’ordre de démarrage.
Ce que la version 1.4.3 a confirmé et n’a pas confirmé
Une réponse d’IceWhale a demandé aux utilisateurs de tester la version 1.4.3. Un participant a indiqué que le comportement du tableau de bord persistait, tandis que l’auteur du message original a d’abord pensé que la version 1.4.3 avait aidé, avant de reproduire plus tard l’échec lié à l’ordre de démarrage SMB. Une autre réponse a précisé qu’une application doit d’abord être démarrée pour que le service de gestion des applications connaisse son dernier état d’exécution.
La discussion ne permet donc pas d’affirmer que la version 1.4.3 a corrigé tous les problèmes de démarrage de la version 1.4.2. Elle suggère plutôt une démarche de diagnostic en deux étapes : vérifier d’abord si le conteneur est réellement arrêté, puis examiner ses journaux et ses dépendances de stockage.
FAQ
Pourquoi une application s’ouvre-t-elle via son URL, mais semble-t-elle arrêtée dans ZimaOS ?
Ce comportement s’est avéré être un problème de lancement du tableau de bord ou de signalement de l’état. Le service lui-même pouvait déjà être en cours d’exécution et accessible à l’adresse et au port configurés.
Pourquoi seuls les conteneurs utilisant un partage SMB échouent-ils après un redémarrage ?
Dans le cas confirmé, ces conteneurs ont démarré avant que le montage SMB soit prêt. Ils fonctionnaient lorsqu’ils étaient démarrés manuellement après l’apparition du partage.
Le changement de la politique de redémarrage de Docker a-t-il résolu le problème ?
Non. L’auteur du message original a testé les deux. toujours toujours sauf arrêt explicite sans résoudre les conteneurs concernés.
