hub - dockers container download

Docker: no se puede quitar el contenedor muerto (18)

Para eliminar todos los contenedores muertos docker rm -f $(docker ps --all -q -f status=dead)
Para eliminar todos los contenedores salidos docker rm -f $(docker ps --all -q -f status=exited)

Como tengo -f es necesario

No puedo eliminar el contenedor muerto, aparece nuevamente después de reiniciar el servicio Docker.

docker ps -a CONTAINER ID STATUS 11667ef16239 Dead

Entonces

docker rm -f 11667ef16239

Luego, cuando ejecuté el docker ps -a, no se muestran contenedores de docker.

docker ps -a CONTAINER ID STATUS

Sin embargo, cuando reinicio el servicio docker:

service docker restart

Y ejecute el docker ps -a nuevamente:

docker ps -a CONTAINER ID STATUS 11667ef16239 Dead

Al ejecutar en Centos7 y Docker 1.8.2, no pude usar la solución de Zgr3doo para desmontar con devicemapper (creo que la respuesta que obtuve fue que el volumen no estaba montado / encontrado).

Creo que también sucedió algo similar con la respuesta de sk8terboi87:: creo que el mensaje fue que los volúmenes no se podían desmontar, y enumeraba los volúmenes específicos que intentó desmontar para eliminar los contenedores muertos.

Lo que sí funcionó para mí fue detener Docker primero y luego eliminar los directorios manualmente. Pude determinar cuáles eran por la salida de error del comando anterior para eliminar todos los contenedores muertos.

Disculpas por las vagas descripciones anteriores. Encontré esta pregunta SO días después de manejar los contenedores muertos. .. Sin embargo, noté un patrón similar hoy:

$ sudo docker rm -v compassionate_ardinghelli compassionate_ardinghelli

Noté que, al usar este enfoque, Docker recreó las imágenes con diferentes nombres:

$ 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

Esto puede deberse a que el contenedor se emitió con restart = siempre, sin embargo, la ID del contenedor coincide con la ID del contenedor que utilizó anteriormente el volumen que forcé la eliminación. No hubo dificultades para eliminar este nuevo contenedor:

$ sudo docker rm -v compassionate_ardinghelli compassionate_ardinghelli

Aquí hay muchas respuestas, pero ninguna de ellas involucró la solución (rápida) que funcionó para mí.

Estoy usando Docker versión 1.12.3, compilación 6b644ec.

Simplemente ejecuté docker rmi <image-name> para la imagen de donde vino el contenedor muerto. Un docker ps -a luego mostró que el contenedor muerto faltaba por completo.

Luego, por supuesto, simplemente volví a sacar la imagen y volví a ejecutar el contenedor.

No tengo idea de cómo se encontró en este estado, pero así es ...

En realidad, las cosas cambiaron ligeramente en estos días para deshacerse de esos contenedores muertos, puede intentar desmontar esos sistemas de archivos bloqueados para liberarlos

Entonces, si recibes un mensaje como este

Error response from daemon: Cannot destroy container elated_wozniak: Driver devicemapper failed to remove root filesystem 656cfd09aee399c8ae8c8d3e735fe48d70be6672773616e15579c8de18e2a3b3: Device is Busy

solo ejecuta esto

umount /var/lib/docker/devicemapper/mnt/656cfd09aee399c8ae8c8d3e735fe48d70be6672773616e15579c8de18e2a3b3

y normalmente puedes quitar el contenedor después de eso

He probado las sugerencias anteriores pero no funcionó.

Entonces

Intento: docker system prune -a , no funcionó la primera vez
Reinicio el sistema
Vuelvo a intentar la docker system prune -a . Esta vez funciona Enviará un mensaje de advertencia y al final preguntará "¿Está seguro de que desea continuar? Y / n?. Respuesta: y. Tomará un tiempo y al final los contenedores muertos desaparecerán.
Verificar con docker ps -a

IMPORTANTE : esta es la opción nuclear, ya que destruye todos los contenedores + imágenes

Intenté todo lo anterior (antes de reiniciar / reiniciar la ventana acoplable).

Así que aquí está el error 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

Luego hice lo siguiente:

$ 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

Este debe ser el PID del proceso ofensivo que lo mantiene ocupado - 20416 (el elemento después de / proc /

Entonces hice un ps -p y para mi sorpresa encontré:

[devops@dp01app5030 SeGrid]$ ps -p 20416 PID TTY TIME CMD 20416 ? 00:00:19 ntpd

Un verdadero momento WTF. Así que emparejé el problema resuelto con Google y encontré esto: luego encontré esto https://github.com/docker/for-linux/issues/124

Resulta que tuve que reiniciar el demonio ntp y eso solucionó el problema.

Intenta ejecutar los siguientes comandos. Siempre funciona para mi.

# docker volume rm $(docker volume ls -qf dangling=true) # docker rm $(docker ps -q -f ''status=exited'')

Después de la ejecución de los comandos anteriores, reinicie Docker,

# service docker restart

Intenta matarlo y luego eliminar> :) es decir
docker kill $(docker ps -q)

Intenta, funcionó para mí:

docker rm -f <container_name> eg. docker rm -f 11667ef16239

Intente esto, funcionó para mí en centos 1) docker container ls -a le da una lista de estado de verificación de contenedores del que desea deshacerse 2) el contenedor docker rm -f 97af2da41b2b no es un gran indicador de fuerza del ventilador, pero hace el trabajo para verificar que funcionó, simplemente active el comando nuevamente o enumere. 3) continuar hasta que despejemos todos los contenedores muertos

Lo más probable es que se haya producido un error cuando el demonio intentó limpiar el contenedor, y ahora está atrapado en este estado "zombie".

Me temo que su única opción aquí es limpiarlo manualmente:

$ sudo rm -rf /var/lib/docker/<storage_driver>/11667ef16239.../

Donde <storage_driver> es el nombre de su controlador ( aufs , overlay , btrfs o devicemapper ).

Prueba esto, funcionó para mí:

$ 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 $

Quitar el contenedor por la fuerza funcionó para mí.

docker rm -f <id_of_the_dead_container>

Notas :

Tenga en cuenta que este comando puede generar este error Error response from daemon: Driver devicemapper failed to remove root filesystem <id_of_the_dead_container>: Device is Busy

El montaje del mapeador de dispositivos de contenedor muerto de su debe eliminarse a pesar de este mensaje. Es decir, ya no accederá a esta ruta:

/var/lib/docker/devicemapper/mnt/<id_of_the_dead_container>

Recibí el mismo problema y ambas respuestas no ayudaron.

Lo que me ayudó es crear los directorios que faltan y eliminarlos:

mkdir /var/lib/docker/devicemapper/mnt/656cfd09aee399c8ae8c8d3e735fe48d70be6672773616e15579c8de18e2a3b3 mkdir /var/lib/docker/devicemapper/mnt/656cfd09aee399c8ae8c8d3e735fe48d70be6672773616e15579c8de18e2a3b3-init docker rm 656cfd09aee399c8ae8c8d3e735fe48d70be6672773616e15579c8de18e2a3b3

También puede eliminar contenedores dead con este comando

docker rm $(docker ps --all -q -f status=dead)

Pero, realmente no estoy seguro de por qué y cómo se crean los contenedores dead . Este error parece estar relacionado https://github.com/typesafehub/mesos-spark-integration-tests/issues/34 cada vez que obtengo contenedores dead

[Actualización] Con la actualización Docker 1.13, podemos eliminar fácilmente ambos contenedores no deseados, colgando imágenes

$ docker system df #will show used space, similar to the unix tool df $ docker system prune # will remove all unused data.

Tuve el siguiente error al eliminar un contenedor muerto (docker 17.06.1-ce en 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

Así es como lo arreglé:

1. Compruebe qué otros procesos también están utilizando los recursos de Docker

$ grep docker /proc/*/mountinfo

que genera algo como esto, donde el número después de /proc/ es el pid :

/proc/10001/mountinfo:179... /proc/10002/mountinfo:149... /proc/12345/mountinfo:159 149 0:36 / /var/lib/docker/overlay/...

2. Verifique el nombre del proceso del pid anterior

$ ps -p 10001 -o comm= dockerd $ ps -p 10002 -o comm= docker-containe $ ps -p 12345 -o comm= nginx <<<-- This is suspicious!!!

Entonces, nginx con pid 12345 también parece estar usando /var/lib/docker/overlay/... , por lo que no podemos eliminar el contenedor relacionado y obtener el error de device or resource busy . (Consulte here para ver una discusión sobre cómo nginx comparte el mismo espacio de nombres de montaje con los contenedores acoplables, por lo que evita su eliminación).

3. Detenga nginx y luego puedo eliminar el contenedor con éxito.

$ sudo service nginx stop $ docker rm <container-id>

para ventanas:

a11bae452da3 trend_av_docker "bash" 2 weeks ago Dead compassionate_ardinghelli

Luego reinicie el escritorio de Docker

grep 656cfd09aee399c8ae8c8d3e735fe48d70be6672773616e15579c8de18e2a3b3 /proc/*/mountinfo

luego encuentra el pid de 656cfd09aee399c8ae8c8d3e735fe48d70be6672773616e15579c8de18e2a3b3and y mátalo