Ce fil a commencé par une réclamation concernant le démarrage automatique des applications, mais une réponse ultérieure a mis en évidence un problème plus profond : Docker lui-même pouvait ne pas démarrer, car une surcharge systemd imposait nvidia-container-runtime sur un hôte où ce chemin d’exécution était incompatible.
Vérifiez d’abord si Docker démarre
Si plusieurs applications sans lien entre elles cessent toutes de fonctionner après un redémarrage, examinez le service Docker avant de modifier chaque application. La documentation de dépannage du daemon Docker décrit les échecs de démarrage du daemon causés par des configurations contradictoires et des surcharges systemd.
Les exigences de l’App Store ZimaOS permettent de déterminer quelles applications sont basées sur Docker, tandis que la page première application Docker présente le workflow habituel des conteneurs ZimaOS. Un problème qui affecte simultanément de nombreux conteneurs provient plus probablement du daemon ou de la couche d’exécution que de neuf bugs d’application indépendants.
La politique de redémarrage n’est pas la seule couche concernée
Les politiques de redémarrage Docker expliquent ce que le daemon fait avec les conteneurs arrêtés. Elles ne sont d’aucune aide si le daemon Docker lui-même ne peut pas démarrer correctement.
La correction liée à l’environnement NVIDIA était propre au système
Un contributeur a désactivé une surcharge systemd de Docker qui ajoutait explicitement nvidia-container-runtime. Après le redémarrage, Docker fonctionnait de nouveau, mais la prise en charge du GPU NVIDIA n’était plus configurée par cette surcharge.
La documentation de NVIDIA Container Toolkit recommande actuellement de configurer Docker avec nvidia-ctk runtime configure --runtime=docker, puis de redémarrer Docker. Ce contexte est important : renommer un fichier de surcharge issu d’un ancien fil communautaire ne doit pas être considéré comme la méthode moderne universelle pour configurer ou supprimer l’environnement d’exécution NVIDIA.
Vérifiez l’espace libre avant de modifier les fichiers système
Un utilisateur ultérieur a essayé de renommer la surcharge et a reçu No space left on device. Il s’agit d’une autre cause racine, qui doit être résolue en premier. La page changements de ZimaOS 1.5 fournit le contexte des évolutions de ZimaOS, tandis que le workflow de dépannage de ZimaOS est utile lorsqu’un problème plus général au niveau de l’hôte survient après une mise à jour.
Un ordre de diagnostic plus sûr
- Vérifiez si Docker est actif et examinez ses journaux récents.
- Vérifiez que le disque système n’est pas plein.
- Ne vérifiez les politiques de redémarrage des conteneurs qu’une fois le daemon en bon état.
- Si les journaux mentionnent le chargement de l’environnement d’exécution NVIDIA, examinez la configuration actuelle de l’environnement d’exécution avant de la modifier.
- Sauvegardez toute surcharge systemd personnalisée avant de la modifier.
En résumé
Le fil d’origine ne prouve pas que tous les problèmes de démarrage automatique de ZimaOS 1.4.3 avaient la même cause. Sur un système, une surcharge de l’environnement d’exécution NVIDIA pour Docker empêchait le daemon de démarrer normalement ; sur un autre, la tentative de correction a révélé que le disque système était plein. Diagnostiquez le daemon Docker et l’état du stockage avant d’appliquer la solution historique liée à la surcharge.
