@vieira Reinicialize a máquina e nos informe se você ainda estiver tendo problemas.

As etapas acima são reproduzíveis mesmo depois de reiniciar a máquina.

@alexlarsson pode dar uma olhada? Parece estar relacionado ao mapeador de dispositivos

O problema parece estar relacionado ao mapeador de dispositivos. Eu acho que é realmente outra coisa.
Eu tentei isso, e o problema é a parte "parar o docker". Se eu apenas ctrl-c o daemon do docker, ele tentará parar os contêineres adequadamente, mas parece que nunca consegue parar o contêiner. Então, pressiono mais algumas vezes para forçar o docker a morrer.

Neste ponto, o contêiner (cauda) ainda está em execução, então o dispositivo mapeador de dispositivos será montado, o que significa que não podemos montá-lo novamente ou removê-lo. É por isso que essas operações falham.

@alexlarsson você conhece uma maneira fácil de limpar o sistema quando isso dá errado?

Bem, se você encontrar o processo de contêiner em fuga, talvez possa forçá-lo a eliminá-lo.

@vieira você pode desmontar:
umount / var / lib / docker / devicemapper / mnt / c39206003c7ae8992a554a9ac2ea130327fc4af1b2c389656c34baf9a56c84b5

e inicie o contêiner novamente, ele deve funcionar

Posso ver que meu docker foi iniciado com -d e -r. Primeiro, quando o docker é reiniciado, os contêineres não são reiniciados. Então o erro mencionado acima acontece (ao tentar iniciar o (s) container (s)).

Meu centos 6.5 ainda está recebendo 1.0.0.6 do epel. Isso já foi identificado como um bug no 1.0 e foi corrigido no 1.1? Alguém pode confirmar?

obrigado

Olá a todos, ainda não corrigido em 1.1.1.
As etapas na postagem original ainda se aplicam.

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

Estou recebendo muitos também, mas parece remover o contêiner de alguma forma (no sentido de que posso iniciar um novo contêiner com o mesmo nome)

Existe uma solução alternativa para esse problema?

Procurando uma solução alternativa também.

Parece que todos os contêineres foram interrompidos antes que o daemon do docker corrija o problema.

Eu adicionei este bloco pre-stop ao meu trabalho inicial como uma solução alternativa:

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

Aqui está um resumo das minhas etapas de depuração: https://gist.github.com/rochacon/4dfa7bd4de3c5f933f0d

@rochacon Obrigado por sua solução alternativa. Vou testar hoje ou amanhã com o 1.2 (parece que você testou com o 1.1.1, certo?). Espero que funcione.

@vieira Também tentei com 1.2.0, mesmos resultados.

Após 4 semanas de execução, um dos meus contêineres parou ... Não tenho certeza por que ... Como posso encontrar a causa raiz?

Enfim, tive o mesmo problema ... Resolvi com a sugestão de

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 vendo isso no 1.3.0 agora, em um sistema EC2 Ubuntu que foi atualizado de 12.04 para 14.04. Minha instância dev é uma instalação direta 14.04 no Vagrant e não tem esse problema. Desmontar e reiniciar os contêineres parece funcionar, mas isso anula o propósito de tê-los configurados para reiniciar automaticamente quando a instância for reinicializada ou quando o docker for reiniciado. Deixe-me saber se há mais informações que eu possa fornecer sobre versões de pacotes de suporte, etc, uma vez que tenho um sistema funcional e um não funcional disponível.

Observando o mesmo problema com docker 1.3 Ubuntu 14.04 com kernel Linux 3.13 ou 3.14.

@srobertson você está se referindo a "contêineres não sendo reiniciados quando o daemon é reiniciado"? Você está usando a nova _per-container_ restart-policy? Porque todo o daemon -r / --restart=true foi removido do Docker 1.2

A nova política de reinicialização (por contêiner) é descrita na referência CLI

+1, tenho esse problema no docker 1.3 @ ArchLinux x86_64 com kernel 3.17.2-1-ARCH.

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

Umount resolve o problema.

umount é uma solução alternativa, não diria que resolve o problema. Basta reiniciar o daemon com os contêineres em execução para reproduzir o problema.

umount funciona para mim na seguinte versão do docker:

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

Parei o daemon do docker primeiro e então:

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

@ mlehner616 Sim, você está certo. Desculpe, é claro que é uma solução alternativa, não uma solução. Isso foi apenas uma má escolha de palavras.

Eu gostaria de ver isso corrigido também, ofc. =)

fyi, desmontado não funcionou para mim. Recebo um erro informando que não há montagem encontrada em / etc / mtab
Docker versão 1.0.0, compilação 63fe64c / 1.0.0 no RHEL 6.5

Eu resolvi isso desmontando automaticamente qualquer montagem antiga quando o docker daemon voltar. Eu não queria corrigir o grande /etc/init/docker.conf do ubuntu, então coloquei uma pequena linha em /etc/default/docker vez disso:

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

Isso parece fazer o truque. Combinei isso com o gerenciamento de inicialização e reaparecimento de meus contêineres docker reais, então agora, depois de service docker restart , todos os contêineres simplesmente voltarão.

Obrigado, @jypma , isso funcionou para mim também!

_reveja a sessão_ com

Usaremos esse problema como rastreador para a maioria dos relatórios de "dispositivo ou recurso ocupado" ou EBUSY .

Este problema, como outros, é atenuado manipulando adequadamente o namespace de montagem do daemon do docker. Atualmente não há manipulação padrão do namespace de montagem, portanto, temos problemas como este EBUSY.

Enquanto trabalhamos na solução oficial para lidar com isso, existem soluções que você pode aplicar. Consulte http://blog.hashbangbash.com/2014/11/docker-devicemapper-fix-for-device-or-resource-busy-ebusy/

Confirmando que também encontrei esse problema usando a imagem stock freeipa. Parei o serviço docker e quando tentei reiniciá-lo junto com o contêiner ipa, obtive o seguinte.

$ 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

A desmontagem do "suporte" contornou o problema para que eu pudesse reiniciar o contêiner.

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

$ docker start ipa
ipa

Usando o seguinte:

$  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 consertou meu problema

docker --version
Docker versão 1.3.2, build 39fa2fa

Portanto, a seguinte solução alternativa é um pouco mais permanente para o meu caso de uso.
Estou usando estritamente o Amazon linux (RedHat6-Like), então fiz uma ligeira modificação no script de inicialização (que provavelmente seria sobrescrito se o docker fosse atualizado). Basicamente, tudo o que isso está fazendo é parar o docker normalmente, verificando as montagens do docker restantes , se houver algum, ele os desmonta. YMMV

_ / etc / init.d / docker_
Adicionando variável lib (linha ~ 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"

Adicionando bloco umount para parar a função (linha ~ 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
}

Estou tendo o mesmo problema com o docker 1.4.1 usando o mapeador de dispositivo como driver de armazenamento. Consegui coletar um rastreamento de pilha de pânico do docker por meio de seu arquivo de log.

MEIO AMBIENTE

$ cat / etc / * release
DISTRIB_ID = Ubuntu
DISTRIB_RELEASE = 14.04
DISTRIB_CODENAME = confiável
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/ "

versão $ docker
sudo: incapaz de resolver host ip-172-30-0-39
Versão do cliente: 1.4.1
Versão da API do cliente: 1.16
Versão Go (cliente): go1.3.3
Git commit (cliente): 5bc2ff8
OS / Arch (cliente): linux / amd64
Versão do servidor: 1.4.1
Versão API do servidor: 1.16
Versão Go (servidor): go1.3.3
Git commit (servidor): 5bc2ff8

$ tail -f / var / log / upstart / docker
...
INFO [143413] -job execResize (3dfcbc075227d5b3f0115bd73a1fea4a56a2c0fc68190d84b6d88e93938b4121, 37, 130)
2015/01/22 22:29:22 http: pânico servindo @: erro de tempo de execução: endereço de memória inválido ou desreferência de ponteiro nulo
goroutine 1932 [em execução]:
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
criado por net / http. (* Servidor) .Serve
/usr/local/go/src/pkg/net/http/server.go:1721 + 0x313

...

INFO [0056] DELETE /v1.16/containers/hoopla_docker_registry
INFO [0056] + job rm (hoopla_docker_registry)
Não é possível destruir o contêiner hoopla_docker_registry: Driver devicemapper falhou ao remover o sistema de arquivos raiz 6abcbfefe8bdd485dfb192f8926
3add895cda1ae28b578d4a0d9b23574dedc5c: o dispositivo está ocupado
INFO [0066] -job rm (hoopla_docker_registry) = ERR (1)
ERRO [0066] Manipulador para DELETE / containers / { name :. *} erro retornado: Não é possível destruir o contêiner hoopla_docker_registry: Drive
r devicemapper falhou ao remover o sistema de arquivos raiz 6abcbfefe8bdd485dfb192f89263add895cda1ae28b578d4a0d9b23574dedc5c: o dispositivo está ocupado

ERRO [0066] Erro HTTP: statusCode = 500 Não é possível destruir o contêiner hoopla_docker_registry: Driver devicemapper falhou ao remover o sistema de arquivos raiz 6abcbfefe8bdd485dfb192f89263add895cda1ae28b578d4a0d9b23574dedc5c: O dispositivo está ocupado

Eu estava vendo isso no ubuntu 14.04 (no ec2) com 1.4.1 e também não com 1.5. É estranho, porque o docker parece muito confiável no linux mint 17, mas muito confiável no nosso servidor de compilação com o ubuntu 14.04.

Existe uma maneira de não usar o mapeador de dispositivos, já que esse problema parece existir desde 0,9 dias?

Isso pode acontecer com overlayfs também.

Bem, acabei de mudar para aufs e até agora sem problemas.

Qual é a situação desse problema? Eu vi alguns PRs serem mesclados que poderiam estar relacionados, mas nada que declarasse claramente era uma solução para isso. Este é um problema _maior_ na produção e a única solução agora é corrigir o script de inicialização para desmontar corretamente as unidades.

depois de revisar novamente, este não é um exemplo ideal do EBUSY que dissemos originalmente.
Este caso tem mais a ver com os pids de um contêiner não manipulando os sinais com elegância.

Visto que o caso de reprodução aqui tail -f /dev/null não está saindo em SIGQUIT quando o daemon é encerrado, o driver devmapper não pode desmontar corretamente (isso não é exclusivo do devmapper). Antes de o daemon ser iniciado novamente, você pode ver o tail -f /dev/null ainda em execução, mesmo quando o docker não está.

Um problema como este exigirá pensamentos sobre como tratar drasticamente os pids no contêiner na saída do docker ... @unclejack @crosbymichael pensamentos?

Testei isso no Fedora 21 x86_64. Fornecendo informações para fins de comparação apenas quando o problema não parece estar presente (mais?). Mesmos resultados usando centos: 7 ou 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

Informação do 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

Basta encontrar isso no 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

executar umount /var/lib/docker/devicemapper/mnt/f3a7515112a0b5af94b0520844ef8c586763d2051b41b1db90e4c4efbd07e774 ajudou entretanto.

Tenho o mesmo problema no 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 falha.

[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)

Meio 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.

Eu o reproduzo pelo docker 1.3.2 do repositório oficial do 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 tem o mesmo bug
Error response from daemon: Cannot destroy container 485bf8d6502a: Driver devicemapper failed to remove root filesystem 485bf8d6502a6cf448075d20c529eb24f09a41946a5dd1c61a99e17

O mesmo problema aqui, fácil de reproduzir

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

Meio 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

EDIT: A única solução alternativa para mim (não estou usando system.d) é atualizar /etc/init.d/docker, linha 50 com o comando unshare. A correção foi fornecida por @vbatts , obrigado btw
No entanto, essa correção não é escalonável. Não queremos atualizar todas as máquinas que possuímos + Ele será apagado na próxima vez que atualizarmos o docker.

1. Quais são minhas outras opções?
2. Há uma correção do lado do docker saindo?
3. Está afetando todo o sistema operacional?
4. Está afetando todos os kernels?

obrigado

Acho que https://github.com/docker/docker/pull/12400 vai consertar isso. Isso ocorre porque o desligamento do daemon do docker deixará os containers em execução não limpos (se os containers não forem eliminados em 10 segundos, o rootfs do container ainda será montado) e não poderá ser removido na próxima inicialização do daemon. (Eu testo em sobreposição)

Obrigado @ coolljt0725 .

1) Qual versão do docker será implementada?
2) Quais são minhas outras opções?
3) Está afetando todo o sistema operacional?
4) Está afetando todos os kernels?

obrigado

1 para a solução alternativa umount. aconteceu comigo com docker 1.6.0, build 4749651.
a reinicialização do docker de serviço não resolveu. umount o problemático 'volume' consertou.

O Docker 1.6.1 (Ubuntu 14.04) ainda apresenta esse problema. umount funciona.

Docker 1.6.2 (Ubuntu 14.04) umount não funciona

O Docker 1.7.0 Centos 6.5 ainda apresenta os mesmos problemas.

Acabei de receber isso no Centos 6.3 após atualizar para o Docker 1.7. A atualização reiniciou o docker (obviamente), e quando fui reiniciar os contêineres, todos os meus contêineres node.js foram reiniciados, mas aqueles que executam uwsgi apresentam o erro:

# 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

Fazer um umount /local/docker/devicemapper/mnt/48596c91d263e44201f9141e7bc701ab9e11fe691c61eadc95019fcfa0e4a549 NÃO resolveu o problema.

O mesmo no Debian. Não é possível iniciar nenhum contêiner, mesmo ao puxar uma imagem de hello-world totalmente nova.

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 Forneça a saída de docker info .

@unclejack O docker info para meu anfitrião é

$ 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 e CentOS 6 não são mais suportados pelo Red Hat para uso com Docker. Faça upgrade para RHEL 7 ou CentOS 7.

Docker suporta oficialmente Centos 6.5 (https://docs.docker.com/installation/centos/). Além disso, atualizamos o kernel para 3.10. Outras pessoas aqui relatam que o erro existe no CentOS 7 também. Parece mais um problema de mapeador de dispositivos do que um problema de versão do CentOS. Não tenho razão para acreditar que atualizar para o CentOS 7 fará algo diferente.

Acabei de fazer isso no CentOS 7, Docker versão 1.6.0, build 4749651 com devicemapper. Todos os meus 15 contêineres travaram. Estou tentando remover algumas imagens pendentes e estou recebendo o mesmo erro:

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 com o daemon parado, executando mount | grep docker pode mostrar alguns diretórios montados (como /dev/mapper/docker-253:2-7995406-6296eddc5eaca30246c02d9b9c956161825bd7e92882a357214e091feba6f9b0 on ... ). você pode umount estes primeiro, depois iniciar o daemon novamente. Se o problema persistir, dmsetup ls | grep docker e veja entradas como docker-253:2-7995406-6296eddc5eaca30246c02d9b9c956161825bd7e92882a357214e091feba6f9b0 (253:5) . Dos quais você pode chamar dmsetup remove docker-253:2-7995406-6296eddc5eaca30246c02d9b9c956161825bd7e92882a357214e091feba6f9b0

@vbatts Obrigado pela ajuda. Nosso verdadeiro problema é que nosso cluster de produção de 15 máquinas acabou de morrer. Esta é uma discussão diferente, mas o que deve ser feito se quisermos suporte no docker?

Eu tive um problema semelhante depois de atualizar para o 1.7, ele estava funcionando bem no 1.6.2 no elementaryOS.

Sempre que eu inicio qualquer contêiner, recebo a mensagem

Resposta de erro do daemon: não é possível iniciar o contêiner 560640442c770dff574f5af7b6cdcc8e86ba8a613db87bf90a77aea7f0db322a: dispositivo ou recurso ocupado

Limpei o docker, rm -rf / var / lib / docker e, com a nova instalação, ainda recebo o mesmo erro ao executar a imagem hello-world.

Também notei que as pastas se acumulam em / var / docker / lib / aufs / mnt após cada tentativa falhada.

Estou acessando isso com extrema frequência e estou usando aufs, não o mapeador de dispositivos:

$ 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

Avise-me se houver mais informações de depuração que eu possa fornecer.

Vendo o mesmo problema. umount não funciona, diz que a pasta não está montada. Observei isso com o docker 1.5.0, depois atualizei para 1.7.1 com o mesmo efeito.

$ 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

Vendo o mesmo no 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

Estou prestes a executar um aplicativo e, independentemente de esse problema ser resolvido, não posso usar o docker na produção porque já experimentei algum contêiner travado e não consegui removê-lo sem reiniciar o sistema, o que é uma dor em um sistema de produção.

@trompx devicemapper com a sincronização do udev desabilitada não vai funcionar.
É parte do motivo pelo qual agora oferecemos binários dinâmicos (que corrigem o problema de sincronização) em vez de um binário estático.
Eu recomendaria substituir seus repositórios de get.docker.com (e o pacote lxc-docker) pelo repositório apt.dockerproject.org (e pacote docker-engine).
Consulte http://blog.docker.com/2015/07/new-apt-and-yum-repos/ para obter mais detalhes.

Há também um novo estado de contêiner (ish) chamado "morto", que é definido quando há problemas ao remover o contêiner. Obviamente, esta é uma solução alternativa para esse problema específico, que permite que você investigue por que existe o erro device or resource busy (provavelmente uma condição de corrida), caso em que você pode tentar remover novamente ou tentar manualmente corrigir (por exemplo, desmonte quaisquer montagens restantes e, em seguida, remova).

Talvez os drivers gráficos possam ser um pouco mais resilientes nos casos em que temos algum tipo de corrida com o fs (por exemplo, fazer com que ele tente desmontar novamente).

@ cpuguy83 Obrigado pela informação. Agora estou usando a última versão com udev true, mas enquanto tentava configurar um sistema de monitoramento de registro, ocorreu um problema que resultou em todo o meu contêiner com status "Exited (137)" e depois "morto" e tentar removê-los me impede de removendo-os "Resposta de erro do daemon: Não é possível destruir o container 9ca0b5642a55: Driver devicemapper falhou ao remover o sistema de arquivos raiz". Então, ainda tenho esse problema.

Não consegui ver o que aconteceu ao usar o driver syslog (para tentar configurar meu sistema de registro), então não sei realmente o que aconteceu. Eu vou deixar você saber se eu resolver isso.

@trompx Se eles estiverem pendurados na instalação anterior, isso pode causar um problema.
Depois que os contêineres estiverem em um estado "morto", você pode docker rm -f eles novamente para removê-los do docker e eles não devem aparecer novamente. É provável que os arquivos estejam faltando de forma que o mapeador de dispositivos não possa realmente localizá-los.

Consegui travar novamente, mas com aquele driver de log de tempo json ligado. Após verificar os logs de todos os contêineres, apenas o haproxy retorna alguma entrada útil "/run.sh: fork: Não é possível alocar memória". Eu estava com pouca memória sem swap e devo ter ficado sem memória. Se essa for a causa, isso significa que o Docker irá travar quando ficar sem memória, saindo de todos os contêineres?

@trompx Certamente nada está impedindo o Docker de ser morto por OOM.
Os contêineres não fecham se o docker travar, no entanto, quando o docker inicia o backup, ele mata todos os contêineres em execução (e inicia aqueles que têm uma política de reinicialização).

Estou vendo isso com bastante regularidade ao usar docker-compose 1.4.2 e docker-engine 1.8.3 no Ubuntu 14.04.

Versão do kernel

@gionn : 3.13.0-65-generic

@superdump @gionn idem para as mesmas versões de software, kernel 3.13.0-67-generic

na AWS usando SSDs EBS

Alguém já tentou usar o docker 1.9 para ver se ele foi corrigido? Tem havido algum trabalho relacionado a volumes ...

Volumes (no sentido de estender os dados fora do ciclo de vida do contêiner) é um recurso diferente do que está sendo afetado aqui, não é?

Se a montagem não compartilhada for uma solução viável para esses problemas, o docker não pode fazer isso por padrão quando o daemon é iniciado ..?
Isso deve ser simples o suficiente de implementar.

É simples de fazer e existem várias maneiras de realizar essa tarefa. o
os mantenedores não queriam aceitar solicitações de pull que fizessem isso porque
foi um "hack".
Na sexta-feira, 27 de novembro de 2015 às 6h49 Andreas Stenius [email protected]
escrevi:

Se a montagem não compartilhada for uma solução viável para esses problemas, o docker não pode fazer
que por padrão quando o daemon é iniciado ..?
Isso deve ser simples o suficiente de implementar.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/docker/issues/5684#issuecomment -160153438.

Isso não é verdade. Tínhamos isso e causou problemas, então, revertemos. É trivial para você fazer isso se não causar nenhum problema.

Obrigado pela informação. Adicionamos o "hack" de não compartilhamento em alguns nós,
veja como vai ...
fre 27 nov. 2015 kl. 19:01 skrev Brian Goff [email protected] :

Isso não é verdade. Tínhamos isso e causou problemas, então, revertemos.
É trivial para você fazer isso se não causar nenhum problema.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/docker/issues/5684#issuecomment -160182860.

Oi,

Estou recebendo o problema discutido acima ao usar o 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

As informações da minha versão do Docker são as seguintes:
Cliente:
Versão: 1.10.2
Versão API: 1.22
Versão Go: go1.5.3
Git commit: c3959b1
Construído: Seg, 22 de fevereiro, 21:37:01 2016
OS / Arch: linux / amd64

Servidor:
Versão: 1.10.2
Versão API: 1.22
Versão Go: go1.5.3
Git commit: c3959b1
Construído: Seg, 22 de fevereiro, 21:37:01 2016
OS / Arch: linux / amd64

Deve-se notar que me deparei com esse problema muito recentemente. Trabalho com o Docker há quase um ano.

Oi,
Só queria dizer que, depois de reiniciar meu computador, descobri que os recipientes não removidos anteriormente haviam sido removidos. Isso resolve o problema em questão, mas ainda assim será irritante ter contêineres acumulados e sempre ter que reiniciar o sistema operacional.

@chirangaalwis +1. Você percebeu que isso acontece depois que o contêiner já está em execução por algum tempo ou ocorre diretamente após iniciar o contêiner?

Oi,
Bem, pelo que me lembro, experimentei isso depois de um tempo considerável desde o início dos containers. Não depois de muito tempo para ser mais preciso.

A propósito, seria bom se alguém pudesse dar uma explicação completa do motivo por trás desse problema. Sou relativamente novo no conceito de conteinerização.

@chirangaalwis você verificou este problema: https://github.com/docker/docker/issues/17902 Parece que pode ser específico para a versão do kernel. Vou atualizar o kernel da máquina em que estava tendo o problema no dia seguinte ou depois e ver se isso resolve o problema.

+1. Sim, parece que sim, até a minha versão do kernel é 3.13. Sim, também vou verificar isso, mapas com o que relatei.

@chirangaalwis @kabobbob ... Estou no RHEL 7.2 e no 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

Ao parar e iniciar contêineres usando docker-compose , eu sempre recebo este erro ....

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

A única solução é parar e aguardar alguns segundos antes de tentar novamente. O problema é que não é garantido que a reinicialização funcione. Às vezes, tento reiniciar várias vezes.

@chirangaalwis @marcellodesales Consegui atualizar o servidor para o kernel 3.16 e tentei parar o contêiner e rm. Tudo parecia funcionar bem. Vai precisar trabalhar e ver se o problema foi resolvido.

@kabobbob, por favor, relate em alguns dias se funcionou melhor ... Vou tentar atualizar meus ambientes de pré-produção e relatar.

Tinha isso no rhel 7.2 - uma atualização yum && systemctl reboot corrigiu.

Estava usando LVM direto e Docker versão 1.9.1

Eu também estou tendo este problema. Minha configuração: Ubuntu 14.04, atualizado para o kernel "3.19.0-58-generic # 64 ~ 14.04.1-Ubuntu". Docker versão 1.11.0, compilação 4dc5990. "docker-compose version 1.7.0, build 0d7bf73".

Quando docker-compose up -d reinicia um contêiner por causa de uma nova imagem, geralmente não consegue remover o contêiner interrompido.

Apenas uma reinicialização ajudará a iniciar o contêiner. Então o problema não é 100% reproduzível, mas acontece com muita frequência. Portanto, sou forçado a reiniciar a máquina host com frequência :-(

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

e

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

@dsteinkopf Você se

Não, o problema já existia usando docker 1.10 e com o kernel 14.04 padrão do ubuntu (~ 3.10 eu acho) e usando aufs. Então eu atualizei (passo a passo) o driver de armazenamento, kernel e docker. Nenhuma mudança significativa no problema experimentado ...

Você acha que vale a pena tentar uma sobreposição a respeito desse problema? (Desempenho não é um grande problema no meu caso.)

@thaJeztah nunca vi esse problema antes e desde que

Você se deparou com isso depois de atualizar de 1.10 para 1.11

Eu tenho este problema :(

Ainda tenho isso
RHEL 7.2 kernel-3.10.0-327.el7.x86_64
Docker versão 1.9.1, compilação 78ee77d / 1.9.1
device-mapper-libs-1.02.107-5.el7_2.1.x86_64

Também tenho o 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

versão 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

informação do 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 é uma mistura de questões diferentes. Acho que precisamos fechar isso. Nenhum dos últimos casos relatados é parecido com o OP.

@guenhter Suspeito que isso esteja relacionado a outro problema com a montagem de / var / run em um contêiner (qualquer outro contêiner em seu host) ou montagem de / var / lib / docker

@guenhter Para o registro # 21969

Além disso, muitos dos problemas anteriores ao 1.11 com erros do tipo "dispositivo ou recurso ocupado" são mais prováveis ​​de matar o daemon (desajeitadamente) e, em seguida, reiniciá-lo.
Isso faz com que as contagens de referência internas nas montagens do driver de armazenamento sejam redefinidas para 0, enquanto as próprias montagens ainda estão ativas.
1.11 trata desse caso.

Fechamento pelos motivos acima indicados.

Desculpe - não tenho certeza se entendi isso. O que você quer dizer com "Nenhum dos casos mais recentes relatados se parece com o OP"?
O que devo (e outras pessoas com este problema) fazer? Abrir outro caso?

@dsteinkopf Sim, com o máximo de detalhes que você puder fornecer (arquivos de composição, logs daemon, etc.).

Olá, apenas para observar o problema que eu especifiquei anteriormente. Eu atualizei minha versão do kernel para 4.4.0-21-generic e as informações da versão do docker são as seguintes:
Cliente:
Versão: 1.11.0
Versão API: 1.23
Versão Go: go1.5.4
Git commit: 4dc5990
Construído: Quarta, 13 de abril, 18:38:59 de 2016
OS / Arch: linux / amd64

Servidor:
Versão: 1.11.0
Versão API: 1.23
Versão Go: go1.5.4
Commit do Git: 4dc5990
Construído: Quarta, 13 de abril, 18:38:59 de 2016
OS / Arch: linux / amd64

O problema relatado anteriormente parece ter parado de ocorrer. Usei o Docker por um tempo considerável, atualizando as versões do kernel e parecia ter parado.

Encontrou uma solução alternativa para o problema, pelo menos quando usado com docker-compose, consulte https://github.com/docker/docker/issues/3786#issuecomment -221601065

O mesmo problema ocorre com um contêiner que não consegue reiniciar.

Ubuntu 14.04
Kernel: 3.13.0-24-genérico
Versão 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

Erro:

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

Falha ao desmontar:

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

Isso ainda é um problema para nós (usando 1.11.2 no Ubuntu 14.04.4 LTS (com KVM) (3.13.0-88-genérico)).

Existe algum tíquete em aberto que eu possa assinar para receber atualizações?

@GameScripting Consulte # 21704

Linux zk1 3.10.0-327.28.3.el7.x86_64 (centos 7)
Docker versão 1.12.1, compilação 23cf638

Resposta de erro do daemon: Driver devicemapper falhou ao remover o sistema de arquivos raiz 228f2c2da3de4d5abd3881184aeb330a4c18e4311ecf404e2fb8cd4ffe15e901: devicemapper: Erro ao executar DeleteDevice dm_task_run falhou

Apenas corri para isso. /etc/init.d/docker restart ajudou, estou feliz que não foi em uma máquina de produção ... 😢

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

Ainda estou entendendo isso também

$ docker --version
Docker version 1.12.2, build bb80604

O mesmo problema tem acontecido em muitas versões do Docker. Eu uso docker-compose para recriar recipientes. Às vezes funciona de forma limpa, às vezes não. Reiniciar o docker daemon ou reinicializar o servidor limpa o contêiner defeituoso.

Arch Linux; contêineres devicemapper no 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

Se ajudar ...

Eu acredito que estou tendo o mesmo problema / semelhante aqui também. Se implantar um serviço usando compose up -d e, em seguida, atualizar o nome da imagem para um nome diferente no compose.yaml e fazer outra composição -d, a composição falhará com erro ao redor do devicemapper:

Erro
ERROR: for <> Driver devicemapper falhou ao remover o sistema de arquivos raiz 216c098e0f051407863934c27111bd1e9b7561dff1c4d67c0f0d45a99505fa70: o dispositivo está ocupado

Versão informação:
versão docker
Cliente:
Versão: 1.12.1
Versão API: 1.24
Versão Go: go1.6.3
Git commit: 23cf638
Construído:
OS / Arch: linux / amd64

Servidor:
Versão: 1.12.1
Versão API: 1.24
Versão Go: go1.6.3
Git commit: 23cf638
Construído:
OS / Arch: linux / amd64

Como solução temporária, adicionei um docker-compose down --rmi antes de executar o up novamente.

Eu também tenho o mesmo problema na versão do Docker: 1.12.3

Tenho quase certeza de que o restante das pessoas que estão enfrentando esse problema está relacionado ao # 27381

Estou vendo isso no docker 1.12.3 no CentOs 7

dc2-elk-02: / root / staging / ls-helper $ docker --version
Docker versão 1.12.3, compilação 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 Seg 24 de outubro 16:09:20 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux
dc2-elk-02: / root / staging / ls-helper $ docker rm ls-helper
Resposta de erro do daemon: Driver devicemapper falhou ao remover o sistema de arquivos raiz e1b9cdeb519d2f4bea53a552c8b76c1085650aa76c1fb90c8e22cac9c2e18830: O dispositivo está ocupado

PS Não estou usando o docker compose.

Mordido após o host ficar sem espaço em disco.
Qualquer comando que afete o ponto de montagem trava (incluindo "docker ps", "sync", "ls", ...)

Eu tive um problema semelhante, vi estes erros como no meu arquivo / 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"
Tentei pesquisar o ponto de montagem em /var/lib/docker/volumes mas não encontrei nenhum
finalmente reinicie o sistema corrigiu o problema