Je ne parviens pas à supprimer le conteneur mort, il réapparaît après le redémarrage du service Docker.
docker ps -a
CONTAINER ID STATUS
11667ef16239 Dead
Ensuite
docker rm -f 11667ef16239
Puis, lorsque j'ai lancé le menu fixe ps -a, aucun conteneur de menu fixe ne s'affiche.
docker ps -a
CONTAINER ID STATUS
Cependant, lorsque je redémarre le service Docker:
service docker restart
Et lancez à nouveau le menu fixe ps -a:
docker ps -a
CONTAINER ID STATUS
11667ef16239 Dead
Très probablement, une erreur s'est produite lorsque le démon a tenté de nettoyer le conteneur et il est maintenant bloqué dans cet état "zombie".
Je crains que votre seule option ici soit de le nettoyer manuellement:
$ Sudo rm -rf /var/lib/docker/<storage_driver>/11667ef16239.../
Où <storage_driver>
est le nom de votre pilote (aufs
, overlay
, btrfs
ou devicemapper
).
En fait, les choses ont légèrement changé ces jours-ci pour vous débarrasser de ces conteneurs morts, vous pouvez essayer de démonter ces systèmes de fichiers bloqués pour les libérer
Donc, si vous recevez un message comme celui-ci
Error response from daemon: Cannot destroy container elated_wozniak: Driver devicemapper failed to remove root filesystem 656cfd09aee399c8ae8c8d3e735fe48d70be6672773616e15579c8de18e2a3b3: Device is Busy
juste courir ceci
umount /var/lib/docker/devicemapper/mnt/656cfd09aee399c8ae8c8d3e735fe48d70be6672773616e15579c8de18e2a3b3
et vous pouvez normalement enlever le conteneur après cela
Vous pouvez également supprimer les conteneurs dead
avec cette commande
docker rm $(docker ps --all -q -f status=dead)
Mais je ne sais vraiment pas pourquoi et comment les conteneurs dead
sont créés. Cette erreur semble liée https://github.com/typesafehub/mesos-spark-integration-tests/issues/34 chaque fois que je reçois des conteneurs dead
[Mise à jour] Avec la mise à jour Docker 1.13, nous pouvons facilement supprimer les deux conteneurs indésirables, les images pendantes.
$ docker system df #will show used space, similar to the unix tool df
$ docker system Prune # will remove all unused data.
J'ai eu l'erreur suivante lors de la suppression d'un conteneur mort (docker 17.06.1-ce sur CentOS 7):
Error response from daemon: driver "overlay" failed to remove root filesystem for <some-id>:
remove /var/lib/docker/overlay/<some-id>/merged: device or resource busy
Voici comment je l'ai corrigé:
1. Vérifier quels autres processus utilisent également les ressources du menu fixe
$ grep docker /proc/*/mountinfo
qui produit quelque chose comme ceci, où le nombre après /proc/
est la pid
:
/proc/10001/mountinfo:179...
/proc/10002/mountinfo:149...
/proc/12345/mountinfo:159 149 0:36 / /var/lib/docker/overlay/...
2. Vérifiez le nom du processus du pid ci-dessus
$ ps -p 10001 -o comm=
dockerd
$ ps -p 10002 -o comm=
docker-containe
$ ps -p 12345 -o comm=
nginx <<<-- This is suspicious!!!
Donc, nginx
avec pid 12345 semble également utiliser /var/lib/docker/overlay/...
, raison pour laquelle nous ne pouvons pas supprimer le conteneur associé et obtenir l'erreur device or resource busy
. (Voir ici pour une discussion sur la façon dont nginx
partage le même espace de noms de montage avec des conteneurs de menu fixe, empêchant ainsi sa suppression.)
3. Arrêtez nginx
et je pourrai ensuite supprimer le conteneur avec succès.
$ Sudo service nginx stop
$ docker rm <container-id>
J'ai eu le même problème et les deux réponses n'ont pas aidé.
Ce qui m'a aidé, c'est simplement de créer les répertoires manquants et de les supprimer:
mkdir /var/lib/docker/devicemapper/mnt/656cfd09aee399c8ae8c8d3e735fe48d70be6672773616e15579c8de18e2a3b3
mkdir /var/lib/docker/devicemapper/mnt/656cfd09aee399c8ae8c8d3e735fe48d70be6672773616e15579c8de18e2a3b3-init
docker rm 656cfd09aee399c8ae8c8d3e735fe48d70be6672773616e15579c8de18e2a3b3
Retirer le conteneur par la force a fonctionné pour moi.
docker rm -f <id_of_the_dead_container>
Remarques :
Sachez que cette commande peut générer cette erreur Error response from daemon: Driver devicemapper failed to remove root filesystem <id_of_the_dead_container>: Device is Busy
Le montage du mappeur de votre périphérique conteneur mort doit être supprimé malgré ce message. C'est-à-dire que vous n'accéderez plus à ce chemin:
/var/lib/docker/devicemapper/mnt/<id_of_the_dead_container>
J'ai essayé les suggestions ci-dessus mais je n'ai pas fonctionné.
Ensuite
docker system Prune -a
, ça n'a pas fonctionné la première foisdocker system Prune -a
. Cette fois ça marche. Il enverra un message d'avertissement et à la fin, demandera "Êtes-vous sûr de vouloir continuer? Oui/Non?. Réponse: Oui. Cela arrivera une fois et les conteneurs morts disparaîtront à la fin.docker ps -a
IMPORTANT- c'est l'option nucléaire, car elle détruit tous les conteneurs + images
grep 656cfd09aee399c8ae8c8d3e735fe48d70be6672773616e15579c8de18e2a3b3 /proc/*/mountinfo
puis trouver le pid de 656cfd09aee399c8ae8c8d3e735fe48d70be6672773616e15579c8de18e2a3b3and
et le tuer
Essayez d'exécuter les commandes suivantes. Ça marche toujours pour moi.
# docker volume rm $(docker volume ls -qf dangling=true)
# docker rm $(docker ps -q -f 'status=exited')
Après exécution des commandes ci-dessus, redémarrez docker par,
# service docker restart
pour Windows:
del D:\ProgramData\docker\containers\{CONTAINER ID}
del D:\ProgramData\docker\windowsfilter\{CONTAINER ID}
Puis redémarrez le Docker Desktop
Pour supprimer tous les conteneurs morts docker rm -f $(docker ps --all -q -f status=dead)
Pour supprimer tous les conteneurs quittés docker rm -f $(docker ps --all -q -f status=exited)
Comme j'ai -f
est nécessaire
J'ai essayé tout ce qui précède (à moins de redémarrer/redémarrer le menu fixe).
Donc, voici l'erreur om docker rm:
$ docker rm 08d51aad0e74
Error response from daemon: driver "devicemapper" failed to remove root filesystem for 08d51aad0e74060f54bba36268386fe991eff74570e7ee29b7c4d74047d809aa: remove /var/lib/docker/devicemapper/mnt/670cdbd30a3627ae4801044d32a423284b540c5057002dd010186c69b6cc7eea: device or resource busy
Puis j'ai fait ce qui suit:
$ grep docker /proc/*/mountinfo | grep 958722d105f8586978361409c9d70aff17c0af3a1970cb3c2fb7908fe5a310ac
/proc/20416/mountinfo:629 574 253:15 / /var/lib/docker/devicemapper/mnt/958722d105f8586978361409c9d70aff17c0af3a1970cb3c2fb7908fe5a310ac rw,relatime shared:288 - xfs /dev/mapper/docker-253:5-786536-958722d105f8586978361409c9d70aff17c0af3a1970cb3c2fb7908fe5a310ac rw,nouuid,attr2,inode64,logbsize=64k,sunit=128,swidth=128,noquota
Ceci doit être le PID du processus incriminé le gardant occupé - 20416 (l'élément après/proc /
J'ai donc fait un ps -p et à ma grande surprise, j'ai trouvé:
[devops@dp01app5030 SeGrid]$ ps -p 20416
PID TTY TIME CMD
20416 ? 00:00:19 ntpd
Un vrai moment WTF. Donc, je couple problème résolu avec Google et a trouvé ceci: Puis trouvé ceci https://github.com/docker/for-linux/issues/124
Il s'avère que je devais redémarrer le démon ntp et que le problème soit résolu !!!
Essayez cela a fonctionné pour moi sur centos 1) le conteneur docker ls -agive une liste des états de vérification des conteneurs dont vous souhaitez vous débarrasser 2) conteneur de menu fixe rm -f 97af2da41b2b N'est pas un indicateur de force de ventilateur, mais fait le travail pour vérifier que tout fonctionne bien, il suffit de relancer la commande ou de la lister . 3) Continuez jusqu'à ce que tous les conteneurs morts soient effacés
Essayez, cela a fonctionné pour moi:
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
4f13b53be9dd 5b0bbf1173ea "/opt/app/netjet..." 5 months ago Dead appname_chess
$ docker rm $(docker ps --all -q -f status=dead)
Error response from daemon: driver "devicemapper" failed to remove root filesystem for 4f13b53be9ddef3e9ba281546aef1c544805282971f324291a1dc91b50eeb440: failed to remove device 487b4b73c58d19ef79201cf6d5fcd6b7316e612e99c14505a6bf24399cad9795-init: devicemapper: Error running DeleteDevice dm_task_run failed
su
cd /var/lib/docker/containers
[root@localhost containers]# ls -l
total 0
drwx------. 1 root root 312 Nov 17 08:58 4f13b53be9ddef3e9ba281546aef1c544805282971f324291a1dc91b50eeb440
[root@localhost containers]# rm -rf 4f13b53be9ddef3e9ba281546aef1c544805282971f324291a1dc91b50eeb440
systemctl restart docker
Il y a beaucoup de réponses ici mais aucune d’entre elles n’implique la solution (rapide) qui a fonctionné pour moi.
J'utilise Docker version 1.12.3, build 6b644ec.
J'ai simplement lancé docker rmi <image-name>
pour l'image d'où le conteneur mort est venu. Un docker ps -a
a ensuite montré le conteneur mort manquant complètement.
Ensuite, bien sûr, j'ai simplement ré-extrait l'image et refait le traitement du conteneur.
Je ne sais pas du tout comment il s'est retrouvé dans cet état, mais il en est ainsi ...
Essayez ceci cela a fonctionné pour moi:
docker rm -f <container_name>
eg. docker rm -f 11667ef16239
Sous Centos7 & Docker 1.8.2, je ne pouvais pas utiliser la solution de Zgr3doo pour exécuter umount par devicemapper (je pense que la réponse que j’ai eue est que le volume n’a pas été monté/trouvé.)
Je pense que la réponse de sk8terboi87 ツ était également similaire: je pense que le message était que les volumes ne pouvaient pas être démontés et qu'il répertoriait les volumes spécifiques qu'il essayait de démonter pour supprimer les conteneurs morts.
Ce qui a fonctionné pour moi, c’est d’arrêter d’abord le menu fixe, puis de supprimer les répertoires manuellement. J'ai été capable de déterminer lesquels ils étaient par la sortie d'erreur de la commande précédente pour supprimer tous les conteneurs morts.
Toutes mes excuses pour les descriptions vagues ci-dessus. J'ai trouvé cette SO question quelques jours après avoir manipulé les conteneurs morts. .. Cependant, j'ai remarqué une tendance similaire aujourd'hui:
$ Sudo docker stop fervent_fermi; Sudo docker rm fervent_fermi fervent_fermi
Error response from daemon: Cannot destroy container fervent_fermi: Driver devicemapper failed to remove root filesystem a11bae452da3dd776354aae311da5be5ff70ac9ebf33d33b66a24c62c3ec7f35: Device is Busy
Error: failed to remove containers: [fervent_fermi]
$ Sudo systemctl docker stop
$ Sudo rm -rf /var/lib/docker/devicemapper/mnt/a11bae452da3dd776354aae311da5be5ff70ac9ebf33d33b66a24c62c3ec7f35
$
J'ai remarqué, en utilisant cette approche, que docker a recréé les images avec des noms différents:
a11bae452da3 trend_av_docker "bash" 2 weeks ago Dead compassionate_ardinghelli
Cela est peut-être dû au fait que le conteneur a été relancé avec restart = toujours. Cependant, l'ID du conteneur correspond à l'ID du conteneur qui utilisait auparavant le volume que j'ai supprimé de force. La suppression de ce nouveau conteneur n'a posé aucun problème:
$ Sudo docker rm -v compassionate_ardinghelli
compassionate_ardinghelli