Le conteneur du docker ne démarre pas après le redémarrage du docker Deamon

Question

J'utilise Ubuntu 16.04 avec docker 1.11.2. J'ai configuré systemd pour redémarrer automatiquement le démon docker. Lorsque je tue le démon docker, le démon docker redémarre, mais le conteneur n'a même pas le paramètre RestartPolicy défini sur always. À partir des journaux, je peux lire qu'il n'a pas réussi à créer le répertoire car il existe. Je pense personnellement que cela a lié à l'arrêt de containerd.

Toute aide serait appréciée.

Aug 25 19:20:19 api-31 systemd[1]: docker.service: Main process exited, code=killed, status=9/KILL 
Aug 25 19:20:19 api-31 docker[17617]: time="2016-08-25T19:20:19Z" level=info msg="stopping containerd after receiving terminated" 
Aug 25 19:21:49 api-31 systemd[1]: docker.service: State 'stop-sigterm' timed out. Killing. 
Aug 25 19:21:49 api-31 systemd[1]: docker.service: Unit entered failed state. 
Aug 25 19:21:49 api-31 systemd[1]: docker.service: Failed with result 'timeout'. 
Aug 25 19:21:49 api-31 systemd[1]: docker.service: Service hold-off time over, scheduling restart. 
Aug 25 19:21:49 api-31 systemd[1]: Stopped Docker Application Container Engine. 
Aug 25 19:21:49 api-31 systemd[1]: Closed Docker Socket for the API. 
Aug 25 19:21:49 api-31 systemd[1]: Stopping Docker Socket for the API. 
Aug 25 19:21:49 api-31 systemd[1]: Starting Docker Socket for the API. 
Aug 25 19:21:49 api-31 systemd[1]: Listening on Docker Socket for the API. 
Aug 25 19:21:49 api-31 systemd[1]: Starting Docker Application Container Engine... 
Aug 25 19:21:49 api-31 docker[19023]: time="2016-08-25T19:21:49.913162167Z" level=info msg="New containerd process, pid: 19029\n" 
Aug 25 19:21:50 api-31 kernel: [87066.742831] audit: type=1400 audit(1472152910.946:23): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="docker-default" pid=19043 comm="apparmor_parser" 
Aug 25 19:21:50 api-31 docker[19023]: time="2016-08-25T19:21:50.952073973Z" level=info msg="[graphdriver] using prior storage driver \"overlay\"" 
Aug 25 19:21:50 api-31 docker[19023]: time="2016-08-25T19:21:50.956693893Z" level=info msg="Graph migration to content-addressability took 0.00 seconds" 
Aug 25 19:21:50 api-31 docker[19023]: time="2016-08-25T19:21:50.961641996Z" level=info msg="Firewalld running: false" 
Aug 25 19:21:51 api-31 docker[19023]: time="2016-08-25T19:21:51.016582850Z" level=info msg="Removing stale sandbox 66ef9e1af997a1090fac0c89bf96c2631bea32fbe3c238c4349472987957c596 (547bceaad5d121444ddc6effbac3f472d0c232d693d8cc076027e238cf253613)" 
Aug 25 19:21:51 api-31 docker[19023]: time="2016-08-25T19:21:51.046227326Z" level=info msg="Default bridge (docker0) is assigned with an IP address 172.17.0.0/16. Daemon option --bip can be used to set a preferred IP address" 
Aug 25 19:21:51 api-31 docker[19023]: time="2016-08-25T19:21:51.081106790Z" level=warning msg="Your kernel does not support swap memory limit." 
Aug 25 19:21:51 api-31 docker[19023]: time="2016-08-25T19:21:51.081650610Z" level=info msg="Loading containers: start." 
Aug 25 19:22:01 api-31 kernel: [87076.922492] docker0: port 1(vethbbc1192) entered disabled state 
Aug 25 19:22:01 api-31 kernel: [87076.927128] device vethbbc1192 left promiscuous mode 
Aug 25 19:22:01 api-31 kernel: [87076.927131] docker0: port 1(vethbbc1192) entered disabled state 
Aug 25 19:22:03 api-31 docker[19023]: .time="2016-08-25T19:22:03.085800458Z" level=warning msg="error locating sandbox id 66ef9e1af997a1090fac0c89bf96c2631bea32fbe3c238c4349472987957c596: sandbox 66ef9e1af997a1090fac0c89bf96c2631bea32fbe3c238c4349472987957c596 not found" 
Aug 25 19:22:03 api-31 docker[19023]: time="2016-08-25T19:22:03.085907328Z" level=warning msg="failed to cleanup ipc mounts:\nfailed to umount /var/lib/docker/containers/547bceaad5d121444ddc6effbac3f472d0c232d693d8cc076027e238cf253613/shm: invalid argument" 
Aug 25 19:22:03 api-31 kernel: [87078.882836] device veth5c6999c entered promiscuous mode 
Aug 25 19:22:03 api-31 kernel: [87078.882984] IPv6: ADDRCONF(NETDEV_UP): veth5c6999c: link is not ready 
Aug 25 19:22:03 api-31 systemd-udevd[19128]: Could not generate persistent MAC address for veth5c6999c: No such file or directory 
Aug 25 19:22:03 api-31 systemd-udevd[19127]: Could not generate persistent MAC address for veth39fb4d3: No such file or directory 
Aug 25 19:22:03 api-31 kernel: [87078.944218] docker0: port 1(veth5c6999c) entered disabled state 
Aug 25 19:22:03 api-31 kernel: [87078.948636] device veth5c6999c left promiscuous mode 
Aug 25 19:22:03 api-31 kernel: [87078.948640] docker0: port 1(veth5c6999c) entered disabled state 
Aug 25 19:22:03 api-31 docker[19023]: time="2016-08-25T19:22:03.219677059Z" level=error msg="Failed to start container 547bceaad5d121444ddc6effbac3f472d0c232d693d8cc076027e238cf253613: rpc error: code = 6 desc = \"mkdir /run/containerd/547bceaad5d121444ddc6effbac3f472d0c232d693d8cc076027e238cf253613: file exists\"" 
Aug 25 19:22:03 api-31 docker[19023]: time="2016-08-25T19:22:03.219750430Z" level=info msg="Loading containers: done." 
Aug 25 19:22:03 api-31 docker[19023]: time="2016-08-25T19:22:03.219776593Z" level=info msg="Daemon has completed initialization" 
Aug 25 19:22:03 api-31 docker[19023]: time="2016-08-25T19:22:03.219847738Z" level=info msg="Docker daemon" commit=b9f10c9 graphdriver=overlay version=1.11.2 
Aug 25 19:22:03 api-31 systemd[1]: Started Docker Application Container Engine. 
Aug 25 19:22:03 api-31 docker[19023]: time="2016-08-25T19:22:03.226116336Z" level=info msg="API listen on /var/run/docker.sock" 

Answer 1

qui semble être suivie issue 25487 (Août 2016), et a été signalé avant même (Avril 2016) dans issue 22195.

Vérifiez si vous êtes dans la situation mentionnée dans issue 21702 par Tõnis Tiigi:

Cela semble être causé par le profil AppArmor pour le démon docker que nous avons en docker/contrib/apparmor.
Si ce profil est appliqué dans v1.11 (au moins ubuntu wily), le démarrage du conteneur ne fonctionne pas. Je ne suis pas sûr si les utilisateurs ont appliqué manuellement ce profil ou apparemment nous avons également accidentellement installé ce profil dans 1.10.0-rc1 (#19707). Donc la solution de contournement, jusqu'à ce que nous comprenions comment traiter cela, est de décharger le profil avec quelque chose comme apparmor_parser -R /etc/apparmor.d/docker-engine, le supprimer et redémarrer démon.
/etc/apparmor.d/docker est le profil pour les conteneurs et n'a pas besoin d'être changé.

Answer 2

@VonC - Merci de m'avoir indiqué la bonne direction. J'ai fait des recherches sur le sujet, mais dans mon cas, l'apparmor n'est pas un problème. Il y a d'autres problèmes mentionnés dans le fil, donc je les ai suivis et j'ai trouvé la solution.

SOLUTION: Sous Ubuntu 16.04, le problème est que systemd tue le processus containerd avec le processus du démon docker. Afin d'éviter, vous devez ajouter

KillMode = processus

à /lib/systemd/system/docker.service et qui résout le problème.

Voici les sources que j'ai utilisé:

https://github.com/docker/docker/issues/25246

https://github.com/docker/docker/blob/master/contrib/init/systemd/docker.service#L25