ACLClouds
ACLClouds

Un conteneur Docker redémarre en boucle

Lire état, code de sortie, journaux et configuration Compose avant de désactiver la politique de redémarrage.

Une politique restart: unless-stopped relance immédiatement une application qui échoue. La boucle est un symptôme ; les premières lignes d’erreur restent la cause à corriger.

Procédure étape par étape

  1. Afficher tous les conteneurs

    Utilisez docker ps -a pour relever état, code de sortie et fréquence des redémarrages.

  2. Lire les journaux précédents

    Exécutez docker logs --tail 200 et recherchez variable absente, port occupé, permission ou migration échouée.

  3. Inspecter la configuration

    Vérifiez les volumes montés, les variables, le contrôle de santé (healthcheck) et les limites mémoire dans Compose.

  4. Corriger puis recréer

    Après correction, lancez docker compose up -d et surveillez l’état sans supprimer les volumes.

Diagnostic Docker

docker ps -a
docker inspect --format="{{.State.Status}} {{.State.ExitCode}} {{.State.Error}}" NOM
docker logs --tail 200 NOM
docker compose config

Suspendre la boucle et explorer l’image

docker update --restart=no NOM
docker stop NOM
docker inspect --format '{{.State.OOMKilled}} {{.RestartCount}}' NOM
docker run --rm -it --entrypoint sh IMAGE

Avant de commencer

Une boucle se reconnaît dans docker ps -a à l’état Restarting ou à un compteur qui augmente dans docker inspect --format '{{.RestartCount}}' suivi du nom du conteneur. Le code de sortie entre parenthèses oriente le diagnostic :

  • 0 : le processus principal se termine normalement, rien ne reste au premier plan.
  • 1 : erreur de l’application (configuration, variable absente, dépendance).
  • 126 ou 127 : commande non exécutable ou introuvable dans l’image.
  • 137 : arrêt par SIGKILL, souvent une limite mémoire ou l’OOM killer du VPS.

Comprendre les politiques de redémarrage

no ne relance jamais ; on-failure relance seulement après un code différent de 0 ; always relance toujours, y compris au démarrage de Docker ; unless-stopped fait de même sauf si vous avez arrêté le conteneur avec docker stop. Docker double le délai entre deux relances, jusqu’à une minute, tant que le conteneur ne tient pas 10 secondes.

Pour lire l’erreur au calme, suspendez la boucle avec docker update --restart=no puis docker stop, suivis du nom du conteneur. Remettez la politique d’origine une fois la cause corrigée.

Vérifier que tout fonctionne

Après docker compose up -d, attendez une minute : docker ps doit afficher Up depuis plus d’une minute, ou (healthy) si un healthcheck existe, et RestartCount ne doit plus augmenter. Suivez les logs avec docker compose logs -f --tail 50.

Questions fréquentes

Les logs affichent exec format error, pourquoi ?

L’image a été construite pour une autre architecture, souvent ARM (arm64) alors que le VPS est en x86-64. Reconstruisez-la avec docker build --platform linux/amd64 ou choisissez le tag amd64 de l’éditeur. Un script d’entrée enregistré avec des fins de ligne Windows provoque, lui, no such file or directory.

Le conteneur ne démarre pas avec bind: address already in use, comment corriger ?

Le port publié est déjà pris sur le VPS, souvent par un Nginx ou un Apache installé hors Docker. ss -tlnp montre le processus qui l’occupe. Arrêtez ce service ou publiez un autre port côté hôte, par exemple 8080:80 dans ports.

Une base de données boucle avec Permission denied sur son volume, que faire ?

Le dossier monté appartient à un autre utilisateur que celui de l’image. Comparez ls -ln sur le dossier avec l’utilisateur du conteneur, souvent l’UID 999 pour les images officielles PostgreSQL et MySQL, puis corrigez avec chown -R 999:999 suivi du chemin. Ne supprimez pas le volume pour repartir de zéro sans sauvegarde.