Ce sujet source aboutit à une conclusion solide et spécifique à la version. Après la mise à niveau d’un ZimaBoard 832 vers ZimaOS 1.4.3, Docker ne démarrait pas automatiquement, l’App Store ne pouvait pas installer de nouvelles applications et les applications existantes ne pouvaient pas se lancer. Zima-Giorgio a indiqué que l’équipe était au courant du problème du service Docker et a fourni une commande de redémarrage manuel temporaire.
L’auteur du sujet a confirmé que la commande de redémarrage résolvait le problème immédiat, mais a également indiqué que Docker échouait de nouveau après chaque redémarrage de l’hôte. La version suivante d’IceWhale apporte l’élément déterminant : ZimaOS 1.4.4 a officiellement corrigé un échec du démarrage de Docker causé par un intervalle de démarrage du service insuffisant.
L’échec est apparu immédiatement après la mise à niveau vers la version 1.4.3
L’utilisateur à l’origine du signalement a indiqué :
- la mise à jour de Prowlarr restait bloquée ;
- les applications existantes ne se lançaient pas ;
- les nouvelles installations depuis l’App Store échouaient ;
- l’interface indiquait qu’elle ne pouvait pas se connecter au démon Docker.
/var/run/docker.sock, bloquant l’installation et le démarrage des applications.IceWhale l’a qualifié de problème connu du service Docker
Le 26 août, Zima-Giorgio a écrit que l’équipe considérait cela comme un problème connu du service Docker et qu’un correctif serait publié.
Il a fourni la solution de contournement officielle temporaire suivante :
sudo -i
systemctl restart docker docker.socketCette commande constitue une recommandation historique valide d’IceWhale pour le cas source de la version 1.4.3.
L’auteur du sujet a confirmé que le redémarrage manuel de Docker fonctionnait
L’utilisateur a répondu que le redémarrage de Docker en tant que root via l’interface de ligne de commande avait complètement résolu le problème immédiat. Il s’agit d’une réussite confirmée par la source, et non d’une solution de contournement spéculative.
Cependant, le même utilisateur a ensuite redémarré le ZimaBoard et constaté que Docker ne parvenait de nouveau pas à démarrer automatiquement.
Le tableau de bord pouvait afficher les applications comme démarrées alors que Docker ne fonctionnait pas correctement
Le redémarrage de Docker a rétabli l’état réel de l’application
Le redémarrage manuel des applications n’a pas résolu de manière fiable le problème au redémarrage suivant
Zima-Giorgio a indiqué que certains rapports suggéraient que le démarrage et le redémarrage manuels de chaque application pourraient améliorer les démarrages suivants. L’auteur de la publication originale a testé cette idée, mais a tout de même constaté le même faux état de démarrage après le redémarrage.
Cela montre qu’il est important de ne pas présenter le redémarrage de chaque application comme la correction définitive de la source.
ZimaOS 1.4.4 a corrigé le problème de délai de démarrage de Docker
Les notes de version officielles d’IceWhale pour la version 1.4.4 incluent :
- une correction des applications qui restaient bloquées en chargement après le démarrage ;
- une correction du délai de démarrage du service Docker, qui était insuffisant et provoquait un échec au démarrage ;
- des corrections supplémentaires concernant l’état des applications et les cartes d’installation.
Consultez les corrections du démarrage de Docker de ZimaOS 1.4.4 pour connaître la résolution historique du produit.
Les utilisateurs actuels ne doivent pas considérer systemctl restart comme la solution permanente
Sur une version moderne de ZimaOS, un daemon Docker qui échoue à plusieurs reprises après un redémarrage indique un problème actuel lié au service, au stockage, au runtime ou à la configuration. Redémarrer Docker peut servir à établir un diagnostic, mais recueillez la véritable cause de l’échec avant de normaliser un redémarrage manuel à chaque démarrage.
Les éléments actuels utiles comprennent :
-
systemctl status docker.service; -
journalctl -u docker.service; - l’espace libre sur le disque système ;
- les récentes surcharges du GPU/runtime ou modifications de l’hôte ;
- la version exacte actuelle de ZimaOS.
Un symptôme similaire peut avoir une cause différente
Une autre discussion sur la version 1.4.3 a signalé que Docker échouait parce qu’une surcharge personnalisée du runtime NVIDIA était toujours présente dans la configuration systemd. Il s’agit d’une cause différente du problème de délai de démarrage évoqué dans ce fil source.
Ne supprimez pas les fichiers de surcharge des services, sauf si les journaux montrent qu’une surcharge spécifique empêche réellement le daemon de fonctionner.
FAQ sur le daemon Docker 1.4.3
IceWhale a-t-elle officiellement fourni une commande de redémarrage manuel de Docker ?
Oui. Zima-Giorgio a publié systemctl restart docker docker.socket comme solution temporaire de la version 1.4.3.
L’utilisateur à l’origine de la source a-t-il confirmé que cela fonctionnait ?
Oui, pour le démarrage en cours. L’échec est réapparu après le redémarrage.
Quelle version a documenté la correction du démarrage au niveau du produit ?
ZimaOS 1.4.4 a corrigé un délai de démarrage insuffisant du service Docker, qui pouvait entraîner un échec au démarrage.
