@vieira Reinicie la máquina y avísenos si aún tiene problemas.

Los pasos anteriores se pueden reproducir incluso después de reiniciar la máquina.

@alexlarsson , ¿puedes echar un vistazo? Parece estar relacionado con devicemapper

El problema parece estar relacionado con el mapeador de dispositivos. Aunque creo que es realmente algo más.
Intenté esto y el problema es la parte de "detener la ventana acoplable". Si solo ctrl-c el demonio de la ventana acoplable, intentará detener correctamente los contenedores, pero parece que nunca logra detener el contenedor. Entonces, presiono ctrl-c unas cuantas veces más para forzar a Docker a morir.

En este punto, el contenedor (cola) todavía se está ejecutando, por lo que se montará el dispositivo mapeador de dispositivos, lo que significa que no podemos volver a montarlo ni eliminarlo. Por eso estas operaciones fallan.

@alexlarsson , ¿conoces una manera fácil de limpiar el sistema una vez que esto sale mal?

Bueno, si encuentras el proceso del contenedor fuera de control, tal vez puedas forzar su eliminación.

@vieira puedes desmontar:
umount / var / lib / docker / devicemapper / mnt / c39206003c7ae8992a554a9ac2ea130327fc4af1b2c389656c34baf9a56c84b5

y vuelva a encender el contenedor, debería funcionar

Puedo ver que mi ventana acoplable se inició con -d y -r. Primero, cuando se reinicia la ventana acoplable, los contenedores no se reinician. Entonces ocurre el error mencionado anteriormente (al intentar iniciar los contenedores).

Mi centos 6.5 todavía está obteniendo 1.0.0.6 del epel. ¿Alguna vez se ha identificado esto como un error en 1.0 y se ha corregido en 1.1? ¿Alguien puede confirmar?

Gracias

Hola a todos, todavía no se solucionó en 1.1.1.
Los pasos de la publicación original aún se aplican.

Error response from daemon: Cannot start container 5e9bde9b409b: 
Error getting container 5e9bde9b409b001bcc685c0b478e925a53a03bab8d8ef3210bf24aa39410e30d 
from driver devicemapper: 
Error mounting '/dev/mapper/docker-253:0-267081-5e9bde9b409b001bcc685c0b478e925a53a03bab8d8ef3210bf24aa39410e30d' 
on 
'/var/lib/docker/devicemapper/mnt/5e9bde9b409b001bcc685c0b478e925a53a03bab8d8ef3210bf24aa39410e30d': 
device or resource busy

También estoy obteniendo mucho, pero parece que elimina el contenedor en cierto sentido (en el sentido de que puedo comenzar un nuevo contenedor con el mismo nombre)

¿Existe una solución alternativa para este problema?

Buscando una solución alternativa también.

Parece que se detienen todos los contenedores antes de que el demonio docker solucione el problema.

Agregué este bloque pre-stop a mi trabajo advenedizo como solución alternativa:

pre-stop script
    /usr/bin/docker ps -q | xargs /usr/bin/docker stop
end script

Aquí hay una esencia con mis pasos de depuración: https://gist.github.com/rochacon/4dfa7bd4de3c5f933f0d

@rochacon Gracias por su solución. Lo probaré hoy o mañana con 1.2 (parece que lo probaste con 1.1.1, ¿verdad?). Espero que funcione.

@vieira También probé con 1.2.0, mismos resultados.

Después de 4 semanas de funcionamiento, uno de mis contenedores se detuvo ... No estoy seguro de por qué ... ¿Cómo puedo encontrar la causa raíz?

De todos modos, tuve el mismo problema ... Se resolvió con la sugerencia de @aroragagan : umount, docker start container ... Por cierto, estoy en RHEL 6.5 ...

root<strong i="8">@pppdc9prd3ga</strong> mdesales]# docker start federated-registry
Error response from daemon: Cannot start container federated-registry: Error getting container 4841fcb6e51f4e9fcd7a115ac3efae4b0fd47e4f785c735e2020d1c479dc3946 from driver devicemapper: Error mounting '/dev/mapper/docker-253:0-394842-4841fcb6e51f4e9fcd7a115ac3efae4b0fd47e4f785c735e2020d1c479dc3946' on '/var/lib/docker/devicemapper/mnt/4841fcb6e51f4e9fcd7a115ac3efae4b0fd47e4f785c735e2020d1c479dc3946': device or resource busy
2014/10/17 21:04:33 Error: failed to start one or more containers

[root<strong i="9">@pppdc9prd3ga</strong> mdesales]# docker version
Client version: 1.1.2
Client API version: 1.13
Go version (client): go1.2.2
Git commit (client): d84a070/1.1.2
Server version: 1.1.2
Server API version: 1.13
Go version (server): go1.2.2
Git commit (server): d84a070/1.1.2

[root<strong i="10">@pppdc9prd3ga</strong> mdesales]# umount /var/lib/docker/devicemapper/mnt/4841fcb6e51f4e9fcd7a115ac3efae4b0fd47e4f785c735e2020d1c479dc3946

[root<strong i="11">@pppdc9prd3ga</strong> mdesales]# docker start federated-registry
federated-registry

Estamos viendo esto en 1.3.0 ahora, en un sistema EC2 Ubuntu que se actualizó de 12.04 a 14.04. Mi instancia de desarrollo es una instalación directa de 14.04 en Vagrant y no tiene este problema. Desmontar y luego reiniciar los contenedores parece funcionar, pero eso anula el propósito de tenerlos configurados para reiniciarse automáticamente cuando la instancia se reinicia o cuando se reinicia la ventana acoplable. Avíseme si hay más información que pueda proporcionar sobre las versiones de los paquetes de soporte, etc., ya que tengo un sistema que funciona y que no funciona.

Viendo el mismo problema con Docker 1.3 Ubuntu 14.04 con el kernel de Linux 3.13 o 3.14.

@srobertson, ¿se refiere a "los contenedores no se reinician cuando se reinicia el demonio"? ¿Está utilizando la nueva política de reinicio de _per-container_? Debido a que el -r / --restart=true el demonio se ha eliminado en Docker 1.2

La nueva política de reinicio (por contenedor) se describe en la referencia CLI

+1, tengo este problema en la ventana acoplable 1.3 @ ArchLinux x86_64 con el kernel 3.17.2-1-ARCH.

$ docker --version
Docker version 1.3.1, build 4e9bbfa

Umount resuelve el problema.

umount es una solución alternativa, no diría que resuelve el problema. Simplemente reiniciar el demonio con los contenedores en ejecución reproducirá el problema.

umount también me funciona en la siguiente versión de la ventana acoplable:

atc@li574-92> docker --version
Docker version 1.3.1, build 4e9bbfa

Primero detuve el demonio docker y luego:

umount /dev/mapper/docker-202\:0-729439-a7c53ae579d02aa7bb3aeb2af5f2f79c295e1f5962ec53f16b73896bb3970635 

@ mlehner616 Sí, tienes razón. Lo siento, por supuesto que es una solución alternativa, no una solución. Esa fue una mala elección de palabras.

Me gustaría ver esto arreglado también, ofc. =)

Fyi, unmounten no funcionó para mí. Recibo un error de que no se puede encontrar ningún montaje en / etc / mtab
Docker versión 1.0.0, compilación 63fe64c / 1.0.0 en RHEL 6.5

Lo solucioné desmontando automáticamente cualquier montaje antiguo cuando el demonio de la ventana acoplable regresa. No quería parchear el gran /etc/init/docker.conf ubuntu, así que puse una pequeña línea en /etc/default/docker lugar:

cat /proc/mounts | grep "mapper/docker" | awk '{print $2}' | xargs -r umount

Eso parece funcionar. Lo he combinado con que un advenedizo administre el inicio y la reaparición de mis contenedores Docker reales, por lo que ahora, después de service docker restart , todos los contenedores volverán.

Gracias, @jypma , ¡eso también me sirvió!

_sesión de revisión_ con

Usaremos este problema como un rastreador para la mayoría de los informes de "dispositivo o recurso ocupado" o EBUSY .

Este problema, como otros, se mitiga manejando correctamente el espacio de nombres de montaje del demonio de la ventana acoplable. Actualmente no existe un manejo predeterminado del espacio de nombres de montaje, por lo que tenemos problemas como este EBUSY.

Mientras trabajamos en la solución oficial para manejarlo, hay soluciones que puede aplicar usted mismo. Consulte http://blog.hashbangbash.com/2014/11/docker-devicemapper-fix-for-device-or-resource-busy-ebusy/

Confirmando que me encontré con este problema también usando la imagen de stock freeipa. Detuve el servicio de Docker y cuando intenté reiniciarlo junto con el contenedor ipa obtuve lo siguiente.

$ docker start ipa
Error response from daemon: Cannot start container ipa: Error getting container 98f224de38a0879b8a628179fa29a53b314dfada8c4c2e018113f0affa76f9d2 from driver devicemapper: Error mounting '/dev/mapper/docker-253:0-786581-98f224de38a0879b8a628179fa29a53b314dfada8c4c2e018113f0affa76f9d2' on '/var/lib/docker/devicemapper/mnt/98f224de38a0879b8a628179fa29a53b314dfada8c4c2e018113f0affa76f9d2': device or resource busy
2015/01/11 21:44:38 Error: failed to start one or more containers

Desmontar el "montaje" solucionó el problema para poder reiniciar el contenedor.

$ umount /var/lib/docker/devicemapper/mnt/98f224de38a0879b8a628179fa29a53b314dfada8c4c2e018113f0affa76f9d2

$ docker start ipa
ipa

Usando lo siguiente:

$  docker version
Client version: 1.3.2
Client API version: 1.15
Go version (client): go1.3.3
Git commit (client): 39fa2fa/1.3.2
OS/Arch (client): linux/amd64
Server version: 1.3.2
Server API version: 1.15
Go version (server): go1.3.3
Git commit (server): 39fa2fa/1.3.2

$ lsb_release -i -d
Distributor ID: CentOS
Description:    CentOS release 6.6 (Final)

umount solucionó mi problema

docker --version
Docker versión 1.3.2, compilación 39fa2fa

Entonces, la siguiente solución es una solución un poco más permanente para mi caso de uso.
Estoy usando estrictamente Amazon linux (RedHat6-Like), así que hice una pequeña modificación en el script de inicio (que probablemente se sobrescribirá si la ventana acoplable se actualiza). Básicamente, todo lo que está haciendo es detener la ventana acoplable como de costumbre, verificando los montajes restantes de la ventana acoplable. , si hay alguno, los desmonta. YMMV

_ / etc / init.d / docker_
Añadiendo la variable lib (línea ~ 28)

prog="docker"
exec="/usr/bin/$prog"
# Adding lib variable here
lib="/var/lib/$prog"
pidfile="/var/run/$prog.pid"
lockfile="/var/lock/subsys/$prog"
logfile="/var/log/$prog"

Agregar bloque de desmontaje para detener la función (línea ~ 77)

stop() {
    echo -n $"Stopping $prog: "
    killproc -p $pidfile -d 300 $prog
    retval=$?
    echo
    [ $retval -eq 0 ] && rm -f $lockfile

    # BEGIN UMOUNT BLOCK
    if [ $(df | grep $lib | awk '{print $1}' | wc -l) -gt 0 ]; then
        umount $(df | grep $lib | awk '{print $1}')
    fi
    # END UMOUNT BLOCK
    return $retval
}

Me encuentro con el mismo problema con la ventana acoplable 1.4.1 usando el mapeador de dispositivos como controlador de almacenamiento. Pude recopilar un seguimiento de pila de pánico de la ventana acoplable a través de su archivo de registro.

MEDIO AMBIENTE

$ cat / etc / * lanzamiento
DISTRIB_ID = Ubuntu
DISTRIB_RELEASE = 14.04
DISTRIB_CODENAME = confiable
DISTRIB_DESCRIPTION = "Ubuntu 14.04.1 LTS"
NAME = "Ubuntu"
VERSION = "14.04.1 LTS, Trusty Tahr"
ID = ubuntu
ID_LIKE = debian
PRETTY_NAME = "Ubuntu 14.04.1 LTS"
VERSION_ID = "14.04"
HOME_URL = " http://www.ubuntu.com/ "
SUPPORT_URL = " http://help.ubuntu.com/ "
BUG_REPORT_URL = " http://bugs.launchpad.net/ubuntu/ "

$ versión docker
sudo: no se puede resolver el host ip-172-30-0-39
Versión del cliente: 1.4.1
Versión de la API del cliente: 1.16
Go versión (cliente): go1.3.3
Confirmación de Git (cliente): 5bc2ff8
OS / Arch (cliente): linux / amd64
Versión del servidor: 1.4.1
Versión de la API del servidor: 1.16
Go versión (servidor): go1.3.3
Confirmación de Git (servidor): 5bc2ff8

$ tail -f / var / log / upstart / docker
...
INFO [143413] -job execResize (3dfcbc075227d5b3f0115bd73a1fea4a56a2c0fc68190d84b6d88e93938b4121, 37, 130)
2015/01/22 22:29:22 http: servicio de pánico @: error de tiempo de ejecución: dirección de memoria no válida o falta de referencia del puntero
goroutine 1932 [en ejecución]:
net / http.func · 011 ()
/usr/local/go/src/pkg/net/http/server.go:1100 + 0xb7
runtime.panic (0xbe5c40, 0x127da13)
/usr/local/go/src/pkg/runtime/panic.c:248 + 0x18d
github.com/docker/docker/daemon.(_execConfig).Resize(0xc20989c800, 0x25, 0x82, 0x0, 0x0)
/go/src/github.com/docker/docker/daemon/exec.go:65 + 0x66
github.com/docker/docker/daemon.(_Daemon).ContainerExecResize(0xc208044f20, 0xc20a836e00, 0x1)
/go/src/github.com/docker/docker/daemon/resize.go:49 + 0x314
github.com/docker/docker/daemon._Daemon.ContainerExecResize·fm(0xc20a836e00, 0x7f49bcd007d8)
/go/src/github.com/docker/docker/daemon/daemon.go:132 + 0x30
github.com/docker/docker/engine.(_Job).Run(0xc20a836e00, 0x0, 0x0)
/go/src/github.com/docker/docker/engine/job.go:83 + 0x837
github.com/docker/docker/api/server.postContainerExecResize(0xc208114fd0, 0xc20a55db27, 0x4, 0x7f49bcd08c58, 0xc209498320, 0xc209e
621a0, 0xc20a69c0c0, 0x0, 0x0)
/go/src/github.com/docker/docker/api/server/server.go:1170 + 0x2d1
github.com/docker/docker/api/server.func·002(0x7f49bcd08c58, 0xc209498320, 0xc209e621a0)
/go/src/github.com/docker/docker/api/server/server.go:1219 + 0x810
net / http.HandlerFunc.ServeHTTP (0xc2081b8280, 0x7f49bcd08c58, 0xc209498320, 0xc209e621a0)
/usr/local/go/src/pkg/net/http/server.go:1235 + 0x40
github.com/gorilla/mux.(_Router).ServeHTTP(0xc2080a3cc0, 0x7f49bcd08c58, 0xc209498320, 0xc209e621a0)
/go/src/github.com/docker/docker/vendor/src/github.com/gorilla/mux/mux.go:98 + 0x297
net / http.serverHandler.ServeHTTP (0xc208180480, 0x7f49bcd08c58, 0xc209498320, 0xc209e621a0)
/usr/local/go/src/pkg/net/http/server.go:1673 + 0x19f
net / http. (_ conn) .serve (0xc20a836300)
/usr/local/go/src/pkg/net/http/server.go:1174 + 0xa7e
creado por net / http. (* Server) .Serve
/usr/local/go/src/pkg/net/http/server.go:1721 + 0x313

...

INFO [0056] BORRAR /v1.16/containers/hoopla_docker_registry
INFO [0056] + trabajo rm (hoopla_docker_registry)
No se puede destruir el contenedor hoopla_docker_registry: Driver devicemapper no pudo eliminar el sistema de archivos raíz 6abcbfefe8bdd485dfb192f8926
3add895cda1ae28b578d4a0d9b23574dedc5c: El dispositivo está ocupado
INFO [0066] -trabajo rm (hoopla_docker_registry) = ERR (1)
ERRO [0066] Manejador para DELETE / containers / { name :. *} devolvió el error: No se puede destruir el contenedor hoopla_docker_registry: Drive
r devicemapper no pudo eliminar el sistema de archivos raíz 6abcbfefe8bdd485dfb192f89263add895cda1ae28b578d4a0d9b23574dedc5c: El dispositivo está ocupado

ERRO [0066] Error HTTP: statusCode = 500 No se puede destruir el contenedor hoopla_docker_registry: El controlador de dispositivo no pudo eliminar el sistema de archivos raíz 6abcbfefe8bdd485dfb192f89263add895cda1ae28b578d4a0d9b23574dedc5c: El dispositivo está ocupado

Estaba viendo esto en ubuntu 14.04 (en ec2) con 1.4.1 y tampoco con 1.5. Es extraño, porque Docker parece muy confiable en linux mint 17 pero muy poco confiable en nuestro servidor de compilación con ubuntu 14.04.

¿Hay alguna forma de no usar devicemapper, ya que este problema parece haber existido desde 0.9 días?

Esto también podría suceder con overlayfs.

Bueno, acabo de cambiar a aufs y hasta ahora no hay problemas.

¿Cuál es el estado de este problema? Vi que se fusionaron algunos PR que podrían estar relacionados, pero nada que se estableciera claramente era una solución para esto. Este es un problema _principal_ en producción y la única solución ahora es parchear el script de inicio para desmontar limpiamente las unidades.

después de revisar esto nuevamente, este no es un ejemplo ideal del EBUSY que habíamos dicho originalmente.
Este caso tiene más que ver con los pids de un contenedor que no maneja las señales con elegancia.

Dado que el caso de reproducción aquí tail -f /dev/null no está saliendo en SIGQUIT cuando el demonio sale, entonces el controlador devmapper no puede desmontarse correctamente (esto no es exclusivo de devmapper). Antes de que el demonio se inicie nuevamente, puede ver que tail -f /dev/null aún se está ejecutando, incluso cuando la ventana acoplable no lo está.

Un problema como este requerirá reflexionar sobre cuán drásticamente se deben tratar los pids en el contenedor al salir de la ventana acoplable ... ¿ pensamientos de @unclejack @crosbymichael ?

Probé esto en Fedora 21 x86_64. Proporcionar información con fines de comparación solo cuando el problema no parece estar presente (¿ya?). Mismos resultados usando centos: 7 o ubuntu: trusty images.

$ docker run -d centos:7 tail -f /dev/null
ec496f1a6738430972b79e5f3c9fdbf2527e55817d4638678e3b0dd486191203

$ systemctl stop docker

$ ps ax | grep tail
14681 ?        Ss     0:00 tail -f /dev/null
14738 pts/9    S+     0:00 grep --color=auto tail

$ systemctl start docker

$ docker ps -q

$ docker ps -a -q
ec496f1a6738

$ docker start ec496f1a6738
ec496f1a6738

$ docker rm ec496f1a6738
Error response from daemon: Conflict, You cannot remove a running container. Stop the container before attempting removal or use -f
FATA[0000] Error: failed to remove one or more containers 

$ docker stop ec496f1a6738
ec496f1a6738

$ docker rm ec496f1a6738
ec496f1a6738

$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

Información del sistema:

$ uname -a
Linux localhost 3.18.9-200.fc21.x86_64 #1 SMP Mon Mar 9 15:10:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

$ rpm -q device-mapper docker-io
device-mapper-1.02.93-3.fc21.x86_64
docker-io-1.5.0-1.fc21.x86_64

$ docker version
Client version: 1.5.0
Client API version: 1.17
Go version (client): go1.3.3
Git commit (client): a8a31ef/1.5.0
OS/Arch (client): linux/amd64
Server version: 1.5.0
Server API version: 1.17
Go version (server): go1.3.3
Git commit (server): a8a31ef/1.5.0

Simplemente ejecute esto en Docker 1.5, Ubuntu 14.04
root@ip-10-148-25-50:~# docker start service Error response from daemon: Cannot start container service: Error getting container f3a7515112a0b5af94b0520844ef8c586763d2051b41b1db90e4c4efbd07e774 from driver devicemapper: Error mounting '/dev/mapper/docker-202:1-153948-f3a7515112a0b5af94b0520844ef8c586763d2051b41b1db90e4c4efbd07e774' on '/var/lib/docker/devicemapper/mnt/f3a7515112a0b5af94b0520844ef8c586763d2051b41b1db90e4c4efbd07e774': device or resource busy FATA[0000] Error: failed to start one or more containers

Sin embargo, ejecutar umount /var/lib/docker/devicemapper/mnt/f3a7515112a0b5af94b0520844ef8c586763d2051b41b1db90e4c4efbd07e774 ayudó.

Tengo el mismo problema en Docker 1.5.0, Centos7.0,

[vagrant<strong i="6">@localhost</strong> ~]$  sudo systemctl start docker
[vagrant<strong i="7">@localhost</strong> ~]$  sudo docker ps -a
CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS                        PORTS               NAMES
5189b16c0917        mongo:3             "/entrypoint.sh mong   35 minutes ago      Exited (128) 29 minutes ago                       mongod
[vagrant<strong i="8">@localhost</strong> ~]$ sudo docker inspect 5189b16c0917 | grep Error
        "Error": "Error getting container 5189b16c0917ff1f87b8aa8ab2e86953887d0e65ad95d0637b0f2213222d55e6 from driver devicemapper: Error mounting '/dev/mapper/docker-253:1-134,

umount falla.

[vagrant<strong i="12">@localhost</strong> ~]$ sudo stat /var/lib/docker/devicemapper/mnt/5189b16c0917ff1f87b8aa8ab2e86953887d0e65ad95d0637b0f2213222d55e6
  File: `/var/lib/docker/devicemapper/mnt/5189b16c0917ff1f87b8aa8ab2e86953887d0e65ad95d0637b0f2213222d55e6'
  Size: 6               Blocks: 0          IO Block: 4096   ディレクトリ
Device: fd01h/64769d    Inode: 201732136   Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2015-03-21 20:36:14.407505308 +0900
Modify: 2015-03-21 20:16:58.863146490 +0900
Change: 2015-03-21 20:16:58.863146490 +0900
 Birth: -
[vagrant<strong i="13">@localhost</strong> ~]$ sudo umount /var/lib/docker/devicemapper/mnt/5189b16c0917ff1f87b8aa8ab2e86953887d0e65ad95d0637b0f2213222d55e6
umount: /var/lib/docker/devicemapper/mnt/5189b16c0917ff1f87b8aa8ab2e86953887d0e65ad95d0637b0f2213222d55e6: not mounted
[vagrant<strong i="14">@localhost</strong> ~]$ grep docker /proc/mounts
(no results)

Medio ambiente

[vagrant<strong i="18">@localhost</strong> ~]$ cat /etc/centos-release
CentOS Linux release 7.0.1406 (Core)
[vagrant<strong i="19">@localhost</strong> ~]$ uname -a
Linux localhost.localdomain 3.10.0-123.20.1.el7.x86_64 #1 SMP Thu Jan 29 18:05:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[vagrant<strong i="20">@localhost</strong> ~]$ sudo docker version
Client version: 1.5.0
Client API version: 1.17
Go version (client): go1.3.3
Git commit (client): a8a31ef/1.5.0
OS/Arch (client): linux/amd64
Server version: 1.5.0
Server API version: 1.17
Go version (server): go1.3.3
Git commit (server): a8a31ef/1.5.0

[vagrant<strong i="21">@localhost</strong> ~]$ rpm -qi docker
Name        : docker
Version     : 1.5.0
Release     : 1.el7
Architecture: x86_64
Install Date: 2015年03月21日 20時04分29秒
Group       : Unspecified
Size        : 27215826
License     : ASL 2.0
Signature   : (none)
Source RPM  : docker-1.5.0-1.el7.src.rpm
Build Date  : 2015年02月12日 05時10分39秒
Build Host  : c1bj.rdu2.centos.org
Relocations : (not relocatable)
Packager    : CBS <[email protected]>
Vendor      : CentOS
URL         : http://www.docker.com
Summary     : Automates deployment of containerized applications
Description :
Docker is an open-source engine that automates the deployment of any
application as a lightweight, portable, self-sufficient container that will
run virtually anywhere.

Lo reproduzco por docker 1.3.2 del repositorio oficial de CentOS7.

$ rpm -qi docker
Name        : docker
Version     : 1.3.2
Release     : 4.el7.centos
Architecture: x86_64
Install Date: 2015年03月22日 02時44分58秒
Group       : Unspecified
Size        : 25505685
License     : ASL 2.0
Signature   : RSA/SHA256, 2014年12月11日 04時21分03秒, Key ID 24c6a8a7f4a80eb5
Source RPM  : docker-1.3.2-4.el7.centos.src.rpm
Build Date  : 2014年12月11日 04時15分49秒
Build Host  : worker1.bsys.centos.org
Relocations : (not relocatable)
Packager    : CentOS BuildSystem <http://bugs.centos.org>
Vendor      : CentOS
URL         : http://www.docker.com
Summary     : Automates deployment of containerized applications

Docker 1.5.0 tiene el mismo error
Error response from daemon: Cannot destroy container 485bf8d6502a: Driver devicemapper failed to remove root filesystem 485bf8d6502a6cf448075d20c529eb24f09a41946a5dd1c61a99e17

El mismo problema aquí, fácil de reproducir.

docker run -it --name busybox --rm busybox tail -f /dev/null

On another shell:

root<strong i="6">@staging5</strong>:/home/shopmedia #service docker stop
Stopping docker:                                           [  OK  ]
root<strong i="7">@staging5</strong>:/home/shopmedia #service docker start
Starting docker:                                           [  OK  ]
root<strong i="8">@staging5</strong>:/home/shopmedia #docker rm -f busybox
Error response from daemon: Cannot destroy container busybox: Driver devicemapper failed to remove root filesystem 124cd3329e0fafa6be2a284b36a75571666745436c601a702a4beedb75adc7c0: Device is Busy
FATA[0011] Error: failed to remove one or more containers

Medio ambiente

docker version
Client version: 1.4.1
Client API version: 1.16
Go version (client): go1.3.3
Git commit (client): 5bc2ff8/1.4.1
OS/Arch (client): linux/amd64
Server version: 1.4.1
Server API version: 1.16
Go version (server): go1.3.3
Git commit (server): 5bc2ff8/1.4.1

cat /etc/centos-release
CentOS release 6.6 (Final)

cat /proc/version
Linux version 2.6.32-504.8.1.el6.x86_64 ([email protected]) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC) ) #1 SMP Wed Jan 28 21:11:36 UTC 2015

rpm -q device-mapper
device-mapper-1.02.90-2.el6_6.1.x86_64

EDITAR: La única solución para mí (no estoy usando system.d) es actualizar /etc/init.d/docker, línea 50 con el comando unshare. La solución ha sido proporcionada por @vbatts , gracias por cierto
Sin embargo, esta solución no es escalable. No queremos actualizar todas las máquinas que poseemos + Se borrará la próxima vez que actualicemos la ventana acoplable.

1. ¿Cuáles son mis otras opciones?
2. ¿Está saliendo una ventana acoplable fija?
3. ¿Está afectando a todos los sistemas operativos?
4. ¿Está afectando a todos los núcleos?

Gracias

Creo que https://github.com/docker/docker/pull/12400 solucionará esto. Esto se debe a que el cierre del daemon de la ventana acoplable dejará los contenedores en ejecución sin limpiar (si los contenedores no se matan en 10 segundos, el rootfs del contenedor seguirá estando montado) y no se podrá eliminar en el próximo inicio del daemon. (Pruebo en superposición)

Gracias @ coolljt0725 .

1) ¿Qué versión de Docker se implementará?
2) ¿Cuáles son mis otras opciones?
3) ¿Está afectando a todos los sistemas operativos?
4) ¿Está afectando a todos los núcleos?

Gracias

+1 para la solución alternativa de desmontaje. Me pasó con Docker 1.6.0, compilación 4749651.
El reinicio de la ventana acoplable del servicio no lo resolvió. desmontar el 'volumen' problemático lo arregló.

Docker 1.6.1 (Ubuntu 14.04) todavía tiene este problema. umount funciona.

Docker 1.6.2 (Ubuntu 14.04) umount no funciona

Docker 1.7.0 Centos 6.5 todavía tiene los mismos problemas.

Acabo de recibir esto en Centos 6.3 después de actualizar a Docker 1.7. La actualización reinició la ventana acoplable (obviamente), y cuando fui a reiniciar los contenedores, todos mis contenedores node.js se reiniciaron, pero los que ejecutan uwsgi dan el error:

# docker start 48596c91d263
Error response from daemon: Cannot start container 48596c91d263: Error getting container 48596c91d263e44201f9141e7bc701ab9e11fe691c61eadc95019fcfa0e4a549 from driver devicemapper: Error mounting '/dev/mapper/docker-8:17-262147-48596c91d263e44201f9141e7bc701ab9e11fe691c61eadc95019fcfa0e4a549' on '/local/docker/devicemapper/mnt/48596c91d263e44201f9141e7bc701ab9e11fe691c61eadc95019fcfa0e4a549': device or resource busy

Hacer un umount /local/docker/devicemapper/mnt/48596c91d263e44201f9141e7bc701ab9e11fe691c61eadc95019fcfa0e4a549 NO solucionó el problema.

Lo mismo en Debian. No se puede iniciar ningún contenedor, incluso cuando se obtiene una imagen de hola mundo totalmente nueva.

root<strong i="6">@vamp1</strong>:~# docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from hello-world
a8219747be10: Pull complete 
91c95931e552: Already exists 
hello-world:latest: The image you are pulling has been verified. Important: image verification is a tech preview feature and should not be relied on to provi
de security.
Digest: sha256:aa03e5d0d5553b4c3473e89c8619cf79df368babd18681cf5daeb82aab55838d
Status: Downloaded newer image for hello-world:latest
Error response from daemon: Cannot start container 69be8cff86828d1f4ca3db9eeeeb1a8891ce1e305bd07847108750a0051846ff: device or resource busy

Client version: 1.7.0
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 0baf609
OS/Arch (client): linux/amd64
Server version: 1.7.0
Server API version: 1.19
Go version (server): go1.4.2
Git commit (server): 0baf609
OS/Arch (server): linux/amd64

PRETTY_NAME="Debian GNU/Linux 7 (wheezy)"
NAME="Debian GNU/Linux"
VERSION_ID="7"
VERSION="7 (wheezy)"

@tnolet Proporcione la salida docker info .

@unclejack El docker info para mi anfitrión es

$ docker info
Containers: 24
Images: 128
Storage Driver: devicemapper
 Pool Name: docker-8:17-262147-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: 
 Metadata file: 
 Data Space Used: 2.897 GB
 Data Space Total: 107.4 GB
 Data Space Available: 104.5 GB
 Metadata Space Used: 7.918 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.14 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Library Version: 1.02.89-RHEL6 (2014-09-01)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.10.81-1.el6.elrepo.x86_64
Operating System: <unknown>
CPUs: 4
Total Memory: 7.812 GiB
Name: radioedit-app101
ID: RY22:ODAC:5NT5:MSBZ:Y52X:L33V:UCHA:IOIL:SR23:YX3U:IILJ:J44R
WARNING: No swap limit support

@tdterry RHEL 6 y CentOS 6 ya no son compatibles con Red Hat para su uso con Docker. Actualice a RHEL 7 o CentOS 7.

Docker es compatible oficialmente con Centos 6.5 (https://docs.docker.com/installation/centos/). Además, hemos actualizado el kernel a 3.10. Otras personas aquí informan que el error también existe en CentOS 7. Parece más un problema de mapeo de dispositivos que un problema de versión CentOS. No tengo ninguna razón para creer que actualizar a CentOS 7 hará algo diferente.

Acabo de tener esto en CentOS 7, Docker versión 1.6.0, compilación 4749651 con devicemapper. Todos mis 15 contenedores se estrellaron. Estoy tratando de eliminar algunas imágenes colgantes y obtengo el mismo error:

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

Containers: 25
Images: 237
Storage Driver: devicemapper
 Pool Name: docker-253:2-8594920394-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: xfs
 Data file: 
 Metadata file: 
 Data Space Used: 22.03 GB
 Data Space Total: 107.4 GB
 Data Space Available: 85.34 GB
 Metadata Space Used: 25.47 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.122 GB
 Udev Sync Supported: false
 Library Version: 1.02.82-git (2013-10-04)
Execution Driver: native-0.2
Kernel Version: 3.10.0-229.4.2.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 24
Total Memory: 141.5 GiB
Name: localhost.localdomain

@amalagaura con el demonio detenido, ejecutando mount | grep docker puede mostrar un par de directorios montados (como /dev/mapper/docker-253:2-7995406-6296eddc5eaca30246c02d9b9c956161825bd7e92882a357214e091feba6f9b0 on ... ). puede umount estos primero, luego iniciar el demonio nuevamente. Si el problema persiste, dmsetup ls | grep docker y vea entradas como docker-253:2-7995406-6296eddc5eaca30246c02d9b9c956161825bd7e92882a357214e091feba6f9b0 (253:5) . De los cuales puedes llamar dmsetup remove docker-253:2-7995406-6296eddc5eaca30246c02d9b9c956161825bd7e92882a357214e091feba6f9b0

@vbatts Gracias por la ayuda. Nuestro verdadero problema es que nuestro grupo de producción de 15 máquinas acaba de morir. Esta es una discusión diferente, pero ¿qué se debe hacer si queremos soporte en Docker?

Tengo un problema similar después de actualizar a 1.7, estaba funcionando bien en 1.6.2 en elementaryOS.

Siempre que inicio cualquier contenedor, recibo el mensaje

Respuesta de error del demonio: No se puede iniciar el contenedor 560640442c770dff574f5af7b6cdcc8e86ba8a613db87bf90a77aea7f0db322a: dispositivo o recurso ocupado

Purgué docker, rm -rf / var / lib / docker, y con la instalación nueva todavía obtengo el mismo error al ejecutar la imagen hello-world.

También noté que las carpetas se acumulan en / var / docker / lib / aufs / mnt después de cada intento fallido.

Estoy presionando esto con mucha frecuencia y estoy usando aufs, no devicemapper:

$ sudo docker info
Containers: 3
Images: 2278
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 2284
 Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.5.0-54-generic
Operating System: Ubuntu precise (12.04.2 LTS)
CPUs: 8
Total Memory: 7.725 GiB
Name: (omitted)
ID: DWS4:G2M5:XD2Q:CQKA:5OXF:I3RB:6M6F:GUVO:NUFM:KKTF:4RB2:X3HP

Avíseme si hay más información de depuración que pueda proporcionar.

Viendo el mismo problema. umount no funciona, dice que la carpeta no está montada. Observé esto con Docker 1.5.0, luego actualicé a 1.7.1 con el mismo efecto.

$ docker info
Containers: 15
Images: 91
Storage Driver: devicemapper
 Pool Name: docker-202:1-149995-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: 
 Metadata file: 
 Data Space Used: 2.225 GB
 Data Space Total: 107.4 GB
 Data Space Available: 105.1 GB
 Metadata Space Used: 5.03 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.142 GB
 Udev Sync Supported: false
 Deferred Removal Enabled: false
 Library Version: 1.02.82-git (2013-10-04)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-40-generic
Operating System: Ubuntu 14.04.1 LTS
CPUs: 1
Total Memory: 3.676 GiB
WARNING: No swap limit support

Viendo lo mismo en ubuntu 14.04

$ docker info
Containers: 6
Images: 537
Storage Driver: devicemapper
 Pool Name: docker-8:1-262623-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file:
 Metadata file:
 Data Space Used: 7.546 GB
 Data Space Total: 107.4 GB
 Data Space Available: 99.83 GB
 Metadata Space Used: 19.05 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.128 GB
 Udev Sync Supported: false
 Deferred Removal Enabled: false
 Library Version: 1.02.82-git (2013-10-04)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-52-generic
Operating System: Ubuntu 14.04.2 LTS
CPUs: 2
Total Memory: 2.939 GiB
Name: test-app
ID: F5T4:5AIR:TDBZ:DGH4:WBFT:ZX6A:FVSA:DI4O:5HE2:CJIV:VVLZ:TGDS
WARNING: No swap limit support

$ docker version
Client version: 1.7.1
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 786b29d
OS/Arch (client): linux/amd64
Server version: 1.7.1
Server API version: 1.19
Go version (server): go1.4.2
Git commit (server): 786b29d
OS/Arch (server): linux/amd64

Estoy a punto de ejecutar una aplicación y, si este problema se resuelve, no puedo usar la ventana acoplable en producción porque ya experimenté que un contenedor se bloqueó y no pude eliminarlos sin reiniciar el sistema, lo cual es una molestia para un sistema de producción.

@trompx devicemapper con la sincronización de udev deshabilitada no va a funcionar.
Es parte de la razón por la que ahora ofrecemos binarios dinámicos (que solucionan el problema de sincronización) en lugar de binarios estáticos.
Recomendaría reemplazar sus repositorios de get.docker.com (y el paquete lxc-docker) con el repositorio apt.dockerproject.org (y el paquete docker-engine).
Consulte http://blog.docker.com/2015/07/new-apt-and-yum-repos/ para obtener más detalles.

También hay un nuevo estado de contenedor (ish) llamado "muerto", que se establece cuando hubo problemas para eliminar el contenedor. Esto, por supuesto, es una solución para este problema en particular, que le permite investigar por qué existe el error device or resource busy (probablemente una condición de carrera), en cuyo caso puede intentar eliminarlo nuevamente o intentar hacerlo manualmente arreglar (por ejemplo, desmontar los soportes sobrantes y luego quitarlos).

Tal vez los controladores de gráficos puedan ser un poco más resistentes en los casos en que tengamos algún tipo de carrera con el fs (por ejemplo, intentar desmontarlo de nuevo).

@ cpuguy83 Gracias por la información. Ahora estoy usando la última versión con udev verdadero, pero mientras intentaba configurar un sistema de monitoreo de registro, ocurrió un problema que resultó en que todos mis contenedores con el estado "Exited (137)", luego "dead" y tratar de eliminarlos me impiden eliminándolos "Respuesta de error del demonio: No se puede destruir el contenedor 9ca0b5642a55: El controlador de dispositivos no pudo eliminar el sistema de archivos raíz". Entonces todavía tengo este problema.

No pude ver lo que sucedió cuando uso el controlador syslog (para intentar configurar mi sistema de registro), por lo que realmente no sé qué sucedió. Te haré saber si soluciono esto.

@trompx Si están colgando de la instalación anterior, podría causar un problema.
Una vez que los contenedores están en un estado "muerto", puede docker rm -f volver a eliminarlos de la ventana acoplable y no deberían volver a aparecer. Es probable que falten los archivos y que devicemapper no pueda encontrarlos.

Me las arreglé para hacer que se bloqueara nuevamente, pero con ese controlador de registro de tiempo json activado. Después de verificar los registros de todos los contenedores, solo el haproxy devuelve alguna entrada útil "/run.sh: fork: No se puede asignar memoria". Tenía un poco poca memoria sin intercambio, y debí haberme quedado sin memoria. Si esa es la causa, ¿significa que Docker se bloqueará cuando se quede sin memoria, saliendo así de todos los contenedores?

@trompx Ciertamente, nada impide que Docker muera a OOM.
Los contenedores no se cierran si la ventana acoplable fallara; sin embargo, cuando la ventana acoplable inicia la copia de seguridad, mata todos los contenedores en ejecución (e inicia los que tienen una política de reinicio).

Veo esto con bastante frecuencia cuando uso docker-compose 1.4.2 y docker-engine 1.8.3 en Ubuntu 14.04.

@superdump versión del kernel?

@gionn : 3.13.0-65-genérico

@superdump @gionn lo mismo

en AWS con SSD de EBS

¿Alguien ha probado con Docker 1.9 para ver si se ha solucionado? Ha habido algunos trabajos relacionados con los volúmenes ...

Los volúmenes (en el sentido de extender los datos fuera del ciclo de vida del contenedor) son una característica diferente de lo que se ve afectado aquí, ¿no es así?

Si no compartir montajes es una solución viable para estos problemas, ¿no puede Docker hacer eso de forma predeterminada cuando se inicia el demonio?
Eso debería ser lo suficientemente simple de implementar.

Es sencillo de hacer y hay varias formas de realizar esta tarea. los
los mantenedores no querían aceptar solicitudes de extracción que hicieran esto porque
fue un "truco".
El viernes 27 de noviembre de 2015 a las 6:49 a.m. Andreas Stenius [email protected]
escribió:

Si dejar de compartir montajes es una solución viable para estos problemas, no se puede hacer la ventana acoplable
que por defecto cuando el demonio se inicia ..?
Eso debería ser lo suficientemente simple de implementar.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/docker/docker/issues/5684#issuecomment -160153438.

Eso no es cierto. Tuvimos esto y causó problemas, por lo que lo revertimos. Es trivial para usted hacerlo si no le causa ningún problema.

Gracias por la info. Hemos agregado el "truco" para dejar de compartir en un par de nodos,
ver cómo va...
fre 27 nov. 2015 kl. 19:01 skrev Brian Goff [email protected] :

Eso no es cierto. Tuvimos esto y causó problemas, por lo que lo revertimos.
Es trivial para usted hacerlo si no le causa ningún problema.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/docker/docker/issues/5684#issuecomment -160182860.

Hola,

Recibo el problema discutido anteriormente cuando uso Docker.

Failed to remove container (da3b06dc0723): Error response from daemon: Unable to remove filesystem for da3b06dc072328112eec54d7b0e00c2c355a8ef471e1ba3c82ab3ffb8e93891f: remove /var/lib/docker/containers/da3b06dc072328112eec54d7b0e00c2c355a8ef471e1ba3c82ab3ffb8e93891f/shm: device or resource busy
Failed to remove container (99cfba26be16): Error response from daemon: Unable to remove filesystem for 99cfba26be16bf7b475aaa4ed3d50f7fca3179082decc60f1418d22745f5a855: remove /var/lib/docker/containers/99cfba26be16bf7b475aaa4ed3d50f7fca3179082decc60f1418d22745f5a855/shm: device or resource busy
Failed to remove container (c34922906202): Error response from daemon: Unable to remove filesystem for c34922906202713a573a45f18f8db45ad6788bde2255f75b0f0e027800721b26: remove /var/lib/docker/containers/c34922906202713a573a45f18f8db45ad6788bde2255f75b0f0e027800721b26/shm: device or resource busy

La información de mi versión de Docker es la siguiente:
Cliente:
Versión: 1.10.2
Versión de API: 1.22
Go versión: go1.5.3
Confirmación de Git: c3959b1
Construido: lun Feb 22 21:37:01 2016
SO / Arch: linux / amd64

Servidor:
Versión: 1.10.2
Versión de API: 1.22
Go versión: go1.5.3
Confirmación de Git: c3959b1
Construido: lun Feb 22 21:37:01 2016
SO / Arch: linux / amd64

Cabe señalar que me encontré con este problema muy recientemente. He estado trabajando con Docker cerca de un año.

Hola,
Solo quería mencionar que después de reiniciar mi computadora, descubrí que los contenedores que no se eliminaron anteriormente se habían eliminado. Esto resuelve el problema en cuestión, pero aún así será irritante tener contenedores acumulados y siempre tener que reiniciar el sistema operativo.

@chirangaalwis +1. ¿Ha notado que esto sucede después de que el contenedor ha estado funcionando durante algún tiempo o ocurre directamente después de iniciar el contenedor?

Hola,
Bueno, por lo que puedo recordar, experimenté esto después de un tiempo considerable desde el inicio de los contenedores. No después de mucho tiempo para ser precisos.

Por cierto, sería bueno si alguien pudiera dar una explicación detallada de la razón detrás de este problema. Soy relativamente nuevo en el concepto de contenerización.

@chirangaalwis ha revisado este problema: https://github.com/docker/docker/issues/17902 Parece que podría ser específico de la versión del kernel. Voy a actualizar el kernel en la máquina en la que estaba experimentando el problema en el próximo día y veré si eso lo resuelve.

+1. Sí, parece que sí, incluso la versión de mi kernel es 3.13. Sí, también verificaré con esto, mapas con lo que he informado.

@chirangaalwis @kabobbob ... Estoy en RHEL 7.2 y kernel 3.10.

[root<strong i="7">@pe2enpmas301</strong> npmo-server]# uname -a
Linux pe2enpmas301.corp.intuit.net 3.10.0-327.3.1.el7.x86_64 #1 SMP Fri Nov 20 05:40:26 EST 2015 x86_64 x86_64 x86_64 GNU/Linux

Al detener e iniciar contenedores usando docker-compose , constantemente obtengo este error ...

Recreating npmoserver_policyfollower_1
ERROR: Driver devicemapper failed to remove root filesystem 3bb07965510f2c398c0fc99c3e0ce4696914f710efabc47f2df19ecf85725021: Device is Busy

La única solución es detenerse y esperar unos segundos antes de volver a intentarlo. El problema es que no se garantiza que el reinicio funcione. A veces intento reiniciar varias veces.

@chirangaalwis @marcellodesales Pude actualizar el servidor al kernel 3.16 e intenté detener el contenedor y rm. Todo pareció funcionar bien. Necesitará trabajar y ver si el problema se resuelve.

@kabobbob, por favor, informe en un par de días si eso resultó funcionar mejor ... Intentaré actualizar mis entornos previos a la producción e informar.

Tenía esto en rhel 7.2: una actualización de yum && systemctl reboot lo solucionó.

Estaba usando LVM directo y Docker versión 1.9.1

También estoy teniendo este problema. Mi configuración: Ubuntu 14.04, actualizado al kernel "3.19.0-58-generic # 64 ~ 14.04.1-Ubuntu". Docker versión 1.11.0, compilación 4dc5990. "docker-compose versión 1.7.0, compilación 0d7bf73".

Cuando docker-compose up -d reinicia un contenedor debido a una nueva imagen, a menudo termina sin poder eliminar el contenedor detenido.

Solo un reinicio ayudará a poder iniciar el contenedor. Entonces el problema no es 100% reproducible pero ocurre muy a menudo. Así que me veo obligado a reiniciar la máquina host con frecuencia :-(

$ docker rm 5435d816c9a3_dockercomposeui_docker-compose-ui_1
Error response from daemon: Driver devicemapper failed to remove root filesystem 5435d816c9a35c63a5a636dc56b7d9052f1681ae21d604127b1685dab3848404: Device is Busy

y

# docker ps -a | grep dockercomposeui
5435d816c9a3        c695fdb43f7a                          "/env/bin/python /app"   2 days ago          Dead                                                                                                                   5435d816c9a3_dockercomposeui_docker-compose-ui_1

@dsteinkopf ¿Se

No, el problema ya existía al usar Docker 1.10 y con el kernel ubuntu 14.04 predeterminado (~ 3.10, creo) y al usar aufs. Luego actualicé (paso a paso) el controlador de almacenamiento, el kernel y la ventana acoplable. Ningún cambio significativo en el problema experimentado ...

¿Crees que vale la pena intentar la superposición sobre este problema? (El rendimiento no es un gran problema en mi caso).

@thaJeztah Nunca vi este problema antes y desde que

¿Se encontró con esto después de actualizar de 1.10 a 1.11?

Tengo este problema :(

Todavía tengo esto encendido
RHEL 7.2 kernel-3.10.0-327.el7.x86_64
Docker versión 1.9.1, compilación 78ee77d / 1.9.1
mapeador-de-dispositivos-libs-1.02.107-5.el7_2.1.x86_64

También tengo el problema:

docker rm agent4 Error response from daemon: Driver aufs failed to remove root filesystem 16a3129667975c411d0084b38ba512761b64eaa7853f3452a7f8e4f2898d1175: rename /var/lib/docker/aufs/diff/76125e9141ec9de7c12e20d41b00cb44826b19bedf98bd9c650cb7a7cc07913a /var/lib/docker/aufs/diff/76125e9141ec9de7c12e20d41b00cb44826b19bedf98bd9c650cb7a7cc07913a-removing: device or resource busy

versión docker

Client:
 Version:      1.11.0
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   4dc5990
 Built:        Wed Apr 13 18:26:49 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.11.0
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   4dc5990
 Built:        Wed Apr 13 18:26:49 2016
 OS/Arch:      linux/amd64

información de docker

Containers: 9
 Running: 8
 Paused: 0
 Stopped: 1
Images: 80
Server Version: 1.11.0
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 193
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge null host
Kernel Version: 3.16.0-4-amd64
Operating System: Debian GNU/Linux 7 (wheezy)
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 31.45 GiB
Name: chell
ID: BXX3:THMK:SWD4:FP35:JPVM:3MV4:XJ7S:DREY:O6XO:XYUV:RHXO:KUBS
Docker Root Dir: /var/lib/docker
Debug mode (client): false
Debug mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No memory limit support
WARNING: No swap limit support
WARNING: No kernel memory limit support
WARNING: No oom kill disable support
WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support

uname -a

Linux chell 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-1 (2016-03-06) x86_64 GNU/Linux

Esta es una combinación de diferentes problemas. Creo que debemos cerrar esto. Ninguno de los últimos casos reportados se parece en nada al OP.

@guenhter Sospecho que esto está relacionado con otro problema con el montaje de / var / run en un contenedor (cualquier otro contenedor en su host) o el montaje de / var / lib / docker

@guenhter Para el registro # 21969

Además, muchos de los problemas anteriores a 1.11 con errores de tipo "dispositivo o recurso ocupado" probablemente se deben a eliminar el demonio (sin gracia) y luego volver a iniciarlo.
Esto hace que los recuentos de referencias internas de los montajes del controlador de almacenamiento se restablezcan a 0, mientras que los propios montajes siguen activos.
1.11 aborda ese caso.

Cierre por las razones indicadas anteriormente.

Lo siento, no estoy seguro de entender esto. ¿Qué quiere decir con "Ninguno de los últimos casos notificados se parece en nada al PO"?
¿Qué debo hacer yo (y otras personas que experimentan este problema)? ¿Abrir otro caso?

@dsteinkopf Sí, con todos los detalles que pueda proporcionar (componer archivos, registros de demonios, etc.).

Hola, solo para tener en cuenta el problema que he especificado anteriormente, he actualizado la versión de mi kernel a 4.4.0-21-generic y la información de la versión de Docker es la siguiente:
Cliente:
Versión: 1.11.0
Versión de API: 1.23
Go versión: go1.5.4
Confirmación de Git: 4dc5990
Construido: Wed Apr 13 18:38:59 2016
SO / Arch: linux / amd64

Servidor:
Versión: 1.11.0
Versión de API: 1.23
Go versión: go1.5.4
Confirmación de Git: 4dc5990
Construido: Wed Apr 13 18:38:59 2016
SO / Arch: linux / amd64

El problema informado anteriormente parece haber dejado de ocurrir. Usé Docker durante un tiempo considerable actualizando las versiones del kernel y parecía haberse detenido.

Encontré una solución para el problema, al menos cuando se usa con docker-compose, consulte https://github.com/docker/docker/issues/3786#issuecomment -221601065

El mismo problema con un contenedor que no se reinicia.

Ubuntu 14.04
Kernel: 3.13.0-24-genérico
Versión de Docker:

Client:
 Version:      1.11.0
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   4dc5990
 Built:        Wed Apr 13 18:34:23 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.11.0
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   4dc5990
 Built:        Wed Apr 13 18:34:23 2016
 OS/Arch:      linux/amd64

Error:

Error response from daemon: Driver aufs failed to remove root filesystem 
802f3a6eb28f8f16bf8452675a389b1d8bf755e59c827d50bec9372420f4194a: 
rename /var/lib/docker/aufs/diff/79e53988cfddcc3fb9868316bd9d8c3d7a825fd09a8620553c148bd96243224f /var/lib/docker/aufs/diff/79e53988cfddcc3fb9868316bd9d8c3d7a825fd09a8620553c148bd96243224f-removing: 
device or resource busy

Desmontar falla:

umount: /var/lib/docker/devicemapper
/mnt/79e53988cfddcc3fb9868316bd9d8c3d7a825fd09a8620553c148bd96243224f is not mounted 
(according to mtab)

Esto sigue siendo un problema para nosotros (usando 1.11.2 en Ubuntu 14.04.4 LTS (con KVM) (3.13.0-88-generic)).

¿Hay algún boleto abierto al que pueda suscribirme para recibir actualizaciones?

@GameScripting Ver # 21704

Linux zk1 3.10.0-327.28.3.el7.x86_64 (centos 7)
Docker versión 1.12.1, compilación 23cf638

Respuesta de error del demonio: Driver devicemapper no pudo eliminar el sistema de archivos raíz 228f2c2da3de4d5abd3881184aeb330a4c18e4311ecf404e2fb8cd4ffe15e901: devicemapper: Error al ejecutar DeleteDevice dm_task_run fallado

Me encontré con esto. /etc/init.d/docker restart ayudó, estoy feliz de que esto no estuviera en una máquina de producción ... 😢

$ docker --version
Docker version 1.11.1, build 5604cbe

Sigo recibiendo esto también

$ docker --version
Docker version 1.12.2, build bb80604

El mismo problema, ha estado sucediendo en muchas versiones de Docker. Utilizo docker-compose para recrear contenedores. A veces funciona limpiamente, a veces no. Reiniciar el demonio de la ventana acoplable o reiniciar el servidor limpia el contenedor defectuoso.

Arch Linux; contenedores devicemapper en ext4 FS.

$ docker version
Client:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.7.3
 Git commit:   6b644ec
 Built:        Thu Oct 27 19:42:59 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.7.3
 Git commit:   6b644ec
 Built:        Thu Oct 27 19:42:59 2016
 OS/Arch:      linux/amd64
$ docker info
Containers: 24
 Running: 22
 Paused: 0
 Stopped: 2
Images: 56
Server Version: 1.12.3
Storage Driver: devicemapper
 Pool Name: docker-8:3-13500430-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 10.74 GB
 Backing Filesystem: xfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 9.394 GB
 Data Space Total: 107.4 GB
 Data Space Available: 78.15 GB
 Metadata Space Used: 24.82 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.123 GB
 Thin Pool Minimum Free Space: 10.74 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 WARNING: Usage of loopback devices is strongly discouraged for production use. Use `--storage-opt dm.thinpooldev` to specify a custom block storage device.
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.135 (2016-09-26)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.7.2-1-ARCH
Operating System: Arch Linux
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 30.85 GiB
Name: omega
ID: IR7W:NSNN:F2B3:YP32:YTQJ:OFEB:2XLK:HHCK:HJ33:5K3O:KEHI:SDUB
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Insecure Registries:
 127.0.0.0/8
$ df -T
Filesystem     Type     1K-blocks      Used Available Use% Mounted on
dev            devtmpfs  16169500         0  16169500   0% /dev
run            tmpfs     16173076      2712  16170364   1% /run
/dev/sda3      ext4     447260560 371064976  53453004  88% /
tmpfs          tmpfs     16173076         0  16173076   0% /dev/shm
tmpfs          tmpfs     16173076         0  16173076   0% /sys/fs/cgroup
tmpfs          tmpfs     16173076      1144  16171932   1% /tmp
/dev/sda1      ext4        289293     45063    224774  17% /boot
tmpfs          tmpfs      3234612         8   3234604   1% /run/user/1000
/dev/sdb2      ext4     403042160  15056296 367489480   4% /run/media/ivan/backup
/dev/sda4      ext4     480580312 320608988 135536228  71% /run/media/ivan/ARCHIVES
/dev/sdb3      ext4     225472980   1473948 212522604   1% /run/media/ivan/data

Si ayuda ...

Creo que estoy teniendo el mismo problema / similar aquí también. Si implementa un servicio usando compose up -d y luego actualiza el nombre de la imagen a uno diferente en compose.yaml y hace otro compose up -d, el compose falla con un error alrededor de devicemapper:

Error
ERROR: para <> Driver devicemapper no pudo eliminar el sistema de archivos raíz 216c098e0f051407863934c27111bd1e9b7561dff1c4d67c0f0d45a99505fa70: El dispositivo está ocupado

Información de versión:
versión docker
Cliente:
Versión: 1.12.1
Versión de API: 1.24
Go versión: go1.6.3
Confirmación de Git: 23cf638
Construido:
SO / Arch: linux / amd64

Servidor:
Versión: 1.12.1
Versión de API: 1.24
Go versión: go1.6.3
Confirmación de Git: 23cf638
Construido:
SO / Arch: linux / amd64

Como solución temporal, agregué un docker-compose down --rmi all antes de volver a ejecutar el up.

También tengo el mismo problema en la versión de Docker: 1.12.3

Estoy bastante seguro de que el resto de las personas que están experimentando este problema están relacionadas con # 27381

Estoy viendo esto en la ventana acoplable 1.12.3 en CentOs 7

dc2-elk-02: / root / staging / ls-helper $ docker --version
Docker versión 1.12.3, compilación 6b644ec
dc2-elk-02: / root / staging / ls-helper $ uname -a
Linux dc2-elk-02 3.10.0-327.36.3.el7.x86_64 # 1 SMP Lunes 24 de octubre 16:09:20 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux
dc2-elk-02: / root / staging / ls-helper $ docker rm ls-helper
Respuesta de error del daemon: Driver devicemapper no pudo eliminar el sistema de archivos raíz e1b9cdeb519d2f4bea53a552c8b76c1085650aa76c1fb90c8e22cac9c2e18830: Device is Busy

PD: No estoy usando docker compose.

Mordido después de que el host se quede sin espacio en el disco.
Cualquier comando que afecte al punto de montaje se cuelga (incluidos "docker ps", "sync", "ls", ...)

Tuve un problema similar, vi estos me gusta de error en mi archivo / var / log / syslog:
Dec 16 14:32:18 rzing dockerd[3093]: time="2018-12-16T14:32:18.627417173+05:30" level=error msg="Failed to load container mount 00d7b9d64ff6c465276e67f5a5e3642ebacd9616c7602d4361b3a7fab038510a: mount does not exist" Dec 16 14:32:18 rzing dockerd[3093]: time="2018-12-16T14:32:18.627816711+05:30" level=error msg="Failed to load container mount fb108b942f8ed87a9e1affb6480ed477a8f5f823b2639e36348cde4a97924c5e: mount does not exist"
Intenté buscar el punto de montaje en /var/lib/docker/volumes pero no encontré ninguno
finalmente reinicie el sistema solucionó el problema