Le démon Docker ne démarre pas : lisez d’abord ce journal (puis réparez-le)

janvier 21, 2026 • février 3, 2026 • Lecture : 30 min • Views: 2

Cet article vous a aidé ?

Quand le démon Docker ne démarre pas, votre hôte devient une pièce de musée : des conteneurs figés dans le temps, des tâches CI bloquées, des déploiements qui font marche arrière, et quelqu’un qui demande « on peut juste reboot ? ». Vous pouvez redémarrer, bien sûr. Vous pouvez aussi mettre un ordinateur portable mouillé au micro-ondes. Aucun des deux n’est une stratégie.

Le chemin le plus rapide pour s’en sortir n’est pas une suite aléatoire de redémarrages. C’est une lecture propre du bon journal, suivie d’un petit nombre de commandes délibérées qui vous disent ce qui a cassé : config, stockage, fonctionnalités du noyau, règles réseau, permissions, ou containerd.

Jouer le diagnostic rapide (quoi vérifier en premier)

Si vous n’avez que cinq minutes et un pager qui vibre contre vos molaires, faites ceci dans l’ordre. L’objectif est d’identifier rapidement la classe du goulot : échec d’analyse de la config, dépendance runtime en panne, corruption/capacité du stockage, incompatibilité des fonctionnalités noyau, ou échec des règles réseau.

Premier point : systemd dit pourquoi il a refusé de garder Docker vivant

Docker est généralement géré par systemd. systemd a le premier avis qui compte : le code de sortie et stderr immédiat.

cr0x@server:~$ systemctl status docker --no-pager -l
● docker.service - Docker Application Container Engine
     Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Tue 2026-01-02 10:12:54 UTC; 17s ago
    Process: 1842 ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock (code=exited, status=1/FAILURE)
   Main PID: 1842 (code=exited, status=1/FAILURE)
        CPU: 230ms

Jan 02 10:12:54 server dockerd[1842]: failed to start daemon: error initializing graphdriver: overlay2: failed to mount /var/lib/docker/overlay2: invalid argument
Jan 02 10:12:54 server systemd[1]: docker.service: Main process exited, code=exited, status=1/FAILURE
Jan 02 10:12:54 server systemd[1]: docker.service: Failed with result 'exit-code'.
Jan 02 10:12:54 server systemd[1]: Failed to start Docker Application Container Engine.

Décision : Prenez au sérieux la première ligne failed to start daemon:. C’est généralement la classe de cause racine. Ici elle crie « overlay2 mount invalid argument » → incompatibilité noyau/système de fichiers/overlayfs, pas un « bug Docker ».

Second point : journalctl pour Docker donne la pile complète, pas seulement le titre

cr0x@server:~$ journalctl -u docker -b --no-pager -n 200
Jan 02 10:12:54 server dockerd[1842]: time="2026-01-02T10:12:54.118922635Z" level=info msg="Starting up"
Jan 02 10:12:54 server dockerd[1842]: time="2026-01-02T10:12:54.152001115Z" level=error msg="failed to mount overlay: invalid argument" storage-driver=overlay2
Jan 02 10:12:54 server dockerd[1842]: time="2026-01-02T10:12:54.152114935Z" level=fatal msg="Error starting daemon: error initializing graphdriver: overlay2: failed to mount /var/lib/docker/overlay2: invalid argument"

Décision : Si vous voyez level=fatal suivi d’un sous-système concret (graphdriver, iptables, daemon.json), arrêtez de deviner. Orientez-vous vers les vérifications de ce sous-système.

Troisième point : vérifier la capacité et le système de fichiers sous /var/lib/docker

Un disque plein et une pénurie d’inodes ne s’annoncent pas toujours poliment. Ils font simplement que les daemons se comportent comme s’ils avaient oublié comment écrire.

cr0x@server:~$ df -h /var/lib/docker
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p4   80G   79G  300M 100% /

cr0x@server:~$ df -i /var/lib/docker
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/nvme0n1p4   5.0M   5.0M       0  100% /

Décision : Si soit les blocs soit les inodes sont à 100%, votre « Docker ne démarre pas » est un incident de stockage. Libérez de l’espace d’abord ; ne changez pas de driver, ne réinstallez pas de paquets ni ne « réinitialisez Docker » tant que l’hôte ne peut pas écrire.

Quatrième point : valider la config du démon avant de courir après des fantômes

Une virgule finale en JSON peut faire tomber toute votre plateforme de conteneurs. J’aimerais que ce soit une blague. Ce n’est pas le cas.

cr0x@server:~$ sudo cat /etc/docker/daemon.json
{
  "log-driver": "json-file",
  "log-opts": { "max-size": "10m", },
  "iptables": true
}

Décision : Cette virgule après "10m" empêchera dockerd de démarrer. Corrigez le JSON, puis redémarrez. Ne touchez rien d’autre.

Cinquième point : vérifier que containerd est vivant (ou confirmer qu’il ne l’est pas)

cr0x@server:~$ systemctl status containerd --no-pager -l
● containerd.service - containerd container runtime
     Loaded: loaded (/lib/systemd/system/containerd.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2026-01-02 10:08:11 UTC; 6min ago
       Docs: man:containerd(8)
   Main PID: 1210 (containerd)

Décision : Si containerd est arrêté, Docker peut échouer avec une erreur de socket ou runtime. Réparez containerd d’abord. Si containerd est sain, poursuivez.

Le journal unique à lire d’abord (et pourquoi)

Lisez le journal systemd pour l’unité docker avant de lire quoi que ce soit d’autre. Pas parce que c’est joli, mais parce que c’est la source d’autorité. Il capture :

Pourquoi systemd a arrêté de redémarrer le service (limites de démarrage atteintes, crash loops).
Exactement ce que dockerd a imprimé sur stderr/stdout.
Le timing par rapport aux autres services (containerd, réseau, montages).

Sur la plupart des distributions modernes, voici la commande clé :

cr0x@server:~$ journalctl -u docker -b --no-pager -o cat
time="2026-01-02T10:12:54.118922635Z" level=info msg="Starting up"
time="2026-01-02T10:12:54.152114935Z" level=fatal msg="Error starting daemon: failed to load listeners: can't create unix socket /var/run/docker.sock: permission denied"

Décision : Cette erreur n’est pas un problème « Docker ne peut pas parler à Docker ». C’est une question de permissions/possession/SELinux/AppArmor sur le chemin du socket (ou son parent). Vous savez maintenant dans quelle classe d’échec vous êtes.

Ne commencez pas par /var/log/docker.log à moins que vous ne soyez sur un système qui y journalise explicitement. Beaucoup d’installations n’y journalisent pas. Ne commencez pas par des correctifs aléatoires trouvés sur Stack Overflow. Votre système vous a déjà dit ce qui ne va pas ; vous ne l’avez simplement pas encore écouté.

Faits et histoire intéressants (pour comprendre les erreurs)

Docker utilisait originellement LXC (Linux Containers) pour l’isolation avant de passer à libcontainer, ce qui a changé la façon dont les fonctionnalités bas-niveau du noyau étaient consommées.
containerd a été extrait de Docker pour que le runtime de base puisse évoluer indépendamment ; c’est pour cela qu’« Docker est down » peut en réalité signifier « containerd est down ».
overlay2 est devenu le driver par défaut sur de nombreuses distributions parce qu’il est rapide et économe en espace, mais il est exigeant sur les fonctionnalités du système de fichiers (surtout sur les noyaux anciens).
L’intégration d’iptables n’est pas optionnelle pour le réseau Docker classique ; quand firewalld/nftables/iptables sont en désaccord, Docker peut échouer au démarrage, pas seulement à l’exécution des conteneurs.
L’adoption de cgroups v2 a modifié la plomberie du contrôle de ressources ; les anciennes versions de Docker sur de nouvelles distributions peuvent échouer tôt à cause de mismatches de driver cgroup.
Les paramètres de journalisation par défaut de Docker (json-file) peuvent remplir les disques en silence ; le démon qui ne démarre plus après un événement disque plein est souvent auto-infligé par la croissance des logs.
Le comportement de start-limit est une fonctionnalité de systemd : après des échecs répétés, il arrête d’essayer. Les opérateurs interprètent souvent cela comme « Docker est gelé ».
/var/lib/docker n’est pas sacré ; c’est juste l’état. Il contient images, couches, métadonnées et volumes (selon la config). Il peut être migré, mais le faire à la légère est la meilleure façon de gagner du travail le week-end.
Rootless Docker existe pour réduire les privilèges du démon, mais il ajoute une classe distincte d’échecs autour des services utilisateur, XDG_RUNTIME_DIR, et la délégation des cgroups.

Tâches pratiques : commandes, sorties et décisions à prendre

Vous ne réparez pas Docker en répétant « restart ». Vous réparez Docker en collectant un petit ensemble de faits et en prenant une décision après chacun d’eux. Ci‑dessous les tâches que j’ai utilisées dans de vrais incidents, avec des sorties réalistes et leur signification.

Tâche 1 : Confirmer l’état de l’unité et la dernière raison d’échec

cr0x@server:~$ systemctl is-enabled docker; systemctl is-active docker; systemctl status docker --no-pager -l
enabled
failed
● docker.service - Docker Application Container Engine
     Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Tue 2026-01-02 10:12:54 UTC; 2min 11s ago
    Process: 1842 ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock (code=exited, status=1/FAILURE)
Jan 02 10:12:54 server dockerd[1842]: failed to start daemon: Error initializing network controller: failed to create NAT chain DOCKER: iptables failed

Décision : Si l’échec pointe vers le contrôleur réseau / iptables, ne perdez pas de temps sur des vérifications de stockage d’abord. Passez directement à la section iptables/nftables.

Tâche 2 : Récupérer les journaux complets pour le boot concernant docker

cr0x@server:~$ journalctl -u docker -b --no-pager -n 300
Jan 02 10:12:54 server dockerd[1842]: time="2026-01-02T10:12:54Z" level=info msg="Starting up"
Jan 02 10:12:54 server dockerd[1842]: time="2026-01-02T10:12:54Z" level=info msg="libcontainerd: started new containerd process" pid=1901
Jan 02 10:12:54 server dockerd[1842]: time="2026-01-02T10:12:54Z" level=error msg="iptables failed: iptables -t nat -N DOCKER: iptables v1.8.7 (nf_tables): Chain already exists."
Jan 02 10:12:54 server dockerd[1842]: time="2026-01-02T10:12:54Z" level=fatal msg="Error starting daemon: Error initializing network controller: iptables failed"

Décision : « Chain already exists » suggère des règles obsolètes d’un run précédent ou un conflit avec le backend nftables. Vous êtes dans le mode d’échec des règles réseau.

Tâche 3 : Vérifier si systemd vous limite les démarrages

cr0x@server:~$ systemctl status docker --no-pager -l | sed -n '1,25p'
● docker.service - Docker Application Container Engine
     Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
     Active: failed (Result: start-limit-hit) since Tue 2026-01-02 10:13:09 UTC; 18s ago
Jan 02 10:13:09 server systemd[1]: docker.service: Start request repeated too quickly.
Jan 02 10:13:09 server systemd[1]: docker.service: Failed with result 'start-limit-hit'.

Décision : Réinitialisez la limite de démarrage après avoir corrigé le problème sous-jacent ; sinon vous « réparerez » et il sera toujours refusé.

cr0x@server:~$ sudo systemctl reset-failed docker

Tâche 4 : Valider /etc/docker/daemon.json sans faire confiance à vos yeux

cr0x@server:~$ sudo python3 -m json.tool /etc/docker/daemon.json
Expecting property name enclosed in double quotes: line 3 column 36 (char 61)

Décision : Corrigez la syntaxe JSON d’abord. Si cela échoue, Docker ne démarrera pas. Point final. Après correction, relancez le validateur jusqu’à ce qu’il affiche le JSON formaté et sorte avec le code 0.

Tâche 5 : Extraire la ligne de commande effective de Docker (les drop-ins importent)

cr0x@server:~$ systemctl cat docker --no-pager
# /lib/systemd/system/docker.service
[Service]
ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock

# /etc/systemd/system/docker.service.d/override.conf
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H fd:// --data-root /mnt/docker-data --storage-driver=overlay2

Décision : Si vous voyez des overrides, considérez-les suspects jusqu’à preuve du contraire. Beaucoup d’incidents « Docker cassé après mise à jour » sont en réalité « ancien override rencontre nouveaux paramètres par défaut ».

Tâche 6 : Vérifier le montage data-root de Docker et le type de système de fichiers

cr0x@server:~$ findmnt -no SOURCE,FSTYPE,OPTIONS /var/lib/docker
/dev/nvme0n1p4 ext4 rw,relatime

cr0x@server:~$ findmnt -no SOURCE,FSTYPE,OPTIONS /mnt/docker-data
/dev/sdb1 xfs rw,relatime,attr2,inode64,logbufs=8,logbsize=32k

Décision : Overlay2 sur XFS exige généralement ftype=1. Si vous avez migré les données Docker vers un XFS formaté anciennement avec ftype=0, overlay2 échouera.

Tâche 7 : Vérifier ftype d’XFS (critique pour overlay2 sur XFS)

cr0x@server:~$ sudo xfs_info /dev/sdb1 | grep ftype
naming   =version 2              bsize=4096   ascii-ci=0, ftype=0

Décision : ftype=0 est un arrêt net pour overlay2. La solution consiste à reformater avec ftype=1 (migration des données requise) ou à changer de driver de stockage (généralement une mauvaise journée). Ne continuez pas à réessayer sans l’avoir résolu.

Tâche 8 : Vérifier la prise en charge du noyau pour overlayfs (et repérer les causes de « invalid argument »)

cr0x@server:~$ uname -r
4.15.0-213-generic

cr0x@server:~$ lsmod | grep overlay
overlay               102400  0

cr0x@server:~$ sudo dmesg -T | tail -n 20
[Mon Jan  2 10:12:54 2026] overlayfs: filesystem on '/var/lib/docker/overlay2' not supported as upperdir

Décision : Cette ligne dans dmesg vous indique que le noyau a rejeté le système de fichiers sous-jacent comme upperdir pour overlay (commun avec certains systèmes de fichiers réseau, des chemins mal montés, ou des options non supportées). Corrigez le montage/le système de fichiers ; Docker ne peut pas le masquer.

Tâche 9 : Confirmer le socket containerd et sa santé

cr0x@server:~$ ls -l /run/containerd/containerd.sock
srw-rw---- 1 root root 0 Jan  2 10:08 /run/containerd/containerd.sock

cr0x@server:~$ systemctl status containerd --no-pager -l | sed -n '1,15p'
● containerd.service - containerd container runtime
     Active: active (running) since Tue 2026-01-02 10:08:11 UTC; 6min ago

Décision : Si le socket manque ou si containerd échoue, réparez containerd avant Docker. Si containerd est OK, l’erreur de Docker se trouve ailleurs.

Tâche 10 : Chercher des refus de permission évidents (SELinux/AppArmor apparaissent ici)

cr0x@server:~$ sudo journalctl -b --no-pager | grep -E 'DENIED|apparmor="DENIED"|avc:'
Jan 02 10:12:54 server kernel: audit: type=1400 apparmor="DENIED" operation="create" profile="docker-default" name="/var/run/docker.sock" pid=1842 comm="dockerd"

Décision : Si vous voyez des refus explicites, arrêtez de traiter ça comme un problème de config Docker. Corrigez la politique/le profil ou le contexte de fichier. Lancer Docker en « désactivant simplement la sécurité » est la façon dont un incident devient une brèche.

Tâche 11 : Inspecter le mismatch du backend iptables (iptables vs nft)

cr0x@server:~$ sudo iptables --version
iptables v1.8.7 (nf_tables)

cr0x@server:~$ sudo iptables -t nat -S | sed -n '1,25p'
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-N DOCKER
-N DOCKER-ISOLATION-STAGE-1
-N DOCKER-ISOLATION-STAGE-2

Décision : Si Docker se plaint de chaînes existantes, vous pouvez avoir des gestionnaires de règles en conflit (firewalld, kube-proxy, scripts custom). Décidez qui possède les règles. En cas d’urgence, videz uniquement les chaînes gérées par Docker avec précaution—après avoir compris le rayon d’impact.

Tâche 12 : Confirmer le mode cgroup et un éventuel mismatch de driver

cr0x@server:~$ mount | grep cgroup2
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime)

cr0x@server:~$ journalctl -u docker -b --no-pager | grep -i cgroup | tail -n 5
Jan 02 10:12:54 server dockerd[1842]: time="2026-01-02T10:12:54Z" level=fatal msg="Error starting daemon: Devices cgroup isn't mounted"

Décision : Cela indique souvent une ancienne build de Docker ou une mauvaise configuration pour cgroups v2. La solution est d’aligner les versions (mettre à jour Docker) ou de configurer le driver/mode cgroup correct pour votre distro. Ne contournez pas en désactivant le contrôle des ressources sauf si vous aimez la roulette des performances.

Tâche 13 : Chercher corruption ou écritures partielles après des coupures

cr0x@server:~$ journalctl -u docker -b --no-pager | tail -n 20
Jan 02 10:12:54 server dockerd[1842]: time="2026-01-02T10:12:54Z" level=error msg="failed to load container metadata" error="unexpected end of JSON input"
Jan 02 10:12:54 server dockerd[1842]: time="2026-01-02T10:12:54Z" level=fatal msg="Error starting daemon: error while opening volume store metadata database"

Décision : La corruption de métadonnées est réelle. Vous décidez maintenant : restaurer depuis une sauvegarde, supprimer chirurgicalement l’objet corrompu, ou reconstruire l’état Docker. Votre choix dépend de la tolérance à perdre images/volumes locaux.

Tâche 14 : Lancer dockerd en « dry-run » directement (utile quand systemd cache stderr)

cr0x@server:~$ sudo dockerd --debug --validate --config-file=/etc/docker/daemon.json
unable to configure the Docker daemon with file /etc/docker/daemon.json: the following directives are specified both as a flag and in the configuration file: hosts

Décision : Vous avez des sources de config en conflit (flags systemd ExecStart vs daemon.json). Enlevez une source de vérité. En production, je préfère laisser hosts à systemd et garder daemon.json pour les paramètres du démon, pas pour les listeners.

Tâche 15 : Vérifier les conflits de ports (commun avec d’anciens flags dockerd)

cr0x@server:~$ sudo ss -ltnp | grep -E ':2375|:2376' || true
LISTEN 0      4096         0.0.0.0:2375      0.0.0.0:*    users:(("dockerd",pid=902,fd=7))

Décision : Si un ancien processus dockerd est toujours lié (ou un autre service), votre nouveau démon ne peut pas binder. Tuez le processus errant proprement, puis corrigez l’unité pour ne pas lancer plusieurs daemons.

Tâche 16 : Libérer de l’espace en sécurité sans tout détruire

cr0x@server:~$ sudo du -sh /var/lib/docker/* 2>/dev/null | sort -h | tail -n 10
2.1G	/var/lib/docker/containers
12G	/var/lib/docker/overlay2
18G	/var/lib/docker/volumes

cr0x@server:~$ sudo find /var/lib/docker/containers -name '*-json.log' -size +200M -printf '%p %s\n' | head
/var/lib/docker/containers/2f3.../2f3...-json.log 987654321

Décision : Si les logs des conteneurs sont en cause, tronquez-les plutôt que de supprimer les répertoires des conteneurs.

cr0x@server:~$ sudo truncate -s 0 /var/lib/docker/containers/2f3.../2f3...-json.log

Décision : Faites démarrer le démon d’abord, puis implémentez correctement la rotation des logs. Disque plein = outage ; l’hygiène parfaite peut attendre une heure.

Les grands modes de défaillance (à quoi ils ressemblent dans les journaux)

Les échecs de démarrage du démon Docker se regroupent en quelques catégories. Reconnaître la catégorie réduit déjà de moitié l’incident.