você teria um caso de teste reduzido para mostrar isso? Talvez um pequeno Dockerfile para o que está no contêiner e um script bash que faz o trabalho de iniciar / parar / ... os contêineres?

O contêiner está em dockerhub kinvey / blrunner # v0.3.8

Usando a API remota com as seguintes opções:

CRIO
Imagem: 'kinvey / blrunner # v0.3.8'
AttachStdout: false
AttachStderr: false
ExposedPorts: {'7000 / tcp': {}}
Tty: falso
HostConfig:
PublishAllPorts: true
CapDrop: [
"CHOWN"
"DAC_OVERRIDE"
"FOWNER"
"MATAR"
"SETGID"
"SETPCAP"
"NET_BIND_SERVICE"
"NET_RAW"
"SYS_CHROOT"
"MKNOD"
"SETFCAP"
"AUDIT_WRITE"
]
LogConfig:
Digite: "nenhum"
Config: {}

COMEÇAR

container.start

RETIRAR
força: verdadeiro

Hmm, você está observando o uso excessivo de recursos?
O fato de o ssh nem estar funcionando me deixa suspeito.
Pode muito bem ser um problema de inode com sobreposição ou muitos FDs abertos, etc.

Não particularmente no que diz respeito ao uso excessivo de recursos ... Mas o primeiro sintoma é o docker completamente travado enquanto outros processos funcionam alegremente ...

É importante observar que temos apenas 8 contêineres em execução a qualquer momento em qualquer instância.

Capturou algumas estatísticas em que o docker não está mais respondendo:

lsof | wc -l

mostra 1025.

No entanto, um erro aparece várias vezes:
lsof: AVISO: stat () não pode sobrepor o sistema de arquivos / var / lib / docker / overlay / aba7820e8cb01e62f7ceb53b0d04bc1281295c38815185e9383ebc19c30325d0 / mesclado
As informações de saída podem estar incompletas.

Saída de amostra do topo:

principais - 00:16:53 até 12:22, 2 usuários, média de carregamento: 2,01, 2,05, 2,05
Tarefas: 123 no total, 1 em execução, 121 dormindo, 0 parado, 1 zumbi
% Cpu (s): 0,3 us, 0,0 sy, 0,0 ni, 99,7 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 3853940 total, 2592920 usado, 1261020 livre, 172660 buffers
Troca de KiB: 0 total, 0 usado, 0 gratuito. 1115644 Mem em cache

24971 kinvey 20 0 992008 71892 10796 S 1,3 1,9 9: 11,93 nó
902 root 20 0 1365860 62800 12108 S 0.3 1.6 30: 06.10 docker
29901 ubuntu 20 0 27988 6720 2676 S 0,3 0,2 3: 58,17 tmux
1 root 20 0 33612 4152 2716 S 0,0 0,1 14: 22,00 init
2 root 20 0 0 0 0 S 0.0 0.0 0: 00.03 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0: 04.40 ksoftirqd / 0
5 root 0 -20 0 0 0 S 0,0 0,0 0: 00,00 kworker / 0: 0H
7 root 20 0 0 0 0 S 0,0 0,0 2: 21,81 rcu_sched
8 root 20 0 0 0 0 S 0,0 0,0 0: 01,91 rcu_bh

@mjsalinger A configuração que você está usando não é compatível. O motivo pelo qual não é compatível é que você está usando o Ubuntu 14.04 com um kernel personalizado.

De onde vem esse kernel 3.18.0-031800? Você notou que esta compilação do kernel está desatualizada? O kernel que você está usando foi construído em dezembro do ano passado.

Sinto muito, mas não há nada a ser depurado aqui. Este problema pode realmente ser um bug do kernel relacionado à sobreposição ou a algum outro bug do kernel já corrigido que não é mais um problema na versão mais recente do kernel 3.18.

Vou encerrar este problema. Por favor tente novamente com um kernel 3.18 atualizado ou mais recente e verifique se você está tendo o problema. Lembre-se de que há vários problemas abertos contra a sobreposição e que você provavelmente terá problemas com a sobreposição, mesmo depois de atualizar para a última versão do kernel e para a última versão do Docker.

@unclejack @ cpuguy83 @ LK4D4 Por favor, reabra este problema. Este foi um conselho para a configuração que estamos usando, fornecido especificamente pela equipe do docker e pela experimentação. Nós tentamos kernels mais novos (3.19 +) e eles têm um bug de kernel panic de algum tipo que estávamos encontrando - então o conselho era ir com 3.18 antes de dezembro porque havia um bug conhecido no kernel introduzido depois que causou um O pânico do kernel que estávamos enfrentando, que até onde sei, ainda não foi corrigido.

No que diz respeito ao OverlayFS, também me foi apresentado como o FS ideal para Docker depois de experimentar _numerosos_ problemas de desempenho com AUFS. Se esta não for uma configuração com suporte, alguém pode me ajudar a encontrar uma configuração estável e com desempenho que funcione neste caso de uso? Há vários meses que estamos nos esforçando para manter isso estável.

@mjsalinger Você pode fornecer o uso de inode para o volume em que o overlay está sendo executado? ( df -i /var/lib/docker deve fazer).

Obrigado por reabrir. Se a resposta for um kernel diferente, tudo bem, eu só quero chegar a um cenário estável.

df -i / ver / lib / docker

Inodes do sistema de arquivos IUsed IFree IUse% Montado em
/ dev / xvda1 1638400 643893 994507 40% /

A sobreposição ainda tem vários problemas: https://github.com/docker/docker/issues?q=is%3Aopen+is%3Aissue+label%3A%2Fsystem%2Foverlay

Eu não usaria sobreposição na produção. Outros comentaram sobre este rastreador de problemas que estão usando AUFS na produção e que é estável para eles.

Kernel 3.18 não é compatível com Ubuntu 14.04. A Canonical não oferece suporte para isso.

O AUFS em produção não tem nenhum desempenho e tem sido algo _mas_ estável para nós - eu costumava encontrar gargalos de I / O, travamentos, etc.

Vejo:

11228, # 12758, # 12962

Mudar para a sobreposição resolveu todos os problemas acima - temos apenas um problema restante.

Além disso:

http://developerblog.redhat.com/2014/09/30/overview-storage-scalability-docker/
http://qconlondon.com/system/files/presentation-slides/Docker%20Clustering.pdf

Parece que o Overlay está sendo apresentado como o direcionador de escolha pela comunidade em geral. Tudo bem se ainda não estiver estável, mas também não é AUFS e deve haver _alguma_ maneira de obter o desempenho e a estabilidade de que preciso com o Docker. Eu adoro experimentar coisas novas, mas em nossa configuração anterior (AUFS no Ubuntu 12.04 e AUFS no Ubuntu 14.04) não conseguimos estabilidade ou desempenho. Pelo menos com Overlay obtemos bom desempenho e melhor estabilidade - mas só precisamos resolver esse problema.

Também experimentei sintomas semelhantes a essas instâncias padrão do Ubuntu em execução no AUFS (12.04, 14.04 e 15.04).

10355 # 13940

Ambos os problemas desapareceram após a mudança para o Kernel atual e o OverlayFS.

@mjsalinger Eu recomendo usar o Ubuntu 14.04 com os pacotes do kernel 3.13 mais recentes. Estou usando isso sozinho e não encontrei nenhum desses problemas.

@unclejack Tentou isso e encontrou os problemas especificados acima com uso pesado e de alto volume (criando / destruindo muitos contêineres) e o AUFS teve um desempenho incrivelmente ruim. Portanto, essa não é uma opção.

@mjsalinger Você está usando o upstart para iniciar o docker? Qual é a aparência de /etc/init/docker.conf?

Sim, usando o upstart.

/etc/init/docker.conf

description "Docker daemon"

start on (local-filesystems and net-device-up IFACE!=lo)
stop on runlevel [!2345]
limit nofile 524288 1048576
limit nproc 524288 1048576

respawn

pre-start script
        # see also https://github.com/tianon/cgroupfs-mount/blob/master/cgroupfs-mount
        if grep -v '^#' /etc/fstab | grep -q cgroup \
                || [ ! -e /proc/cgroups ] \
                || [ ! -d /sys/fs/cgroup ]; then
                exit 0
        fi
        if ! mountpoint -q /sys/fs/cgroup; then
                mount -t tmpfs -o uid=0,gid=0,mode=0755 cgroup /sys/fs/cgroup
        fi
        (
                cd /sys/fs/cgroup
                for sys in $(awk '!/^#/ { if ($4 == 1) print $1 }' /proc/cgroups); do
                        mkdir -p $sys
                        if ! mountpoint -q $sys; then
                                if ! mount -n -t cgroup -o $sys cgroup $sys; then
                                        rmdir $sys || true
                                fi
                        fi
                done
        )
end script

script
        # modify these in /etc/default/$UPSTART_JOB (/etc/default/docker)
        DOCKER=/usr/bin/$UPSTART_JOB
        DOCKER_OPTS=
        if [ -f /etc/default/$UPSTART_JOB ]; then
                . /etc/default/$UPSTART_JOB
        fi
        exec "$DOCKER" -d $DOCKER_OPTS
end script

# Don't emit "started" event until docker.sock is ready.
# See https://github.com/docker/docker/issues/6647
post-start script
        DOCKER_OPTS=
        if [ -f /etc/default/$UPSTART_JOB ]; then
                . /etc/default/$UPSTART_JOB
        fi
        if ! printf "%s" "$DOCKER_OPTS" | grep -qE -e '-H|--host'; then
                while ! [ -e /var/run/docker.sock ]; do
                        initctl status $UPSTART_JOB | grep -qE "(stop|respawn)/" && exit 1
                        echo "Waiting for /var/run/docker.sock"
                        sleep 0.1
                done
                echo "/var/run/docker.sock is up"
        fi
end script

Também estamos vendo o seguinte ao executar qualquer comando do Docker em algumas instâncias, por exemplo ...

sudo docker ps

FATA [0000] Obtenha http: ///var/run/docker.sock/v1.18/containers/json? All = 1: disque unix /var/run/docker.sock: recurso temporariamente indisponível. Você está tentando se conectar a um TLS habilitado
daemon sem TLS?

@mjsalinger É apenas uma mensagem de erro

@mjsalinger O que os logs daemon do docker dizem durante isso? /var/log/upstart/docker.log deve ser o local.

Congelado, nenhuma entrada nova entrando. Aqui estão as últimas entradas no log:

INFO[46655] -job log(create, 48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46655] -job create() = OK (0)
INFO[46655] POST /containers/48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a/start
INFO[46655] +job start(48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a)
INFO[46655] +job allocate_interface(48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a)
INFO[46655] -job allocate_interface(48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a) = OK (0)
INFO[46655] +job allocate_port(48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a)
INFO[46655] POST /containers/create?Image=kinvey%2Fblrunner%3Av0.3.8&AttachStdout=false&AttachStderr=false&ExposedPorts=&Tty=false&HostConfig=
INFO[46655] +job create()
INFO[46655] DELETE /containers/4d447093f522f1d74f482b2f76c91adfd38b5ad264202b1c8262f05a0edaf187?force=true
INFO[46655] +job rm(4d447093f522f1d74f482b2f76c91adfd38b5ad264202b1c8262f05a0edaf187)
INFO[46656] -job allocate_port(48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a) = OK (0)
INFO[46656] +job log(start, 48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(start, 48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46656] +job log(create, 7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(create, 7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46656] -job create() = OK (0)
INFO[46656] +job log(die, 4d447093f522f1d74f482b2f76c91adfd38b5ad264202b1c8262f05a0edaf187, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(die, 4d447093f522f1d74f482b2f76c91adfd38b5ad264202b1c8262f05a0edaf187, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46656] +job release_interface(4d447093f522f1d74f482b2f76c91adfd38b5ad264202b1c8262f05a0edaf187)
INFO[46656] POST /containers/7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f/start
INFO[46656] +job start(7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f)
INFO[46656] +job allocate_interface(7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f)
INFO[46656] -job allocate_interface(7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f) = OK (0)
INFO[46656] +job allocate_port(7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f)
INFO[46656] -job release_interface(4d447093f522f1d74f482b2f76c91adfd38b5ad264202b1c8262f05a0edaf187) = OK (0)
INFO[46656] DELETE /containers/cb03fc14e5eab2acf01d1d42dec2fc1990cccca69149de2dc97873f87474db9b?force=true
INFO[46656] +job rm(cb03fc14e5eab2acf01d1d42dec2fc1990cccca69149de2dc97873f87474db9b)
INFO[46656] +job log(destroy, 4d447093f522f1d74f482b2f76c91adfd38b5ad264202b1c8262f05a0edaf187, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(destroy, 4d447093f522f1d74f482b2f76c91adfd38b5ad264202b1c8262f05a0edaf187, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46656] -job rm(4d447093f522f1d74f482b2f76c91adfd38b5ad264202b1c8262f05a0edaf187) = OK (0)
INFO[46656] +job log(die, cb03fc14e5eab2acf01d1d42dec2fc1990cccca69149de2dc97873f87474db9b, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(die, cb03fc14e5eab2acf01d1d42dec2fc1990cccca69149de2dc97873f87474db9b, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46656] +job release_interface(cb03fc14e5eab2acf01d1d42dec2fc1990cccca69149de2dc97873f87474db9b)
INFO[46656] DELETE /containers/1e8ddec281bd9b5bfe239d0e955874f83d51ffec95c499f88c158639f7445d20?force=true
INFO[46656] +job rm(1e8ddec281bd9b5bfe239d0e955874f83d51ffec95c499f88c158639f7445d20)
INFO[46656] -job allocate_port(7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f) = OK (0)
INFO[46656] +job log(start, 7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(start, 7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46656] -job start(48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a) = OK (0)
INFO[46656] POST /containers/create?Image=kinvey%2Fblrunner%3Av0.3.8&AttachStdout=false&AttachStderr=false&ExposedPorts=&Tty=false&HostConfig=
INFO[46656] +job create()
INFO[46656] +job log(create, 1ae5798d7aeec4857944b40a27f1a69789323bbe8edb8d67a250150241484830, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(create, 1ae5798d7aeec4857944b40a27f1a69789323bbe8edb8d67a250150241484830, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46656] -job create() = OK (0)
INFO[46656] +job log(die, 1e8ddec281bd9b5bfe239d0e955874f83d51ffec95c499f88c158639f7445d20, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(die, 1e8ddec281bd9b5bfe239d0e955874f83d51ffec95c499f88c158639f7445d20, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46656] +job release_interface(1e8ddec281bd9b5bfe239d0e955874f83d51ffec95c499f88c158639f7445d20)
INFO[46656] GET /containers/48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a/json
INFO[46656] +job container_inspect(48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a)
INFO[46656] -job container_inspect(48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a) = OK (0)
INFO[46656] POST /containers/1ae5798d7aeec4857944b40a27f1a69789323bbe8edb8d67a250150241484830/start
INFO[46656] +job start(1ae5798d7aeec4857944b40a27f1a69789323bbe8edb8d67a250150241484830)
INFO[46656] +job allocate_interface(1ae5798d7aeec4857944b40a27f1a69789323bbe8edb8d67a250150241484830)
INFO[46656] -job allocate_interface(1ae5798d7aeec4857944b40a27f1a69789323bbe8edb8d67a250150241484830) = OK (0)
INFO[46656] +job allocate_port(1ae5798d7aeec4857944b40a27f1a69789323bbe8edb8d67a250150241484830)
INFO[46656] -job release_interface(cb03fc14e5eab2acf01d1d42dec2fc1990cccca69149de2dc97873f87474db9b) = OK (0)
INFO[46656] -job start(7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f) = OK (0)
INFO[46656] GET /containers/7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f/json
INFO[46656] +job container_inspect(7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f)
INFO[46656] -job release_interface(1e8ddec281bd9b5bfe239d0e955874f83d51ffec95c499f88c158639f7445d20) = OK (0)
INFO[46656] -job container_inspect(7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f) = OK (0)
INFO[46656] +job log(destroy, cb03fc14e5eab2acf01d1d42dec2fc1990cccca69149de2dc97873f87474db9b, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(destroy, cb03fc14e5eab2acf01d1d42dec2fc1990cccca69149de2dc97873f87474db9b, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46656] -job rm(cb03fc14e5eab2acf01d1d42dec2fc1990cccca69149de2dc97873f87474db9b) = OK (0)
INFO[46656] +job log(destroy, 1e8ddec281bd9b5bfe239d0e955874f83d51ffec95c499f88c158639f7445d20, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(destroy, 1e8ddec281bd9b5bfe239d0e955874f83d51ffec95c499f88c158639f7445d20, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46656] -job rm(1e8ddec281bd9b5bfe239d0e955874f83d51ffec95c499f88c158639f7445d20) = OK (0)
INFO[46656] DELETE /containers/4cfeb48701f194cfd40f71d7883d82906d54a538084fa7be6680345e4651aa60?force=true
INFO[46656] +job rm(4cfeb48701f194cfd40f71d7883d82906d54a538084fa7be6680345e4651aa60)
INFO[46656] -job allocate_port(1ae5798d7aeec4857944b40a27f1a69789323bbe8edb8d67a250150241484830) = OK (0)
INFO[46656] +job log(start, 1ae5798d7aeec4857944b40a27f1a69789323bbe8edb8d67a250150241484830, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(start, 1ae5798d7aeec4857944b40a27f1a69789323bbe8edb8d67a250150241484830, kinvey/blrunner:v0.3.8) = OK (0)

@ cpuguy83 O log foi útil de alguma forma?

@mjsalinger Me faz pensar que há um impasse em algum lugar, pois nada mais indica um problema.

@ cpuguy83 Isso faria sentido, dados os sintomas. Há algo que eu possa fazer para ajudar a rastrear ainda mais esse problema e de onde ele vem?

Talvez possamos dar uma olhada para ver se ele está realmente travando.

Está bem. Trabalharemos para ver se conseguimos isso. Queríamos experimentar o 1.7 primeiro - fizemos isso, mas não notamos nenhuma melhora.

@ cpuguy83 De um dos hosts afetados:

root@<host>:~# strace -q -y -v -p 899
futex(0x134f1b8, FUTEX_WAIT, 0, NULL^C <detached ...>

@ cpuguy83 Alguma ideia?

Ver o seguinte em 1.7 com contêineres não sendo mortos / iniciados. Isso parece ser um precursor do problema (observe que não vi esses erros no 1.6, mas viu um volume de contêineres inativos começar a se acumular, embora um comando tenha sido emitido para eliminar / remover)

Error spawning container: Error: HTTP code is 404 which indicates error: no such container - Cannot start container 09c12c9f72d461342447e822857566923d5532280f9ce25659d1ef3e54794484: Link not found

Error spawning container: Error: HTTP code is 404 which indicates error: no such container - Cannot start container 5e29407bb3154d6f5778676905d112a44596a23fd4a1b047336c3efaca6ada18: Link not found

Error spawning container: Error: HTTP code is 404 which indicates error: no such container - Cannot start container be22e8b24b70e24e5269b860055423236e4a2fca08969862c3ae3541c4ba4966: Link not found

Error spawning container: Error: HTTP code is 404 which indicates error: no such container - Cannot start container c067d14b67be8fb81922b87b66c0025ae5ae1ebed3d35dcb4052155afc4cafb4: Link not found

Error spawning container: Error: HTTP code is 404 which indicates error: no such container - Cannot start container 7f21c4fd8b6620eba81475351e8417b245f86b6014fd7125ba0e37c6684e3e42: Link not found

Error spawning container: Error: HTTP code is 404 which indicates error: no such container - Cannot start container b31531492ab7e767158601c438031c8e9ef0b50b9e84b0b274d733ed4fbe03a0: Link not found

Error spawning container: Error: HTTP code is 500 which indicates error: server error - Cannot start container 477dc3c691a12f74ea3f07af0af732082094418f6825f7c3d320bda0495504a1: iptables failed: iptables --wait -t nat -A DOCKER -p tcp -d 0/0 --dport 32822 -j DNAT --to-destination 172.17.0.44:7000 ! -i docker0: iptables: No chain/target/match by that name.
 (exit status 1)

Error spawning container: Error: HTTP code is 404 which indicates error: no such container - Cannot start container 6965eec076db173f4e3b9a05f06e1c87c02cfe849821bea4008ac7bd0f1e083a: Link not found

Error spawning container: Error: HTTP code is 404 which indicates error: no such container - Cannot start container 7c721dd2b8d31b51427762ac1d0fe86ffbb6e1d7462314fdac3afe1f46863ff1: Link not found

Error spawning container: Error: HTTP code is 500 which indicates error: server error - Cannot start container c908d059631e66883ee1a7302c16ad16df3298ebfec06bba95232d5f204c9c75: iptables failed: iptables --wait -t nat -A DOCKER -p tcp -d 0/0 --dport 32837 -j DNAT --to-destination 172.17.0.47:7000 ! -i docker0: iptables: No chain/target/match by that name.
 (exit status 1)

Error spawning container: Error: HTTP code is 500 which indicates error: server error - Cannot start container c3e11ffb82fe08b8a029ce0a94e678ad46e3d2f3d76bed7350544c6c48789369: iptables failed: iptables --wait -t nat -A DOCKER -p tcp -d 0/0 --dport 32847 -j DNAT --to-destination 172.17.0.48:7000 ! -i docker0: iptables: No chain/target/match by that name.
 (exit status 1)

Resultado de docker.log de um incidente recente:

INFO[44089] DELETE /containers/4e455d01da8453688dd27cad41fea158757311c0c89f27619a728f272591ef25?force=true
INFO[44089] +job rm(4e455d01da8453688dd27cad41fea158757311c0c89f27619a728f272591ef25)
INFO[44089] DELETE /containers/a608bc1014317b083ac2f32a4c6c85dda65445420775e21d6406ca9146723c96?force=true
INFO[44089] +job rm(a608bc1014317b083ac2f32a4c6c85dda65445420775e21d6406ca9146723c96)
INFO[44089] +job log(die, 4e455d01da8453688dd27cad41fea158757311c0c89f27619a728f272591ef25, kinvey/blrunner:v0.3.8)
INFO[44089] -job log(die, 4e455d01da8453688dd27cad41fea158757311c0c89f27619a728f272591ef25, kinvey/blrunner:v0.3.8) = OK (0)
INFO[44089] +job release_interface(4e455d01da8453688dd27cad41fea158757311c0c89f27619a728f272591ef25)
INFO[44089] -job release_interface(4e455d01da8453688dd27cad41fea158757311c0c89f27619a728f272591ef25) = OK (0)
INFO[44089] +job log(die, a608bc1014317b083ac2f32a4c6c85dda65445420775e21d6406ca9146723c96, kinvey/blrunner:v0.3.8)
INFO[44089] -job log(die, a608bc1014317b083ac2f32a4c6c85dda65445420775e21d6406ca9146723c96, kinvey/blrunner:v0.3.8) = OK (0)
INFO[44089] +job release_interface(a608bc1014317b083ac2f32a4c6c85dda65445420775e21d6406ca9146723c96)
INFO[44089] -job release_interface(a608bc1014317b083ac2f32a4c6c85dda65445420775e21d6406ca9146723c96) = OK (0)
INFO[44092] +job log(destroy, 285274ee9c5b3bfa9fcea4d93b75e7e51949752b8d0eb101a31ea4f9aec5dad6, kinvey/blrunner:v0.3.8)
INFO[44092] -job log(destroy, 285274ee9c5b3bfa9fcea4d93b75e7e51949752b8d0eb101a31ea4f9aec5dad6, kinvey/blrunner:v0.3.8) = OK (0)
INFO[44092] -job rm(285274ee9c5b3bfa9fcea4d93b75e7e51949752b8d0eb101a31ea4f9aec5dad6) = OK (0)
INFO[44092] POST /containers/create?Image=kinvey%2Fblrunner%3Av0.3.8&AttachStdout=false&AttachStderr=false&ExposedPorts=&Tty=false&HostConfig=
INFO[44092] +job create()
INFO[44097] +job log(destroy, 4e455d01da8453688dd27cad41fea158757311c0c89f27619a728f272591ef25, kinvey/blrunner:v0.3.8)
INFO[44097] -job log(destroy, 4e455d01da8453688dd27cad41fea158757311c0c89f27619a728f272591ef25, kinvey/blrunner:v0.3.8) = OK (0)
INFO[44097] -job rm(4e455d01da8453688dd27cad41fea158757311c0c89f27619a728f272591ef25) = OK (0)
INFO[44097] POST /containers/create?Image=kinvey%2Fblrunner%3Av0.3.8&AttachStdout=false&AttachStderr=false&ExposedPorts=&Tty=false&HostConfig=
INFO[44097] +job create()
INFO[44098] +job log(destroy, c80a39f060f200f1aff8ae52538779542437745e4184ed02793f8873adcb9cd4, kinvey/blrunner:v0.3.8)
INFO[44098] -job log(destroy, c80a39f060f200f1aff8ae52538779542437745e4184ed02793f8873adcb9cd4, kinvey/blrunner:v0.3.8) = OK (0)
INFO[44098] -job rm(c80a39f060f200f1aff8ae52538779542437745e4184ed02793f8873adcb9cd4) = OK (0)
INFO[44098] POST /containers/create?Image=kinvey%2Fblrunner%3Av0.3.8&AttachStdout=false&AttachStderr=false&ExposedPorts=&Tty=false&HostConfig=
INFO[44098] +job create()
INFO[44098] +job log(create, 3b9a4635c068989ddb1983aa12460083e874d50fd42c743033ed3a08000eb7e9, kinvey/blrunner:v0.3.8)
INFO[44098] -job log(create, 3b9a4635c068989ddb1983aa12460083e874d50fd42c743033ed3a08000eb7e9, kinvey/blrunner:v0.3.8) = OK (0)
INFO[44098] -job create() = OK (0)
INFO[44098] POST /containers/3b9a4635c068989ddb1983aa12460083e874d50fd42c743033ed3a08000eb7e9/start
INFO[44098] +job start(3b9a4635c068989ddb1983aa12460083e874d50fd42c743033ed3a08000eb7e9)
INFO[44102] +job log(destroy, a608bc1014317b083ac2f32a4c6c85dda65445420775e21d6406ca9146723c96, kinvey/blrunner:v0.3.8)
INFO[44102] -job log(destroy, a608bc1014317b083ac2f32a4c6c85dda65445420775e21d6406ca9146723c96, kinvey/blrunner:v0.3.8) = OK (0)
INFO[44102] -job rm(a608bc1014317b083ac2f32a4c6c85dda65445420775e21d6406ca9146723c96) = OK (0)
INFO[44102] POST /containers/create?Image=kinvey%2Fblrunner%3Av0.3.8&AttachStdout=false&AttachStderr=false&ExposedPorts=&Tty=false&HostConfig=
INFO[44102] +job create()

@ cpuguy83 @ LK4D4 Alguma ideia / atualização?

Não tenho ideia do que pensar. Não é um impasse de software, porque até as informações do docker estão suspensas. Isso pode ser vazamento de memória?

PID USUÁRIO PR NI VIRT RES SHR S% CPU% MEM TEMPO + COMANDO
root 20 0 1314832 89688 11568 S 0,3 2,3 65: 47,56 docker

É isso que o processo Docker parece estar usando; não parece muito com um vazamento de memória para mim ...

Vou comentar sobre isso para dizer "nós também". Estamos usando o Docker para nossa infraestrutura de teste e somos atingidos por isso nas mesmas condições / cenários. Isso afetará nossa capacidade de usar o Docker de maneira significativa se travar sob carga.

Terei prazer em contribuir com resultados de solução de problemas se você me indicar o que você precisa como informação.

Acabei de ter o mesmo problema em um host CentOS7.

$ docker version
Client version: 1.6.2
Client API version: 1.18
Go version (client): go1.4.2
Git commit (client): ba1f6c3/1.6.2
OS/Arch (client): linux/amd64
Server version: 1.6.2
Server API version: 1.18
Go version (server): go1.4.2
Git commit (server): ba1f6c3/1.6.2
OS/Arch (server): linux/amd64

$ docker info
Containers: 7
Images: 672
Storage Driver: devicemapper
 Pool Name: docker-253:2-67171716-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: xfs
 Data file: /dev/mapper/vg01-docker--data
 Metadata file: /dev/mapper/vg01-docker--metadata
 Data Space Used: 54.16 GB
 Data Space Total: 59.06 GB
 Data Space Available: 4.894 GB
 Metadata Space Used: 53.88 MB
 Metadata Space Total: 5.369 GB
 Metadata Space Available: 5.315 GB
 Udev Sync Supported: true
 Library Version: 1.02.93-RHEL7 (2015-01-28)
Execution Driver: native-0.2
Kernel Version: 3.10.0-229.7.2.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 8
Total Memory: 31.25 GiB

Isso aconteceu em nosso sistema de CI. Mudei o número de trabalhos paralelos e iniciei 4 trabalhos em paralelo. Portanto, havia 4-6 contêineres em execução. A carga foi de cerca de 10 (com alguns dos 8 núcleos ainda ociosos).

Enquanto todos os contêineres estavam funcionando bem, o dockerd em si estava preso. docker images ainda mostraria imagens, mas todos os comandos deamon como docker ps ou docker info estagnaram.

Meu strace foi semelhante ao anterior:

strace -p 1194
Process 1194 attached
futex(0x11d2838, FUTEX_WAIT, 0, NULL

Depois de um tempo, todos os contêineres estavam concluídos com seus trabalhos (compilar, testar ...), mas nenhum "retornou". É como se estivessem esperando o dockerd.

Quando eu finalmente matei o dockerd, os contêineres terminaram com uma mensagem como esta:

time="2015-08-05T15:59:32+02:00" level=fatal msg="Post http:///var/run/docker.sock/v1.18/containers/9117731bd16a451b89fd938f569c39761b5f8d6df505256e172738e0593ba125/wait: EOF. Are you trying to connect to a TLS-enabled daemon without TLS?" 

Estamos vendo a mesma coisa que @filex no Centos 7 em nosso ambiente de CI

Containers: 1
Images: 19
Storage Driver: devicemapper
 Pool Name: docker--vg-docker--pool
 Pool Blocksize: 524.3 kB
 Backing Filesystem: xfs
 Data file:
 Metadata file:
 Data Space Used: 2.611 GB
 Data Space Total: 32.17 GB
 Data Space Available: 29.56 GB
 Metadata Space Used: 507.9 kB
 Metadata Space Total: 54.53 MB
 Metadata Space Available: 54.02 MB
 Udev Sync Supported: true
 Deferred Removal Enabled: true
 Library Version: 1.02.93-RHEL7 (2015-01-28)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.10.0-229.11.1.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 2
Total Memory: 7.389 GiB
Name: ip-10-1-2-234
ID: 5YVL:O32X:4NNA:ICSJ:RSYS:CNCI:6QVC:C5YR:XGR4:NQTW:PUSE:YFTA

Client version: 1.7.1
Client API version: 1.19
Package Version (client): docker-1.7.1-108.el7.centos.x86_64
Go version (client): go1.4.2
Git commit (client): 3043001/1.7.1
OS/Arch (client): linux/amd64
Server version: 1.7.1
Server API version: 1.19
Package Version (server): docker-1.7.1-108.el7.centos.x86_64
Go version (server): go1.4.2
Git commit (server): 3043001/1.7.1
OS/Arch (server): linux/amd64

O mesmo aqui: docker não estava respondendo a ps, rm, stop, run, info e provavelmente mais. Algumas reinicializações depois, tudo voltou ao normal.

 informação do docker
 Recipientes: 25
 Imagens: 1739
 Driver de armazenamento: devicemapper
 Nome da piscina: docker-9: 2-62521632-pool
 Tamanho do bloco da piscina: 65,54 kB
 Sistema de arquivos de backup: extfs
 Arquivo de dados: / dev / loop0
 Arquivo de metadados: / dev / loop1
 Espaço de dados usado: 96,01 GB
 Total de espaço de dados: 107,4 GB
 Espaço de dados disponível: 11,36 GB
 Espaço de metadados usado: 110,5 MB
 Total de espaço de metadados: 2,147 GB
 Espaço de metadados disponível: 2.037 GB
 Udev Sync Supported: true
 Remoção adiada ativada: falso
 Arquivo de loop de dados: / var / lib / docker / devicemapper / devicemapper / data
 Arquivo de loop de metadados: / var / lib / docker / devicemapper / devicemapper / metadata
 Versão da biblioteca: 1.02.93-RHEL7 (2015-01-28)
 Driver de execução: nativo-0.2
 Driver de registro: arquivo json
 Versão do kernel: 3.10.0-229.11.1.el7.x86_64
 Sistema operacional: CentOS Linux 7 (Core)
 CPUs: 8
 Memória total: 31,2 GiB
 Nome: CentOS-70-64-minimal
 ID: EM3I: PELO: SBH6: JRVL: AM6C: UM7W: XJWJ: FI5N: JO77: 7PMF: S57A: PLAT

 versão docker
 Versão do cliente: 1.7.1
 Versão da API do cliente: 1.19
 Versão do pacote (cliente): docker-1.7.1-108.el7.centos.x86_64
 Versão Go (cliente): go1.4.2
 Git commit (cliente): 3043001 / 1.7.1
 OS / Arch (cliente): linux / amd64
 Versão do servidor: 1.7.1
 Versão da API do servidor: 1.19
 Versão do pacote (servidor): docker-1.7.1-108.el7.centos.x86_64
 Versão Go (servidor): go1.4.2
 Git commit (servidor): 3043001 / 1.7.1
 OS / Arch (servidor): linux / amd64

Estou em 1.6.2 e 1.8.2 e minha configuração do docker também está derretendo sob carga. Parece que a fila de trabalhos do docker está se enchendo lentamente até o ponto em que qualquer nova chamada leva minutos. Ajustar o sistema de arquivos e manter um pequeno número de contêineres torna as coisas um pouco melhores. Ainda estou procurando por alguns padrões.

$ docker version
Client:
 Version:      1.8.2
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   44b3b67
 Built:        Mon Sep 14 23:56:40 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.2
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   44b3b67
 Built:        Mon Sep 14 23:56:40 UTC 2015
 OS/Arch:      linux/amd64

O mesmo aqui. Tenho certeza que estou feliz por ter encontrado este tópico, eu estava perdendo minha mente nas últimas duas semanas tentando ver qual poderia ser o problema.
Acho que é a quantidade de containers que estão sendo iniciados simultaneamente, parece um caso clássico de deadlock.

no meu caso, foi apenas um punhado de contêineres sendo iniciados simultaneamente (talvez 3-5). mas todos eles recebem um grande fluxo de entrada por meio de STDIN (da execução do docker), o que pode ter colocado um estresse extra no daemon.

@filex tem um caso de uso semelhante. Embora não tenhamos enfrentado esses congelamentos antes de migrarmos para 1.8.2

Hoje encontro problemas como este - docker ps frozen, docker eat 100% cpu.
E agora vejo que meu datadog-agent perguntou ao docker em loop sobre seus contêineres com esta opção:

collect_container_size: true

Portanto, eu tenho um loop infinito com operação muito difícil (tenho mais de 10 mil contêineres). Depois de interromper a integração do datadog com docker, a execução do sistema ok - docker ps funcionou, docker come 0% cpu.

Estou fazendo experiências com o cadvisor e também está derretendo o docker. Tente reduzir o número de contêineres mortos e retirados e veja se isso reduz a carga.

Você pode elaborar mais sobre suas descobertas?

Na quinta-feira, 1º de outubro de 2015, 00h23, Alexander Vagin [email protected] escreveu:

Hoje encontro problemas como este - docker ps frozen, docker eat 100% cpu.
E agora vejo que meu agente datadog perguntou ao docker em loop sobre
recipientes com esta opção:

collect_container_size: true

Então, eu tenho um loop infinito com operação muito difícil (tenho mais de 10k
recipientes). Depois de parar a integração do datadog com docker, o sistema rodando ok -
docker ps funcionou, docker come 0% cpu.

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

@ohade meu docker funciona sem qualquer congelamento 24/7. Em todas as vezes, ele tem 60-80 contêineres iniciados. Tenho cerca de 1.500 novos contêineres em um dia. Então quando vi que com esse load ele travava e só do docker (o sistema tem muita memória livre, io, cpu), achei que não fosse um problema comum.
Descobri que alguém envia solicitações para meu docker em logs (/var/log/upstart/docker.logs). E eu descobri quem era :)
O que dizer mais?

:) I mento, esse agente faz parte do docker e posso aumentá-lo
verificando também, ou é um agente externo?

Na quinta-feira, 1º de outubro de 2015, 14:03 Alexander Vagin [email protected] escreveu:

@ohade https://github.com/ohade meu docker funciona sem qualquer congelamento
24/7. Em todas as vezes, ele tem 60-80 contêineres iniciados. Eu tenho cerca de 1500 novos
recipientes em um dia. Então, quando eu vi que com esta carga ele congela e
apenas do docker (o sistema tem muitas memórias livres, io, cpu), pensei que
não é um problema comum.
Eu descobri que alguém envia solicitações para meu docker em logs
(/var/log/upstart/docker.logs). E eu descobri quem era :)
O que dizer mais?

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

@ohade não, não faz parte do docker. Minha opinião é que não é um problema docker. Você deve procurar em seu ambiente solicitações pesadas ao docker.

Também estou tendo esse problema desde que atualizei para o docker 1.8.2

Algum progresso nisso? Em nossa infraestrutura de teste, estou gerando um grande número ou contêineres de curta duração e estou enfrentando esse problema mais de uma vez por dia.

docker version
Client:
 Version:      1.8.2
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   0a8c2e3
 Built:        Thu Sep 10 19:12:52 UTC 2015
 OS/Arch:      linux/amd64
Server:
 Version:      1.8.2
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   0a8c2e3
 Built:        Thu Sep 10 19:12:52 UTC 2015
 OS/Arch:      linux/amd64

Versão Linux:

$ uname -a
Linux grpc-interop1 3.16.0-0.bpo.4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u3~bpo70+1 (2015-08-08) x86_64 GNU/Linux

Mudamos para 1.8.3:

# docker version 
Client:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   f4bf5c7
 Built:        Mon Oct 12 06:06:01 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   f4bf5c7
 Built:        Mon Oct 12 06:06:01 UTC 2015
 OS/Arch:      linux/amd64

mas mesmo assim continuou a falhar, primeiro uma vez em alguns dias e, posteriormente, até dez vezes por dia. A migração do CentOS 7 com mapeador de dispositivos / loopback para o Ubuntu 14.04 LTS com AUFS classificou isso.

Também vi este problema https://github.com/docker/docker/issues/12606#issuecomment -149659953

Posso reproduzir o problema de maneira confiável executando os testes e2e deste kubernetes em um loop.

Eu peguei o log de rastreamento do daemon, parece que há um impasse, muitos goroutines estão pendurados em semacquire

goroutine 8956 [semacquire, 8 minutes]:
sync.(*Mutex).Lock(0xc208961650)
/usr/lib/go/src/sync/mutex.go:66 +0xd3
github.com/docker/docker/daemon.func·028(0xc20861c1e0, 0x0, 0x0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/daemon/list.go:84 +0xfc
github.com/docker/docker/daemon.(*Daemon).Containers(0xc2080a50a0, 0xc209ec4820, 0x0, 0x0, 0x0, 0x0, 0x0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/daemon/list.go:187 +0x917
github.com/docker/docker/api/server.(*Server).getContainersJSON(0xc208032540, 0xc3f700, 0x4, 0x7f214584f110, 0xc20a306d20, 0xc209d4a9c0, 0xc20a09fa10, 0x0, 0x0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/api/server/server.go:562 +0x3ba
github.com/docker/docker/api/server.*Server.(github.com/docker/docker/api/server.getContainersJSON)·fm(0xc3f700, 0x4, 0x7f214584f110, 0xc20a306d20, 0xc209d4a9c0, 0xc20a09fa10, 0x0, 0x0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/api/server/server.go:1526 +0x7b
github.com/docker/docker/api/server.func·008(0x7f214584f110, 0xc20a306d20, 0xc209d4a9c0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/api/server/server.go:1501 +0xacd
net/http.HandlerFunc.ServeHTTP(0xc208033380, 0x7f214584f110, 0xc20a306d20, 0xc209d4a9c0)
/usr/lib/go/src/net/http/server.go:1265 +0x41
github.com/gorilla/mux.(*Router).ServeHTTP(0xc2080b1090, 0x7f214584f110, 0xc20a306d20, 0xc209d4a9c0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/vendor/src/github.com/gorilla/mux/mux.go:98 +0x297
net/http.serverHandler.ServeHTTP(0xc20804f080, 0x7f214584f110, 0xc20a306d20, 0xc209d4a9c0)
/usr/lib/go/src/net/http/server.go:1703 +0x19a
net/http.(*conn).serve(0xc208743680)
/usr/lib/go/src/net/http/server.go:1204 +0xb57
created by net/http.(*Server).Serve
/usr/lib/go/src/net/http/server.go:1751 +0x35e

Rastreamento completo aqui:
https://gist.github.com/yifan-gu/ac0cbc2a59a7b8c3fe2d

Tentaremos testar na versão mais recente

Tentei outra corrida, ainda com 1.7.1, mas desta vez encontrei algo mais interessante:

goroutine 114 [syscall, 50 minutes]:
syscall.Syscall6(0x3d, 0x514, 0xc2084e74fc, 0x0, 0xc208499950, 0x0, 0x0, 0x44199c, 0x441e22, 0xb28140)
/usr/lib/go/src/syscall/asm_linux_amd64.s:46 +0x5
syscall.wait4(0x514, 0xc2084e74fc, 0x0, 0xc208499950, 0x90, 0x0, 0x0)
/usr/lib/go/src/syscall/zsyscall_linux_amd64.go:124 +0x79
syscall.Wait4(0x514, 0xc2084e7544, 0x0, 0xc208499950, 0x41a768, 0x0, 0x0)
/usr/lib/go/src/syscall/syscall_linux.go:224 +0x60
os.(*Process).wait(0xc2083e2b20, 0xc20848a860, 0x0, 0x0)
/usr/lib/go/src/os/exec_unix.go:22 +0x103
os.(*Process).Wait(0xc2083e2b20, 0xc2084e7608, 0x0, 0x0)
/usr/lib/go/src/os/doc.go:45 +0x3a
os/exec.(*Cmd).Wait(0xc2083c9a40, 0x0, 0x0)
/usr/lib/go/src/os/exec/exec.go:364 +0x23c
github.com/docker/libcontainer.(*initProcess).wait(0xc20822cf30, 0x1b6, 0x0, 0x0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/vendor/src/github.com/docker/libcontainer/process_linux.go:194 +0x3d
github.com/docker/libcontainer.Process.Wait(0xc208374a30, 0x1, 0x1, 0xc20839b000, 0x47, 0x80, 0x127e348, 0x0, 0x127e348, 0x0, ...)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/vendor/src/github.com/docker/libcontainer/process.go:60 +0x11d
github.com/docker/libcontainer.Process.Wait·fm(0xc2084e7ac8, 0x0, 0x0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/daemon/execdriver/native/driver.go:164 +0x58
github.com/docker/docker/daemon/execdriver/native.(*driver).Run(0xc20813c230, 0xc20832a900, 0xc20822cc00, 0xc208374900, 0x0, 0x41a900, 0x0, 0x0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/daemon/execdriver/native/driver.go:170 +0xa0a
github.com/docker/docker/daemon.(*Daemon).Run(0xc2080a5880, 0xc2080a21e0, 0xc20822cc00, 0xc208374900, 0x0, 0xc2084b6000, 0x0, 0x0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/daemon/daemon.go:1068 +0x95
github.com/docker/docker/daemon.(*containerMonitor).Start(0xc20853d180, 0x0, 0x0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/daemon/monitor.go:138 +0x457
github.com/docker/docker/daemon.*containerMonitor.Start·fm(0x0, 0x0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/daemon/container.go:732 +0x39
github.com/docker/docker/pkg/promise.func·001()
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/pkg/promise/promise.go:8 +0x2f
created by github.com/docker/docker/pkg/promise.Go
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/pkg/promise/promise.go:9 +0xfb

Eu vi um monte de goroutines pendurados aqui. Se Container.Start() travar, o bloqueio do contêiner não será liberado e todos os docker ps seguintes travarão. (parece que isso também é verdade para o v.1.9.0-rc1)

Embora eu não saiba por que Container.Start() trava, e se esta é a única causa para docker ps travar.

https://github.com/docker/docker/blob/v1.9.0-rc1/daemon/container.go#L243
https://github.com/docker/docker/blob/v1.9.0-rc1/daemon/container.go#L304
https://github.com/docker/docker/blob/v1.9.0-rc1/daemon/list.go#L113

Acho que devemos tentar não manter um mutex antes de tais syscalls de qualquer maneira ...

Esse é um grande problema para mim. Alguém do Docker está investigando isso?

ping @ LK4D4 @tiborvass ^^ https://github.com/docker/docker/issues/13885#issuecomment -149767470

Temos o problema semelhante no docker 1.8.2, suspeito que haja uma rotina go ou outros vazamentos acontecendo no daemon.

Quando colocado sob estresse de criação / exclusão rápida, docker ps demoraria uma eternidade para terminar e, eventualmente, o daemon do docker perderia o repouso.

Estou tendo problemas semelhantes com 1.8.2. Tentei 1.9 rc2 e tive problemas semelhantes, muitos travamentos e reiniciando o daemon do docker, que às vezes corrigia coisas e na maioria das vezes não.

Eu ficaria curioso para saber quando algo trava, quanto tempo dura antes de ser morto?
Ele sempre volta se você apenas deixá-lo esperar?

Embora eu não tenha cronometrado, eu diria que foram pelo menos mais de vinte minutos. Comecei a usar docker-compose kill vs. stop e parece melhor, mas o tempo dirá. Também não vejo nada óbvio nos registros.

Também vemos isso no centos 7.1, docker 1.8.2. Meu instinto me diz que é um problema de mapeamento de dados / loopback.

O próximo passo em nossa lista é tentar isso: https://github.com/projectatomic/docker-storage-setup (h / t @ibuildthecloud )

Também experimentando isso e não está sob carga pesada.

Centos 7

Versão Docker

Client:
 Version:      1.8.2
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   0a8c2e3
 Built:        Thu Sep 10 19:08:45 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.2
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   0a8c2e3
 Built:        Thu Sep 10 19:08:45 UTC 2015
 OS/Arch:      linux/amd64

Informações do Docker

Containers: 4
Images: 40
Storage Driver: devicemapper
 Pool Name: docker-202:1-25190844-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: xfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 2.914 GB
 Data Space Total: 107.4 GB
 Data Space Available: 81.05 GB
 Metadata Space Used: 4.03 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.143 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.93-RHEL7 (2015-01-28)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.10.0-123.8.1.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 4
Total Memory: 6.898 GiB
Name: ip-10-50-185-203
ID: EOMR:4G7Y:7H6O:QOXE:WW4Z:3R2G:HLI4:ZMXY:GKF3:YKSK:TIHC:MHZF
[centos@ip-10-50-185-203 ~]$ uname -a
Linux ip-10-50-185-203 3.10.0-123.8.1.el7.x86_64 #1 SMP Mon Sep 22 19:06:58 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

as imagens do docker funcionam, mas o docker ps trava.

Últimas linhas de saída do strace:

clock_gettime(CLOCK_MONOTONIC, {2393432, 541406232}) = 0
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
socket(PF_LOCAL, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
setsockopt(3, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
connect(3, {sa_family=AF_LOCAL, sun_path="/run/systemd/journal/socket"}, 30) = 0
epoll_create1(EPOLL_CLOEXEC)            = 4
epoll_ctl(4, EPOLL_CTL_ADD, 3, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=2856433208, u64=139812631852600}}) = 0
getsockname(3, {sa_family=AF_LOCAL, NULL}, [2]) = 0
getpeername(3, {sa_family=AF_LOCAL, sun_path="/run/systemd/journal/socket"}, [30]) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 542834304}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 542897330}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 543010460}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 543090332}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 543157219}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 543208557}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 543306537}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 543364486}) = 0
clock_gettime(CLOCK_REALTIME, {1446718224, 108316907}) = 0
mmap(0xc208100000, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xc208100000
mmap(0xc207fe0000, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xc207fe0000
clock_gettime(CLOCK_MONOTONIC, {2393432, 543814528}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 543864338}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 543956865}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 544018495}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 544402150}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 544559595}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 544607443}) = 0
clock_gettime(CLOCK_REALTIME, {1446718224, 109474379}) = 0
epoll_wait(4, {{EPOLLOUT, {u32=2856433208, u64=139812631852600}}}, 128, 0) = 1
clock_gettime(CLOCK_MONOTONIC, {2393432, 544968692}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 545036728}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 545095771}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 545147947}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 545199057}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 545251039}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 545308858}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 545756723}) = 0
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
clock_gettime(CLOCK_REALTIME, {1446718224, 112187655}) = 0
clock_gettime(CLOCK_REALTIME, {1446718224, 112265169}) = 0
clock_gettime(CLOCK_REALTIME, {1446718224, 112345304}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 547677486}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 547743669}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 547801800}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 547864215}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 547934364}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 548042167}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 548133574}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 548209405}) = 0
clock_gettime(CLOCK_REALTIME, {1446718224, 113124453}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 548493023}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 548566472}) = 0
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
clock_gettime(CLOCK_MONOTONIC, {2393432, 549410983}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 549531015}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 549644468}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 549713961}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 549800266}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 549864335}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
stat("/root/.docker/config.json", 0xc208052900) = -1 ENOENT (No such file or directory)
stat("/root/.dockercfg", 0xc208052990)  = -1 ENOENT (No such file or directory)
clock_gettime(CLOCK_REALTIME, {1446718224, 115099477}) = 0
clock_gettime(CLOCK_REALTIME, {1446718224, 115153125}) = 0
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 5
setsockopt(5, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
connect(5, {sa_family=AF_LOCAL, sun_path="/var/run/docker.sock"}, 23) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 550603891}) = 0
clock_gettime(CLOCK_REALTIME, {1446718224, 115517051}) = 0
epoll_ctl(4, EPOLL_CTL_ADD, 5, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=2856433016, u64=139812631852408}}) = 0
getsockname(5, {sa_family=AF_LOCAL, NULL}, [2]) = 0
getpeername(5, {sa_family=AF_LOCAL, sun_path="/var/run/docker.sock"}, [23]) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 550961223}) = 0
read(5, 0xc208131000, 4096)             = -1 EAGAIN (Resource temporarily unavailable)
clock_gettime(CLOCK_MONOTONIC, {2393432, 551138398}) = 0
write(5, "GET /v1.20/containers/json HTTP/"..., 108) = 108
epoll_wait(4, {{EPOLLOUT, {u32=2856433016, u64=139812631852408}}}, 128, 0) = 1
epoll_wait(4, 

@chbatey você pode editar seu comentário e adicionar o resultado de docker version ?

Quanto a mim e ao meu, pinte meu rosto de vermelho. Eu executei o daemon no debug e descobri um volume compartilhado que estava pendurado em uma montagem cifs. Uma vez que cuidei disso, as coisas estão funcionando bem para mim agora.

@pspierce sem problemas, obrigado por nos reportar!

Estou interessado em saber se isso ainda é um problema no 1.9 para alguém aqui

também estamos vendo isso com 1.8.2 em centos 7.1 com bastante frequência, mas apenas em nossos hosts de alta rotatividade (~ 2.100 contêineres / hora). Não parece afetar nossos hosts configurados de forma idêntica, mas com menor volume (~ 300 contêineres / hora), então parece ser algum tipo de impasse acionado por muitas operações simultâneas? Vemos isso ~ / 6 horas de atividade de alta rotatividade, e até agora a única solução que encontramos é executar o daemon

vamos dar uma chance ao 1.9 na próxima semana e ver se ajuda em alguma coisa (dedos cruzados!); fwiw, não encontramos essa degradação gradual da capacidade de resposta (e eventual impasse) em 1.6.2.

aqui estão os detalhes sobre nossa configuração atual:

PRODUCTION [[email protected] ~]$ docker -D info
Containers: 8
Images: 41
Storage Driver: overlay
 Backing Filesystem: xfs
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.3.0-1.el7.elrepo.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 4
Total Memory: 7.796 GiB
Name: cc-docker01.prod.iad01.treehouse
ID: AB4S:SO4Z:AEOS:MC3H:XPRV:SIH4:VE2N:ELYX:TA5S:QQWP:WDAP:DUKE
Username: xxxxxxxxxxxxxx
Registry: https://index.docker.io/v1/
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled

PRODUCTION [[email protected] ~]$ docker -D version
Client:
 Version:      1.8.2
 API version:  1.20
 Package Version: docker-1.8.2-7.el7.centos.x86_64
 Go version:   go1.4.2
 Git commit:   bb472f0/1.8.2
 Built:        
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.2
 API version:  1.20
 Package Version: 
 Go version:   go1.4.2
 Git commit:   bb472f0/1.8.2
 Built:        
 OS/Arch:      linux/amd64

Também vejo isso no ubuntu 14.04, apenas 8 contêineres em execução, mas alta carga de disco e CPU. Os contêineres são reiniciados à medida que são concluídos, então sempre há 8 em execução. O daemon está morrendo depois de algumas centenas a alguns milhares de execuções cumulativas do contêiner. Não vi o daemon travar quando estava executando o loopback, mas isso aconteceu duas vezes nos últimos dias usando o thinpool. Isso está em uma estação de trabalho de 40 núcleos com 64 GB de RAM.

Versão Docker:
versão ~ $ docker
Cliente:
Versão: 1.9.1
Versão API: 1.21
Versão Go: go1.4.2
Git commit: a34a1d5
Construído: Sex. 20 de novembro, 13:12:04 UTC de 2015
OS / Arch: linux / amd64

Servidor:
Versão: 1.9.1
Versão API: 1.21
Versão Go: go1.4.2
Git commit: a34a1d5
Construído: Sex. 20 de novembro, 13:12:04 UTC de 2015
OS / Arch: linux / amd64

--- A imagem do Docker funciona, mas o docker ps trava. Docker info também trava. Este é o final do strace para docker ps:
soquete (PF_LOCAL, SOCK_STREAM | SOCK_CLOEXEC | SOCK_NONBLOCK, 0) = 3
setsockopt (3, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
conectar (3, {sa_family = AF_LOCAL, sun_path = "/ var / run / docker.sock"}, 23) = 0
epoll_create1 (EPOLL_CLOEXEC) = 4
epoll_ctl (4, EPOLL_CTL_ADD, 3, {EPOLLIN | EPOLLOUT | EPOLLRDHUP | EPOLLET, {u32 = 3565442144, u64 = 140517715498080}}) = 0
getockname (3, {sa_family = AF_LOCAL, NULL}, [2]) = 0
getpeername (3, {sa_family = AF_LOCAL, sun_path = "/ var / run / docker.sock"}, [23]) = 0
ler (3, 0xc208506000, 4096) = -1 EAGAIN (Recurso temporariamente indisponível)
write (3, "GET /v1.21/containers/json HTTP /" ..., 108) = 108
epoll_wait (4, {{EPOLLOUT, {u32 = 3565442144, u64 = 140517715498080}}}, 128, 0) = 1
epoll_wait (4,

Tínhamos isso em 1.7.1 e trabalhamos em torno dele de forma muito eficaz (vimos isso a cada poucas horas em 1.7.1, mas nunca por mais de 1 mês após a solução alternativa):

udevadm control --timeout=300

Estamos executando o RHEL7.1. Acabamos de fazer uma atualização para o Docker 1.8.2 sem nenhuma outra alteração e nosso aplicativo o bloqueou em algumas horas. Strace:

``
[pid 4200] open ("/ sys / fs / cgroup / freezer / system.slice / docker-bcb29dad6848d250df7508f85e78ca9b83d40f0e22011869d89a176e27b7ef87.scope / freezer.state", O_RDONLY = 36_CLOECLY)
[pid 4200] fstat (36, {st_mode = S_IFREG | 0644, st_size = 0, ...}) = 0
[pid 4239] <... selecionar retomado>) = 0 (tempo limite)
[pid 4200] lido (36, [pid 4239] selecione (0, NULL, NULL, NULL, {0, 20} [pid 4200] <... ler resumido> "FREEZINGn", 512) = 9
[pid 4200] lido (36, "", 1527) = 0
[pid 4200] fechar (36) = 0
[pid 4200] futex (0x1778e78, FUTEX_WAKE, 1 [pid 4239] <... selecionar retomado>) = 0 (tempo limite)
[pid 5252] <... futex retomado>) = 0
[pid 4200] <... futex resumido>) = 1
[pid 5252] futex (0xc2085daed8, FUTEX_WAIT, 0, NULL [pid 4239] selecione (0, NULL, NULL, NULL, {0, 20} [pid 4200] futex (0xc2085daed8, FUTEX_WAKE, 1 [pid 5252] <... futex resumido>) = -1 EAGAIN (Recurso temporariamente indisponível)
[pid 4200] <... futex resumido>) = 0
[pid 5252] epoll_wait (4, [pid 4200] futex (0x1778e78, FUTEX_WAIT, 0, {0, 958625} [pid 5252] <... epoll_wait resumed> {}, 128, 0) = 0
[pid 5252] futex (0xc2085daed8, FUTEX_WAIT, 0, NULL [pid 4239] <... selecionar retomado>) = 0 (tempo limite)

Estamos enfrentando o mesmo problema https://github.com/giantswarm/giantswarm/issues/289

ATUALIZAÇÃO: Parece que minha hipótese sobre docker run intercalados docker rm era incorreta. Tentei fazer apenas muitos docker run s simultâneos e isso foi suficiente para acionar o comportamento. Eu também tentei mudar para um thinpool dm, mas isso também não ajudou. Minha solução alternativa foi simplesmente garantir que vários contêineres nunca sejam iniciados "ao mesmo" tempo, ou seja, adicionei intervalos de pelo menos 10 a 30 segundos entre as partidas. Agora o daemon está rodando sem problemas por mais de 2 semanas. Fim da atualização.

Só para adicionar mais uma confirmação, estamos vendo isso no 1.9.0. Não estamos nem gerando muito, no máximo 8 contêineres (1 por núcleo) por vez, e não mais do que ~ 40 por hora. Uma coisa comum com o relatório original é que também acabamos fazendo algumas invocações intercaladas de docker run e docker rm -f . Minha intuição é que é a combinação de muitas criações e exclusões simultâneas de contêineres que aciona o impasse.

$ docker version
Client:
 Version:      1.9.0
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   76d6bc9
 Built:        Tue Nov  3 18:00:05 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.9.0
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   76d6bc9
 Built:        Tue Nov  3 18:00:05 UTC 2015
 OS/Arch:      linux/amd64

$ docker -D info
Containers: 10
Images: 119
Server Version: 1.9.0
Storage Driver: devicemapper
 Pool Name: docker-253:1-2114818-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 107.4 GB
 Backing Filesystem: xfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 7.234 GB
 Data Space Total: 107.4 GB
 Data Space Available: 42.64 GB
 Metadata Space Used: 10.82 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.137 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
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.93-RHEL7 (2015-01-28)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.10.0-229.20.1.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 8
Total Memory: 15.51 GiB

@mjsalinger Temos o mesmo problema que você, com a mesma configuração, você resolveu o problema?

Mesmo problema aqui

~ # docker info
Containers: 118
Images: 2239
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.2.2-coreos-r1
Operating System: CoreOS 835.8.0
CPUs: 16
Total Memory: 29.44 GiB
Username: util-user
Registry: https://index.docker.io/v1/
Client:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   cedd534-dirty
 Built:        Tue Dec  1 02:00:58 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   cedd534-dirty
 Built:        Tue Dec  1 02:00:58 UTC 2015
 OS/Arch:      linux/amd64

Nossos registros estão cheios de coisas como:

time="2016-01-08T21:38:34.735146159Z" level=error msg="Failed to compute size of container rootfs e4565ff148266389cbf70af9f22f9c62aa255bacaec0925a72eab5d0dca9da5f: Error getting container e4565ff148266389cbf70af9f22f9c62aa255bacaec0925a72eab5d0dca9da5f from driver overlay: stat /var/lib/docker/overlay/e4565ff148266389cbf70af9f22f9c62aa255bacaec0925a72eab5d0dca9da5f: no such file or directory"

e

time="2016-01-08T21:42:34.846701169Z" level=error msg="Handler for GET /containers/json returned error: write unix @: broken pipe"
time="2016-01-08T21:42:34.846717812Z" level=error msg="HTTP Error" err="write unix @: broken pipe" statusCode=500

Mas não tenho certeza se alguma dessas coisas tem a ver com o problema do enforcamento.

Incluir despejo de todas as pilhas de goroutines do docker enviando SIGUSR1 para um daemon pode ser útil

@whosthatknocking nem sabia que eu poderia fazer isso, legal.

time="2016-01-08T22:20:16.181468178Z" level=info msg="=== BEGIN goroutine stack dump ===
goroutine 11 [running]:
github.com/docker/docker/pkg/signal.DumpStacks()
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/pkg/signal/trap.go:60 +0x7a
github.com/docker/docker/daemon.func·025()
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/debugtrap_unix.go:18 +0x6d
created by github.com/docker/docker/daemon.setupDumpStackTrap
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/debugtrap_unix.go:20 +0x18e

goroutine 1 [chan receive, 33262 minutes]:
main.(*DaemonCli).CmdDaemon(0xc20807d1a0, 0xc20800a020, 0x1, 0x1, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/docker/daemon.go:289 +0x1781
reflect.callMethod(0xc208142060, 0xc20842fce0)
    /usr/lib/go/src/reflect/value.go:605 +0x179
reflect.methodValueCall(0xc20800a020, 0x1, 0x1, 0x1, 0xc208142060, 0x0, 0x0, 0xc208142060, 0x0, 0x452ecf, ...)
    /usr/lib/go/src/reflect/asm_amd64.s:29 +0x36
github.com/docker/docker/cli.(*Cli).Run(0xc20810df80, 0xc20800a010, 0x2, 0x2, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/cli/cli.go:89 +0x38e
main.main()
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/docker/docker.go:69 +0x428

goroutine 5 [syscall]:
os/signal.loop()
    /usr/lib/go/src/os/signal/signal_unix.go:21 +0x1f
created by os/signal.init·1
    /usr/lib/go/src/os/signal/signal_unix.go:27 +0x35

goroutine 17 [syscall, 33262 minutes, locked to thread]:
runtime.goexit()
    /usr/lib/go/src/runtime/asm_amd64.s:2232 +0x1

goroutine 13 [IO wait, 33262 minutes]:
net.(*pollDesc).Wait(0xc2081eb100, 0x72, 0x0, 0x0)
    /usr/lib/go/src/net/fd_poll_runtime.go:84 +0x47
net.(*pollDesc).WaitRead(0xc2081eb1
00, 0x0, 0x0)
    /usr/lib/go/src/net/fd_poll_runtime.go:89 +0x43
net.(*netFD).readMsg(0xc2081eb0a0, 0xc2081bd9a0, 0x10, 0x10, 0xc208440020, 0x1000, 0x1000, 0xffffffffffffffff, 0x0, 0x0, ...)
    /usr/lib/go/src/net/fd_unix.go:296 +0x54e
net.(*UnixConn).ReadMsgUnix(0xc2080384b8, 0xc2081bd9a0, 0x10, 0x10, 0xc208440020, 0x1000, 0x1000, 0x51, 0xc2081bd6d4, 0x4, ...)
    /usr/lib/go/src/net/unixsock_posix.go:147 +0x167
github.com/godbus/dbus.(*oobReader).Read(0xc208440000, 0xc2081bd9a0, 0x10, 0x10, 0xc208440000, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/transport_unix.go:21 +0xc5
io.ReadAtLeast(0x7f9ad52e9310, 0xc208440000, 0xc2081bd9a0, 0x10, 0x10, 0x10, 0x0, 0x0, 0x0)
    /usr/lib/go/src/io/io.go:298 +0xf1
io.ReadFull(0x7f9ad52e9310, 0xc208440000, 0xc2081bd9a0, 0x10, 0x10, 0x51, 0x0, 0x0)
    /usr/lib/go/src/io/io.go:316 +0x6d
github.com/godbus/dbus.(*unixTransport).ReadMessage(0xc2081df900, 0xc208115170, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/transport_unix.go:85 +0x1bf
github.com/godbus/dbus.(*Conn).inWorker(0xc208418480)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/conn.go:248 +0x58
created by github.com/godbus/dbus.(*Conn).Auth
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/auth.go:118 +0xe84

goroutine 10 [chan receive, 33262 minutes]:
github.com/docker/docker/api/server.(*Server).ServeApi(0xc208037800, 0xc20807d3d0, 0x1, 0x1, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/api/server/server.go:111 +0x74f
main.func·007()
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/docker/daemon.go:239 +0x5b
created by main.(*DaemonCli).CmdDaemon
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-
1.8.3/work/docker-1.8.3/docker/daemon.go:245 +0xce9

goroutine 14 [chan receive, 33262 minutes]:
github.com/godbus/dbus.(*Conn).outWorker(0xc208418480)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/conn.go:370 +0x58
created by github.com/godbus/dbus.(*Conn).Auth
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/auth.go:119 +0xea1

goroutine 15 [chan receive, 33262 minutes]:
github.com/docker/libnetwork/iptables.signalHandler()
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/docker/libnetwork/iptables/firewalld.go:92 +0x57
created by github.com/docker/libnetwork/iptables.FirewalldInit
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/docker/libnetwork/iptables/firewalld.go:48 +0x185

goroutine 50 [chan receive, 33262 minutes]:
database/sql.(*DB).connectionOpener(0xc2081aa0a0)
    /usr/lib/go/src/database/sql/sql.go:589 +0x4c
created by database/sql.Open
    /usr/lib/go/src/database/sql/sql.go:452 +0x31c

goroutine 51 [IO wait]:
net.(*pollDesc).Wait(0xc2081dcd10, 0x72, 0x0, 0x0)
    /usr/lib/go/src/net/fd_poll_runtime.go:84 +0x47
net.(*pollDesc).WaitRead(0xc2081dcd10, 0x0, 0x0)
    /usr/lib/go/src/net/fd_poll_runtime.go:89 +0x43
net.(*netFD).readMsg(0xc2081dccb0, 0xc20b38c970, 0x10, 0x10, 0xc20bf3b220, 0x1000, 0x1000, 0xffffffffffffffff, 0x0, 0x0, ...)
    /usr/lib/go/src/net/fd_unix.go:296 +0x54e
net.(*UnixConn).ReadMsgUnix(0xc208038618, 0xc20b38c970, 0x10, 0x10, 0xc20bf3b220, 0x1000, 0x1000, 0x35, 0xc20b38c784, 0x4, ...)
    /usr/lib/go/src/net/unixsock_posix.go:147 +0x167
github.com/godbus/dbus.(*oobReader).Read(0xc20bf3b200, 0xc20b38c970, 0x10, 0x10, 0xc20bf3b200, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/transport_unix.go:21 +0xc5
io.ReadAtLeast(0x7f9ad52e9310, 0xc20bf3b200, 0x
c20b38c970, 0x10, 0x10, 0x10, 0x0, 0x0, 0x0)
    /usr/lib/go/src/io/io.go:298 +0xf1
io.ReadFull(0x7f9ad52e9310, 0xc20bf3b200, 0xc20b38c970, 0x10, 0x10, 0x35, 0x0, 0x0)
    /usr/lib/go/src/io/io.go:316 +0x6d
github.com/godbus/dbus.(*unixTransport).ReadMessage(0xc208176950, 0xc208471470, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/transport_unix.go:85 +0x1bf
github.com/godbus/dbus.(*Conn).inWorker(0xc2080b0fc0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/conn.go:248 +0x58
created by github.com/godbus/dbus.(*Conn).Auth
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/auth.go:118 +0xe84

goroutine 52 [chan receive]:
github.com/godbus/dbus.(*Conn).outWorker(0xc2080b0fc0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/conn.go:370 +0x58
created by github.com/godbus/dbus.(*Conn).Auth
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/auth.go:119 +0xea1

goroutine 53 [chan receive]:
github.com/coreos/go-systemd/dbus.func·001()
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/coreos/go-systemd/dbus/subscription.go:70 +0x64
created by github.com/coreos/go-systemd/dbus.(*Conn).initDispatch
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/coreos/go-systemd/dbus/subscription.go:94 +0x11c

goroutine 54 [chan receive]:
github.com/docker/docker/daemon.(*statsCollector).run(0xc20844dad0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/stats_collector_unix.go:91 +0xb2
created by github.com/docker/docker/daemon.newStatsCollector
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/wo
rk/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/stats_collector_unix.go:31 +0x116

goroutine 55 [chan receive, 2 minutes]:
github.com/docker/docker/daemon.(*Daemon).execCommandGC(0xc2080908c0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/exec.go:256 +0x8c
created by github.com/docker/docker/daemon.NewDaemon
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/daemon.go:736 +0x2358

goroutine 774 [semacquire, 33261 minutes]:
sync.(*Cond).Wait(0xc208460030)
    /usr/lib/go/src/sync/cond.go:62 +0x9e
io.(*pipe).read(0xc208460000, 0xc208c0bc00, 0x400, 0x400, 0x0, 0x0, 0x0)
    /usr/lib/go/src/io/pipe.go:52 +0x303
io.(*PipeReader).Read(0xc208b52750, 0xc208c0bc00, 0x400, 0x400, 0x1f, 0x0, 0x0)
    /usr/lib/go/src/io/pipe.go:134 +0x5b
github.com/docker/docker/pkg/ioutils.(*bufReader).drain(0xc2084600c0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/pkg/ioutils/readers.go:116 +0x10e
created by github.com/docker/docker/pkg/ioutils.NewBufReader
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/pkg/ioutils/readers.go:86 +0x2f3

goroutine 784 [semacquire, 33261 minutes]:
sync.(*Cond).Wait(0xc208460570)
    /usr/lib/go/src/sync/cond.go:62 +0x9e
io.(*pipe).read(0xc208460540, 0xc208963000, 0x400, 0x400, 0x0, 0x0, 0x0)
    /usr/lib/go/src/io/pipe.go:52 +0x303
io.(*PipeReader).Read(0xc208b529d8, 0xc208963000, 0x400, 0x400, 0x1f, 0x0, 0x0)
    /usr/lib/go/src/io/pipe.go:134 +0x5b
github.com/docker/docker/pkg/ioutils.(*bufReader).drain(0xc208460600)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/pkg/ioutils/readers.go:116 +0x10e
created by github.com/docker/docker/pkg/ioutils.NewBufReader
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/wo
rk/docker-1.8.3/.gopath/src/github.com/docker/docker/pkg/ioutils/readers.go:86 +0x2f3

goroutine 757 [semacquire, 33261 minutes]:
sync.(*Cond).Wait(0xc208141cb0)
    /usr/lib/go/src/sync/cond.go:62 +0x9e
github.com/docker/docker/pkg/ioutils.(*bufReader).Read(0xc208141c80, 0xc2089f2000, 0x1000, 0x1000, 0x0, 0x7f9ad52d4080, 0xc20802a0d0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/pkg/ioutils/readers.go:210 +0x158
bufio.(*Reader).fill(0xc208956ae0)
    /usr/lib/go/src/bufio/bufio.go:97 +0x1ce
bufio.(*Reader).ReadSlice(0xc208956ae0, 0x41d50a, 0x0, 0x0, 0x0, 0x0, 0x0)
    /usr/lib/go/src/bufio/bufio.go:295 +0x257
bufio.(*Reader).ReadBytes(0xc208956ae0, 0xc208141c0a, 0x0, 0x0, 0x0, 0x0, 0x0)
    /usr/lib/go/src/bufio/bufio.go:374 +0xd2
github.com/docker/docker/daemon/logger.(*Copier).copySrc(0xc2084def40, 0xf8ac00, 0x6, 0x7f9ad003e420, 0xc208141c80)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/logger/copier.go:47 +0x96
created by github.com/docker/docker/daemon/logger.(*Copier).Run
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/logger/copier.go:38 +0x11c

goroutine 842 [chan receive, 33261 minutes]:
github.com/docker/docker/daemon.(*Container).AttachWithLogs(0xc208cc90e0, 0x0, 0x0, 0x7f9ad003e398, 0xc208471e30, 0x7f9ad003e398, 0xc208471e00, 0x100, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/container.go:934 +0x40d
github.com/docker/docker/daemon.(*Daemon).ContainerAttachWithLogs(0xc2080908c0, 0xc208cc90e0, 0xc208471dd0, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/attach.go:39 +0x42c
github.com/docker/docker/api/server.(*Server).postContainersAttach(0xc208037800, 0xc208b36007, 0x4, 0x7f9ad52f2870, 0xc20
87fde00, 0xc2087d4410, 0xc208471b90, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/api/server/server.go:1169 +0x5d1
github.com/docker/docker/api/server.*Server.(github.com/docker/docker/api/server.postContainersAttach)·fm(0xc208b36007, 0x4, 0x7f9ad52f2870, 0xc2087fde00, 0xc2087d4410, 0xc208471b90, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/api/server/server.go:1671 +0x7b
github.com/docker/docker/api/server.func·008(0x7f9ad52f2870, 0xc2087fde00, 0xc2087d4410)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/api/server/server.go:1614 +0xc8f
net/http.HandlerFunc.ServeHTTP(0xc2081cc580, 0x7f9ad52f2870, 0xc2087fde00, 0xc2087d4410)
    /usr/lib/go/src/net/http/server.go:1265 +0x41
github.com/gorilla/mux.(*Router).ServeHTTP(0xc20813cd70, 0x7f9ad52f2870, 0xc2087fde00, 0xc2087d4410)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/gorilla/mux/mux.go:98 +0x297
net/http.serverHandler.ServeHTTP(0xc2082375c0, 0x7f9ad52f2870, 0xc2087fde00, 0xc2087d4410)
    /usr/lib/go/src/net/http/server.go:1703 +0x19a
net/http.(*conn).serve(0xc2087fdd60)
    /usr/lib/go/src/net/http/server.go:1204 +0xb57
created by net/http.(*Server).Serve
    /usr/lib/go/src/net/http/server.go:1751 +0x35e

goroutine 789 [semacquire, 33261 minutes]:
sync.(*WaitGroup).Wait(0xc20882de60)
    /usr/lib/go/src/sync/waitgroup.go:132 +0x169
github.com/docker/docker/daemon.func·017(0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/container.go:1035 +0x42
github.com/docker/docker/pkg/promise.func·001()
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/pkg/promise/promise.go:8 +0x2f
created by github.com/docker/docker/pkg
/promise.Go
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/pkg/promise/promise.go:9 +0xfb

goroutine 788 [semacquire, 33261 minutes]:
sync.(*Cond).Wait(0xc2084607b0)
    /usr/lib/go/src/sync/cond.go:62 +0x9e
github.com/docker/docker/pkg/ioutils.(*bufReader).Read(0xc208460780, 0xc208a70000, 0x8000, 0x8000, 0x0, 0x7f9ad52d4080, 0xc20802a0d0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/pkg/ioutils/readers.go:210 +0x158
io.Copy(0x7f9ad003e398, 0xc208845860, 0x7f9ad003e420, 0xc208460780, 0x0, 0x0, 0x0)
    /usr/lib/go/src/io/io.go:362 +0x1f6
github.com/docker/docker/daemon.func·016(0xf8abc0, 0x6, 0x7f9ad003e398, 0xc208845860, 0x7f9ad003e3f0, 0xc208460780)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/container.go:1021 +0x245
created by github.com/docker/docker/daemon.attach
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/container.go:1032 +0x597

goroutine 769 [IO wait, 33261 minutes]:
net.(*pollDesc).Wait(0xc20881de20, 0x72, 0x0, 0x0)
    /usr/lib/go/src/net/fd_poll_runtime.go:84 +0x47
net.(*pollDesc).WaitRead(0xc20881de20, 0x0, 0x0)
    /usr/lib/go/src/net/fd_poll_runtime.go:89 +0x43
net.(*netFD).Read(0xc20881ddc0, 0xc2088ac000, 0x1000, 0x1000, 0x0, 0x7f9ad52d8340, 0xc20880d758)
    /usr/lib/go/src/net/fd_unix.go:242 +0x40f
net.(*conn).Read(0xc208b52360, 0xc2088ac000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
    /usr/lib/go/src/net/net.go:121 +0xdc
net/http.(*liveSwitchReader).Read(0xc208792c28, 0xc2088ac000, 0x1000, 0x1000, 0x2, 0x0, 0x0)
    /usr/lib/go/src/net/http/server.go:214 +0xab
io.(*LimitedReader).Read(0xc20889f960, 0xc2088ac000, 0x1000, 0x1000, 0x2, 0x0, 0x0)
    /usr/lib/go/src/io/io.go:408 +0xce
bufio.(*Reader).fill(0xc2082544e0)
    /usr/lib/go/src/bufio/bufio.go:97 +0x1ce
bufio.(*Reader).ReadSlice(0xc208254
4e0, 0xc20889db0a, 0x0, 0x0, 0x0, 0x0, 0x0)
    /usr/lib/go/src/bufio/bufio.go:295 +0x257
bufio.(*Reader).ReadLine(0xc2082544e0, 0x0, 0x0, 0x0, 0xc208bc2700, 0x0, 0x0)
    /usr/lib/go/src/bufio/bufio.go:324 +0x62
net/textproto.(*Reader).readLineSlice(0xc208845560, 0x0, 0x0, 0x0, 0x0, 0x0)
    /usr/lib/go/src/net/textproto/reader.go:55 +0x9e
net/textproto.(*Reader).ReadLine(0xc208845560, 0x0, 0x0, 0x0, 0x0)
    /u
=== END goroutine stack dump ==="

Acabei de colocar as rotinas do hang, docker go anexadas

Também estou vendo isso repetidamente nos registros após uma travamento
kernel: unregister_netdevice: waiting for veth2fb10a9 to become free. Usage count = 1

@rwky possivelmente relacionado a https://github.com/docker/docker/issues/5618?

@thaJeztah possivelmente, entretanto # 5618 parece se aplicar apenas a lo e eth0, não à interface à qual o contêiner estava vinculado.

O mesmo problema acontecia quando uma carga pesada de jobs do Kubernetes era programada. docker ps nunca retorna. Na verdade, curl --unix-socket /var/run/docker.sock http:/containers/json trava. Tenho que reiniciar o daemon do docker para recuperar o problema. O que é pior é que leva alguns minutos para reiniciar o daemon do docker!

$ docker version
Client:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.3
 Git commit:   cedd534-dirty
 Built:        Thu Nov 19 23:12:57 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.3
 Git commit:   cedd534-dirty
 Built:        Thu Nov 19 23:12:57 UTC 2015
 OS/Arch:      linux/amd64

$ docker info
Containers: 57
Images: 100
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.2.2-coreos-r2
Operating System: CoreOS 870.2.0
CPUs: 32
Total Memory: 251.9 GiB
Name: CNPVG50853311
ID: TV5P:6OHQ:QTSN:IF6K:5LPX:TSHS:DEAW:TQSF:QTOT:45NO:JH2X:DMSE
Http Proxy: http://proxy.wdf.sap.corp:8080
Https Proxy: http://proxy.wdf.sap.corp:8080
No Proxy: hyper.cd,anywhere.cd

Vendo algo semelhante em meu ambiente, despejei as informações abaixo para ajudar em qualquer depuração. As estatísticas são de dois hosts rancheros4.2 físicos de alta especificação com cerca de 70 contêineres cada. Vemos o desempenho do docker degradar, não consegui rastrear o acionador, mas reiniciar o docker daemon resolve o problema.

Versão Docker

Client:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.3
 Git commit:   994543b
 Built:        Mon Nov 23 06:08:57 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.3
 Git commit:   994543b
 Built:        Mon Nov 23 06:08:57 UTC 2015
 OS/Arch:      linux/amd64

informação do docker

Containers: 35
Images: 1958
Server Version: 1.9.1
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.2.3-rancher
Operating System: RancherOS (containerized)
CPUs: 64
Total Memory: 251.9 GiB
Name: PTL-BCA-07
ID: Q5WF:7MOB:37YR:NRZR:P2FE:DVWV:W7XY:Z6OL:TAVC:4KCM:IUFU:LO4C

Stacktrace:
debug2.txt

+1 para nós também, definitivamente vendo mais frequentemente sob carga mais alta, rodando em centos 6

Versão Docker

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

Informações do Docker

Containers: 1
Images: 55
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.18.23-74.el6.x86_64
Operating System: <unknown>
CPUs: 40
Total Memory: 157.4 GiB
Name: lively-frost
ID: SXAC:IJ45:UY45:FIXS:7MWD:MZAE:XSE5:HV3Z:DU4Z:CYK6:LXPB:A65F

@ssalinas mesmo se isso for resolvido, não ajudaria em sua situação, visto que você está executando em uma distribuição que não suportamos mais (centos 6) e em um kernel personalizado (CentOS 6 vem com 2.6.x). Este problema não será resolvido para Docker 1.7, porque não apoiamos mudanças de porta

@ theJeztah , Obviamente, há algum problema que está causando bloqueio sob carga pesada. Você pode confirmar se alguém da equipe do Docker identificou esse problema e isso foi resolvido na versão 1.9?

Além disso, há alguma maneira de eu conseguir identificar se o Docker está travando e não criando mais instâncias? Se sim, posso automatizar pelo menos para reiniciar o daemon e continuar a operação.

Vemos o problema também com a seguinte configuração:

docker 1.8.3 e coreos 835.10

docker ps trava em altas taxas de rotatividade. Você pode acioná-lo 100% criando 200 ou mais contêineres o mais rápido possível (o Kubernetes faz isso).

O mesmo aqui
repro:

A_LOT=300 # whatever
for i in `seq 1 $A_LOT`; 
  do docker run --rm alpine sh -c "echo $i; sleep 30" & 
done
sleep 5   # give it some time to start spawning containers
docker ps # hangs

core@pph-01 ~ $ docker version
Client:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   cedd534-dirty
 Built:        Tue Feb  2 13:28:10 UTC 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   cedd534-dirty
 Built:        Tue Feb  2 13:28:10 UTC 2016
 OS/Arch:      linux/amd64

Containers: 291
Images: 14
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.2.2-coreos-r2
Operating System: CoreOS 835.12.0
CPUs: 2
Total Memory: 1.958 GiB
Name: pph-01
ID: P4FX:IMCD:KF5R:MG3Y:XECP:JPKO:IRWM:3MGK:IAIW:UG5S:6KCR:IK2J
Username: pmoust
Registry: https://index.docker.io/v1/

Para registro, tentei o script bash acima para tentar reproduzir o problema no meu laptop, mas nada de ruim aconteceu, estava tudo bem. Eu executo o Ubuntu 15.10:

$ docker version
Client:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   a34a1d5
 Built:        Fri Nov 20 13:20:08 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   a34a1d5
 Built:        Fri Nov 20 13:20:08 UTC 2015
 OS/Arch:      linux/amd64

$ docker info
Containers: 1294
Images: 1231
Server Version: 1.9.1
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 3823
 Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.2.0-27-generic
Operating System: Ubuntu 15.10
CPUs: 8
Total Memory: 5.809 GiB
Name: pochama
ID: 6VMD:Z57I:QDFF:TBSU:FNSH:Y433:6KDS:2AXU:CVMH:JUKU:TVQQ:7UMR
Username: tomfotherby
Registry: https://index.docker.io/v1/
WARNING: No swap limit support

Vimos vários casos desse problema no Docker 1.8.3 / CentOS 7. Estamos usando kubernetes, que pode criar um grande número de contêineres. Ocasionalmente, nosso daemon do docker deixa de responder (o docker ps trava por> 30 minutos) e apenas a reinicialização do daemon corrige o problema.

No entanto, não consigo reproduzir o problema usando o script de @pmoust .

Containers: 117
Images: 105
Storage Driver: devicemapper
 Pool Name: docker-docker--pool
 Pool Blocksize: 524.3 kB
 Backing Filesystem: xfs
 Data file: 
 Metadata file: 
 Data Space Used: 5.559 GB
 Data Space Total: 21.45 GB
 Data Space Available: 15.89 GB
 Metadata Space Used: 7.234 MB
 Metadata Space Total: 54.53 MB
 Metadata Space Available: 47.29 MB
 Udev Sync Supported: true
 Deferred Removal Enabled: true
 Library Version: 1.02.107-RHEL7 (2015-10-14)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.10.0-327.4.5.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 2
Total Memory: 3.451 GiB
Name: server
ID: MK35:YN3L:KULL:C4YU:IOWO:6OK2:FHLO:WIYE:CBVE:MZBL:KG3T:OV5T
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled

Client:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   f4bf5c7
 Built:        Mon Oct 12 06:06:01 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   f4bf5c7
 Built:        Mon Oct 12 06:06:01 UTC 2015
 OS/Arch:      linux/amd64

No caso de @tomfotherby e no seu @andrewmichaelsmith, o driver de armazenamento é aufs / devicemapper-xfs respectivamente.
Posso reproduzi-lo de forma consistente quando o driver de armazenamento é sobreposto

Posso replicar o travamento usando o script de @pmoust no CoreOS 835.12

Containers: 227
Images: 1
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.2.2-coreos-r2
Operating System: CoreOS 835.12.0
CPUs: 2
Total Memory: 3.864 GiB
Name: core-01
ID: WIYE:CGI3:2C32:LURO:MNHU:YQXU:NEU4:LPZG:YJM5:ZN3S:BBPF:3SXM

FWIW, achamos que podemos ter atribuído isso a este bug do kernel do mapeador de dispositivos: https://bugzilla.redhat.com/show_bug.cgi?id=1292481

@andrewmichaelsmith é um AWS AMI disponível com o patch?

@pmoust yum update em nossas caixas CentOS 7 AWS retirou o novo kernel daquele relatório de bug (kernel-3.10.0-327.10.1.el7).

editar: Embora se você estiver usando overlayfs, eu não acho que isso seja relevante para você?

1 sobre este assunto. Estou enfrentando este problema com Docker 1.10.1 no kernel 4.4.1-coreos no CoreOS Alpha
970.1.0 na AWS. Isso está causando uma séria instabilidade em nosso cluster de kubernetes e minha equipe está pensando em descartar completamente as janelas de encaixe.

Existe alguma investigação ativa sobre este problema?

@gopinatht As pessoas nesta edição parecem ser afetadas por uma série de problemas. Para nós, foi um bug no mapeador de dispositivos que corrigiu o problema, nada a ver com o projeto docker.

@andrewmichaelsmith Obrigado pela resposta. Existe alguma orientação sobre como chegar ao fundo do problema? sequência de docker ps chamada dá o seguinte:

read(5, 0xc20807d000, 4096) = -1 EAGAIN (Resource temporarily unavailable) write(5, "GET /v1.22/containers/json HTTP/"..., 109) = 109 futex(0x1fe97a0, FUTEX_WAKE, 1) = 1 futex(0x1fe9720, FUTEX_WAKE, 1) = 1 epoll_wait(4, {}, 128, 0) = 0 futex(0x1fea698, FUTEX_WAIT, 0, NULL

Isso é muito semelhante a vários outros relatórios aqui. O que mais eu poderia fazer para chegar ao fundo disso?

@andrewmichaelsmith tentou com kernel corrigido

Aqui estão os resultados https://github.com/coreos/bugs/issues/1117#issuecomment -191190839

@pmoust Obrigado pela atualização.

@andrewmichaelsmith @pmoust Você tem alguma

@gopinatht Não trabalho para docker / google ou tenho um interesse particular em você usar docker ou kubernetes, não importa o quão crítico seja para sua equipe ;-)

Eu nem sei qual driver de armazenamento você está usando? Para reiterar: encontramos um problema em que o docker travava completamente ao usar o driver de armazenamento devicemapper. Atualizar nosso kernel para kernel-3.10.0-327.10.1.el7 resolveu esse problema. Eu realmente não posso adicionar mais nada a isso.

Se você não estiver usando o mapeador de dispositivos como driver de armazenamento do docker, minhas descobertas provavelmente não significam muito para você.

@andrewmichaelsmith Peço desculpas se pareci sugerir que você precisa fazer algo a respeito.

Eu estava apenas procurando orientação para investigação, pois estou obviamente perdido aqui. Obrigado por sua ajuda até agora de qualquer maneira.

Acabamos de obter isso no Ubuntu com uma versão mais recente do Kernel 3.13.0-83-generic . Todas as outras operações parecem estar bem - os únicos problemas estão relacionados a docker ps e alguns docker inspect aleatórios

Informações do Docker:

Containers: 51
 Running: 48
 Paused: 0
 Stopped: 3
Images: 92
Server Version: 1.10.3
Storage Driver: devicemapper
 Pool Name: docker-data-tpool
 Pool Blocksize: 65.54 kB
 Base Device Size: 5.369 GB
 Backing Filesystem: ext4
 Data file:
 Metadata file:
 Data Space Used: 19.14 GB
 Data Space Total: 102 GB
 Data Space Available: 82.86 GB
 Metadata Space Used: 33.28 MB
 Metadata Space Total: 5.369 GB
 Metadata Space Available: 5.335 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Library Version: 1.02.77 (2012-10-15)
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
 Volume: local
 Network: host bridge null
Kernel Version: 3.13.0-83-generic
Operating System: Ubuntu 14.04.4 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 29.96 GiB
Name: apocalypse.servers.lair.io
ID: Q444:V3WX:RIQJ:5B3T:SYFQ:H2TR:SPVF:U6YE:XNDX:HV2Z:CS7F:DEJJ
WARNING: No swap limit support

strace cauda:

futex(0x20844d0, FUTEX_WAIT, 0, NULL)   = 0
futex(0xc82002ea10, FUTEX_WAKE, 1)      = 1
clock_gettime(CLOCK_MONOTONIC, {216144, 494093555}) = 0
clock_gettime(CLOCK_MONOTONIC, {216144, 506740959}) = 0
futex(0xc82002ea10, FUTEX_WAKE, 1)      = 1
clock_gettime(CLOCK_MONOTONIC, {216144, 506835134}) = 0
clock_gettime(CLOCK_MONOTONIC, {216144, 506958105}) = 0
futex(0x20844d0, FUTEX_WAIT, 0

Além disso, depois de algum tempo - talvez alguns minutos - obtive a seguinte saída no strace bloqueado, embora também nunca tenha terminado:

futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0x20844d0, FUTEX_WAIT, 0, NULL

Depois de esperar mais algum tempo, os mesmos futex bloqueiam, mas desta vez há também um 'Erro de recurso temporariamente indisponível':

futex(0x20844d0, FUTEX_WAIT, 0, NULL)   = 0
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
clock_gettime(CLOCK_MONOTONIC, {216624, 607690506}) = 0
clock_gettime(CLOCK_MONOTONIC, {216624, 607853434}) = 0
futex(0x2083970, FUTEX_WAIT, 0, {0, 100000}) = -1 EAGAIN (Resource temporarily unavailable)
epoll_wait(5, {}, 128, 0)               = 0
clock_gettime(CLOCK_MONOTONIC, {216624, 608219882}) = 0
futex(0x2083980, FUTEX_WAKE, 1)         = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
clock_gettime(CLOCK_MONOTONIC, {216624, 608587202}) = 0
clock_gettime(CLOCK_MONOTONIC, {216624, 609140069}) = 0
clock_gettime(CLOCK_MONOTONIC, {216624, 609185048}) = 0
clock_gettime(CLOCK_MONOTONIC, {216624, 609272020}) = 0
futex(0xc82002ea10, FUTEX_WAKE, 1)      = 1
clock_gettime(CLOCK_MONOTONIC, {216624, 616982914}) = 0
sched_yield()                           = 0
clock_gettime(CLOCK_MONOTONIC, {216624, 626726774}) = 0
futex(0x20844d0, FUTEX_WAIT, 0, NULL)   = 0
futex(0x2083970, FUTEX_WAKE, 1)         = 1
futex(0x20838c0, FUTEX_WAKE, 1)         = 1
sched_yield()                           = 0
futex(0x20838c0, FUTEX_WAIT, 2, NULL)   = 0
futex(0x20838c0, FUTEX_WAKE, 1)         = 0
futex(0x20844d0, FUTEX_WAIT, 0, NULL

Observe que todas as vezes, o strace bloqueou no mesmo futex .

@akalipetis Você pode enviar SIGUSR1 para o processo e extrair o rastreamento de pilha completo dos logs do daemon, por favor?

Farei isso assim que encontrar de novo @ cpuguy83 - desculpe, mas eu não sabia disso ...

(Infelizmente) aconteceu novamente, você pode encontrar o stacktrace completo no arquivo anexado abaixo:

stacktrace.txt

Avise-me se desejar mais alguma coisa do meu lado.

/ cc @ cpuguy83

Muito apreciado, @akalipetis!

Sem problemas @ cpuguy83 - deixe-me saber se você gostaria de quaisquer outros dados, ou mesmo se gostaria de ter rastreamentos de pilha de futuras paradas.

Infelizmente, não consegui encontrar uma maneira de reproduzir isso ou identifiquei qualquer situação semelhante entre travamentos.

Desde que atualizamos para 1.11.0 executando testes de imagem docker rspec (~ 10 contêineres paralelos executando esses testes em uma máquina de 4 cpu) às vezes congela e falha com um tempo limite. O Docker congela completamente e não responde (por exemplo, docker ps ). Isso está acontecendo no vserver com Debian strech (btrfs) e com (vagrant) Parallels VM Ubuntu 14.04 (kernel com backport 3.19.0-31-generic, ext4).

O sistema de arquivos para /var/lib/docker em ambos os servidores foi limpo (o btrfs foi recriado) após o primeiro congelamento. O congelamento acontece aleatoriamente ao executar esses testes.

O rastreamento de pilha é anexado de ambos os servidores:
docker-log.zip

strace de docker-containerd e docker daemons :

# strace -p 21979 -p 22536
Process 21979 attached
Process 22536 attached
[pid 22536] futex(0x219bd90, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid 21979] futex(0xf9b170, FUTEX_WAIT, 0, NULL

Informações do Docker (Debian strech)

Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 1096
Server Version: 1.11.0
Storage Driver: btrfs
 Build Version: Btrfs v4.4
 Library Version: 101
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: host bridge null
Kernel Version: 4.4.0-1-amd64
Operating System: Debian GNU/Linux stretch/sid
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 11.74 GiB
Name: slave.webdevops.io
ID: WU2P:YOYC:VP2F:N6DE:BINB:B6YO:2HJO:JKZA:HTP3:SIDA:QOJZ:PJ2E
Docker Root Dir: /var/lib/docker
Debug mode (client): false
Debug mode (server): false
Username: webdevopsslave
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

Informações do Docker (Ubuntu 14.04 com kernel com backport)

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
root@DEV-VM:/var/lib/docker# docker info
Containers: 11
 Running: 1
 Paused: 0
 Stopped: 10
Images: 877
Server Version: 1.11.0
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 400
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge null host
Kernel Version: 3.19.0-31-generic
Operating System: Ubuntu 14.04.2 LTS
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 3.282 GiB
Name: DEV-VM
ID: KCQP:OGCT:3MLX:TAQD:2XG6:HBG2:DPOM:GJXY:NDMK:BXCK:QEIT:D6KM
Docker Root Dir: /var/lib/docker
Debug mode (client): false
Debug mode (server): false
Registry: https://index.docker.io/v1/

Versão Docker (Debian strech)

Client:
 Version:      1.11.0
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   4dc5990
 Built:        Wed Apr 13 18:22:26 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:22:26 2016
 OS/Arch:      linux/amd64

Versão do Docker (Ubuntu 14.04 com kernel com backport)

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

@mblaschke você quer usar -f para strace for golang programs afaik.

Posso confirmar esse bug para o Ubuntu 14.04, mas não tenho certeza se esse bug é realmente o problema na extensão do Debian com kernel 4.4. Ainda tentando obter mais informações.

O problema para a extensão do Debian com Docker 1.10.3 era o limite de processo do systemd (era 512, elevado para 8192) e nossos testes de contêiner do Docker agora estão sendo executados sem problemas. 1.11.0 ainda não está funcionando e os testes rspec ainda estão congelando, mas docker ps ainda responde no Debian Stretch com kernel 4.4, então acho que é outro problema.

Criado um novo problema # 22124 para rastrear o relatório de @mblaschke que pode ser algo novo.

também correndo para isso eu acredito

$ uname -a
Linux ip-10-15-42-103.ec2.internal 4.4.6-coreos #2 SMP Sat Mar 26 03:25:31 UTC 2016 x86_64 Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz GenuineIntel GNU/Linux

$ docker version
Client:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.5.3
 Git commit:   9894698
 Built:
 OS/Arch:      linux/amd64

Server:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.5.3
 Git commit:   9894698
 Built:
 OS/Arch:      linux/amd64

$ docker info
Containers: 198
Images: 196
Server Version: 1.9.1
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: journald
Kernel Version: 4.4.6-coreos
Operating System: CoreOS 991.2.0 (Coeur Rouge)
CPUs: 2
Total Memory: 3.862 GiB

$ sudo strace -q -y -v -f docker ps
<snip>
[pid 26889] connect(5<socket:[18806726]>, {sa_family=AF_LOCAL, sun_path="/var/run/docker.sock"}, 23) = 0
[pid 26889] clock_gettime(CLOCK_REALTIME, {1462217998, 860739240}) = 0
[pid 26889] epoll_ctl(4<anon_inode:[eventpoll]>, EPOLL_CTL_ADD, 5<socket:[18806726]>, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=914977888, u64=140334676407392}}) = 0
[pid 26889] getsockname(5<socket:[18806726]>, {sa_family=AF_LOCAL, NULL}, [2]) = 0
[pid 26889] getpeername(5<socket:[18806726]>, {sa_family=AF_LOCAL, sun_path="/var/run/docker.sock"}, [23]) = 0
[pid 26889] read(5<socket:[18806726]>,  <unfinished ...>
[pid 26893] <... futex resumed> )       = 1
[pid 26889] <... read resumed> 0xc820015000, 4096) = -1 EAGAIN (Resource temporarily unavailable)
[pid 26893] futex(0xc8200e9790, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid 26891] futex(0xc820026a10, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily unavailable)
[pid 26891] epoll_wait(4<anon_inode:[eventpoll]>, {{EPOLLOUT, {u32=914978080, u64=140334676407584}}, {EPOLLOUT, {u32=914977888, u64=140334676407392}}}, 128, 0) = 2
[pid 26891] epoll_wait(4<anon_inode:[eventpoll]>,  <unfinished ...>
[pid 26889] write(5<socket:[18806726]>, "GET /v1.21/containers/json HTTP/"..., 88 <unfinished ...>
[pid 26890] <... select resumed> )      = 0 (Timeout)
[pid 26889] <... write resumed> )       = 88
[pid 26891] <... epoll_wait resumed> {{EPOLLOUT, {u32=914977888, u64=140334676407392}}}, 128, -1) = 1
[pid 26891] epoll_wait(4<anon_inode:[eventpoll]>,  <unfinished ...>
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 935071149}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 861179188}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 935216184}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 861327424}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 935376601}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 861479813}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 935543531}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 861646718}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 935709999}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 861817062}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 935872149}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 861975102}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 936046201}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 862149543}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 936215534}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 862318597}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 936384887}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 862488231}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 936547503}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 862650775}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 936708047}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 862810981}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 936875834}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 862978790}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 937049520}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 863161620}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 937216897}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 863319694}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 937382999}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 863485851}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 937549477}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 863652283}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 937722463}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 863833602}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 937888537}) = 0
[pid 26889] futex(0xc8200e9790, FUTEX_WAKE, 1 <unfinished ...>
[pid 26890] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid 26889] <... futex resumed> )       = 1
[pid 26893] <... futex resumed> )       = 0
[pid 26890] <... clock_gettime resumed> {1462217998, 864010029}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20} <unfinished ...>
[pid 26889] futex(0x1df2f50, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid 26893] futex(0xc8200e9790, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid 26890] <... select resumed> )      = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 938059687}) = 0
[pid 26890] futex(0x1df2400, FUTEX_WAIT, 0, {60, 0}

@mwhooker Infelizmente, um strace do cliente docker não vai ajudar muito, pois precisamos ver o que está acontecendo no daemon.

Use SIGUSR1 no daemon travado para que ele exiba um rastreamento de pilha em seus logs.

aqui está minha saída sigusr1 https://gist.github.com/mwhooker/6858c0d0c123e214ef69d0a4bff2d7cc (cc @ cpuguy83)

Aqui está outro dump sigusr1 de um daemon docker preso

https://gist.github.com/mwhooker/e837f08370145d183e661c03a5b9d07e

strace novamente encontra o daemon em FUTEX_WAIT

Eu posso realmente me conectar ao host desta vez, então posso realizar uma depuração adicional, embora irei matar o daemon em breve

ping @ cpuguy83 ^^

Tenho o mesmo problema em 1.11.1 (4.2.5-300.fc23), Overlay / EXT4. Acontece quando eu executo um trabalhador do Celery, carrego-o com jobs e tento stop it.

Não posso então executar nada dentro dele:
rpc error: code = 2 desc = "oci runtime error: exec failed: exit status 1"

Acho que parte do contêiner está destruída, mas não consigo terminar o trabalho. Eu confirmei que Celery foi morto dentro do contêiner, então não tenho certeza do que o está segurando.

Editar:
O aipo não foi eliminado completamente, há um processo preso em D, então acho que reiniciar é a única opção.

Consulte https://github.com/docker/docker/issues/20401#issuecomment -231337800

Tive o mesmo problema sob carga elevada (criação / exclusão de contêineres em alta taxa)

• CoreOS 1068.8.0
• Docker 1.10.3
• uname -a:

Linux coreos_k8s_28 4.6.3-coreos #2 SMP Mon Jul 18 06:10:39 UTC 2016 x86_64 Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz GenuineIntel GNU/Linux

• kubernetes 1.2.0

Aqui está minha essência dos logs de depuração do docker (enviados SIGUSR1 para o daemon do docker): https://gist.github.com/ntquyen/409376bc0d8418a31023c1546241e190

Como @ntquyen . Mesma versão do sistema operacional / kernel / docker.

Repro ainda está de pé https://github.com/docker/docker/issues/13885#issuecomment -181811082

No meu caso, pode ser porque as máquinas estavam funcionando com mais de 90% do espaço em disco usado. Eu designei mais espaço em disco para eles e eles estão funcionando de forma bastante estável agora, mesmo estando sob alta carga.

@mwhooker , parece que seu daemon está travado em uma chamada de netlink para excluir uma interface.
Quais opções de daemon você configurou?

Observe que quando digo "travado", não está realmente congelando todo o daemon, mas qualquer chamada de API que precise acessar esse objeto recipiente também travará porque ficará travada esperando o mutex do recipiente que está travado na chamada netlink.

Analisando várias coisas que podemos fazer para mitigar esses tipos de problemas.

@pmoust Você pode fornecer um rastreamento de pilha do daemon? (enviar SIGUSR1 para um daemon preso e coletar o rastreamento dos logs do daemon)
Além disso, as opções com as quais você iniciou o daemon.

Obrigado!

@ntquyen Acho que o problema que você
Você abordou o problema apenas uma vez?

@ cpuguy83 obrigado por entrar em

/usr/bin/docker daemon --icc=false --storage-driver=overlay --log-driver=journald --host=fd://

Não tenho certeza se está relacionado, mas também notamos um monte dessas mensagens em nossos registros

Jul 19 10:22:55 ip-10-0-37-191.ec2.internal systemd-networkd[852]: veth0adae8a: Removing non-existent address: fe80::e855:98ff:fe3f:8b2c/64 (valid forever)

(editar: também estes)

[19409.536106] unregister_netdevice: waiting for veth2304bd1 to become free. Usage count = 1

@mwhooker, a mensagem inferior provavelmente é aqui que o docker está --userland-proxy=false

@ cpuguy83 interessante você mencionar que estamos executando o hyperkube com --proxy-mode=userspace . é possível que esteja causando isso?

@mwhooker baseado na descrição do sinalizador, não parece.
Basicamente --userland-proxy=false ativa o modo hairpin na interface de ponte do contêiner, o que parece desencadear alguma condição no kernel onde quando adicionamos / removemos muitos contêineres (ou fazemos um monte em paralelo) isso causa um congelamento muito ruim (e a mensagem de erro que você vê).

Você pode verificar se as interfaces de ponte estão no modo hairpin.

@ cpuguy83 este é o comando docker de um conjunto separado de servidores que também apresenta esse problema

docker daemon --host=fd:// --icc=false --storage-driver=overlay --log-driver=journald --exec-opt native.cgroupdriver=systemd --bip=10.2.122.1/24 --mtu=8951 --ip-masq=true --selinux-enable

e posso ver que essas interfaces veth estão em modo de grampo

cat /sys/devices/virtual/net/docker0/brif/veth*/hairpin_mode
1
1

Eu me pergunto se essa é a causa de pelo menos um dos problemas de suspensão do docker que estamos vendo.

(fwiw, estamos usando proxy do espaço do usuário no kube-proxy devido a uma interação com flanela https://github.com/kubernetes/kubernetes/issues/20391)

@ cpuguy83 Infelizmente, estou usando o docker 1.10 no coreos estável mais recente e não consigo atualizar para o docker 1.12. O problema não foi resolvido completamente (como eu pensava) depois que aumentei o espaço em disco.

O mesmo aqui.

• Docker: 1,12
• Kernel: 4.4.3
• Distro: ubuntu

Daemon:

    # strace -q -y -v -p `pidof dockerd`
    futex(0x2a69be8, FUTEX_WAIT, 0, NULL
    futex(0xc820e1b508, FUTEX_WAKE, 1)      = 1
    futex(0x2a69be8, FUTEX_WAIT, 0, NULL)   = 0
    futex(0xc8224b0508, FUTEX_WAKE, 1)      = 1
    futex(0x2a69be8, FUTEX_WAIT, 0, NULL)   = 0
    futex(0x2a69be8, FUTEX_WAIT, 0, NULL

Cliente:

    # strace docker ps
    execve("/usr/bin/docker", ["docker", "ps"], [/* 24 vars */]) = 0
    brk(0)                                  = 0x2584000
    ...
    stat("/root/.docker/config.json", {st_mode=S_IFREG|0600, st_size=91, ...}) = 0
    openat(AT_FDCWD, "/root/.docker/config.json", O_RDONLY|O_CLOEXEC) = 3
    read(3, "{\n\t\"auths\": {\n\t\t\"https://quay.io"..., 512) = 91
    close(3)                                = 0
    ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
    ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
    futex(0xc820068108, FUTEX_WAKE, 1)      = 1
    futex(0xc820068108, FUTEX_WAKE, 1)      = 1
    socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
    setsockopt(3, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
    connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/docker.sock"}, 23) = 0
    epoll_create1(EPOLL_CLOEXEC)            = 4
    epoll_ctl(4, EPOLL_CTL_ADD, 3, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=3136698616, u64=140182279305464}}) = 0
    getsockname(3, {sa_family=AF_LOCAL, NULL}, [2]) = 0
    getpeername(3, {sa_family=AF_LOCAL, sun_path="/var/run/docker.sock"}, [23]) = 0
    futex(0xc820032d08, FUTEX_WAKE, 1)      = 1
    read(3, 0xc820356000, 4096)             = -1 EAGAIN (Resource temporarily unavailable)
    write(3, "GET /v1.24/containers/json HTTP/"..., 95) = 95
    futex(0x132aca8, FUTEX_WAIT, 0, NULL

Ainda está acontecendo aqui no Debian ao executar testes rspec:

Kernel: 4.4.0-28-genérico
Docker: 1.12.2-0 ~ xenial

A solução alternativa atual é voltar ao Docker 1.10.3-0 ~ wily, que é a última versão estável.

@mblaschke @Bregor Você pode postar um stacktrace, por favor?

Isso já vem acontecendo em nosso ambiente há algum tempo: [

$ docker info
Containers: 20
 Running: 6
 Paused: 0
 Stopped: 14
Images: 57
Server Version: 1.11.1
Storage Driver: overlay
 Backing Filesystem: extfs
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge null host
Kernel Version: 3.18.27
Operating System: Debian GNU/Linux 8 (jessie)
OSType: linux
Architecture: x86_64
CPUs: 24
Total Memory: 125.8 GiB
Name: appdocker414-sjc1
ID: ZTWC:53NH:VKUZ:5FZK:SLZN:YPI4:ICK2:W7NF:UIGD:P2NQ:RHUD:PS6Y
Docker Root Dir: /var/lib/docker
Debug mode (client): false
Debug mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support

Kernel: 3.18.27

Stackstrace: https://gist.github.com/dmyerscough/6948218a228ff69dd6e309f8de0f0261

@dmyerscough Parece ser https://github.com/docker/docker/issues/22732 . Fixado em 1.11.2 e 1.12

Executar um contêiner simples com docker run --rm cada minuto e o serviço Docker bloqueia de vez em quando até que seja reiniciado.

docker -D info
Containers: 6
 Running: 2
 Paused: 0
 Stopped: 4
Images: 6
Server Version: 1.11.2
Storage Driver: overlay
 Backing Filesystem: extfs
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: host bridge null
Kernel Version: 4.7.3-coreos-r2
Operating System: CoreOS 1185.3.0 (MoreOS)
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 7.8 GiB
Name: <hostname>
ID: GFHQ:Y6IV:XCQI:Y2NA:PCQN:DEII:OSPZ:LENL:OCFU:6CBI:MDFV:EMD7
Docker Root Dir: /var/lib/docker
Debug mode (client): true
Debug mode (server): false
Username: <username>
Registry: https://index.docker.io/v1/

Última mensagem antes de ser suspenso:

Nov 04 16:42:01 dockerd[1447]: time="2016-11-04T16:42:01Z" level=error msg="containerd: deleting container" error="wait: no child processes"

@ liquid-sky você tem mais informações, talvez os logs daemon mostrem algo útil ou um rastreamento de pilha? Observe também que não temos pacotes oficiais para CoreOS; visto que eles distribuem um pacote / configuração modificada, pode valer a pena relatar lá.

@thaJeztah Infelizmente, o log do diário mudou desde a última vez que o processo foi registrado, quando eu o abri, vejo que ele está travado no bloqueio mutex.

$ ps -ef | grep -w 148[9] | head -1
root      1489     1  0 Nov02 ?        00:20:35 docker daemon --host=fd:// --insecure-registry=<registry_address> --selinux-enabled

sudo strace -e verbose=all -v -p 1489
Process 1489 attached
futex(0x22509c8, FUTEX_WAIT, 0, NULL

$ sudo strace docker ps
.....
clock_gettime(CLOCK_REALTIME, {1478601605, 8732879}) = 0
clock_gettime(CLOCK_REALTIME, {1478601605, 9085011}) = 0
clock_gettime(CLOCK_REALTIME, {1478601605, 9242006}) = 0
socket(PF_LOCAL, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
setsockopt(3, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
connect(3, {sa_family=AF_LOCAL, sun_path="/run/systemd/journal/socket"}, 30) = 0
epoll_create1(EPOLL_CLOEXEC)            = 4
epoll_ctl(4, EPOLL_CTL_ADD, 3, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=3317119944, u64=140066495609800}}) = 0
getsockname(3, {sa_family=AF_LOCAL, NULL}, [2]) = 0
getpeername(3, {sa_family=AF_LOCAL, sun_path="/run/systemd/journal/socket"}, [30]) = 0
stat("/root/.docker/config.json", 0xc8203b6fa8) = -1 ENOENT (No such file or directory)
stat("/root/.dockercfg", 0xc8203b7078)  = -1 ENOENT (No such file or directory)
stat("/bin/docker-credential-secretservice", 0xc8203b7148) = -1 ENOENT (No such file or directory)
stat("/sbin/docker-credential-secretservice", 0xc8203b7218) = -1 ENOENT (No such file or directory)
stat("/usr/bin/docker-credential-secretservice", 0xc8203b72e8) = -1 ENOENT (No such file or directory)
stat("/usr/sbin/docker-credential-secretservice", 0xc8203b73b8) = -1 ENOENT (No such file or directory)
stat("/usr/local/bin/docker-credential-secretservice", 0xc8203b7488) = -1 ENOENT (No such file or directory)
stat("/usr/local/sbin/docker-credential-secretservice", 0xc8203b7558) = -1 ENOENT (No such file or directory)
stat("/opt/bin/docker-credential-secretservice", 0xc8203b7628) = -1 ENOENT (No such file or directory)
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
futex(0xc8202c9108, FUTEX_WAKE, 1)      = 1
clock_gettime(CLOCK_REALTIME, {1478601605, 11810493}) = 0
clock_gettime(CLOCK_REALTIME, {1478601605, 11888495}) = 0
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 5
setsockopt(5, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
connect(5, {sa_family=AF_LOCAL, sun_path="/var/run/docker.sock"}, 23) = 0
clock_gettime(CLOCK_REALTIME, {1478601605, 12378242}) = 0
epoll_ctl(4, EPOLL_CTL_ADD, 5, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=3317119752, u64=140066495609608}}) = 0
getsockname(5, {sa_family=AF_LOCAL, NULL}, [2]) = 0
getpeername(5, {sa_family=AF_LOCAL, sun_path="/var/run/docker.sock"}, [23]) = 0
futex(0xc820026d08, FUTEX_WAKE, 1)      = 1
read(5, 0xc8203d6000, 4096)             = -1 EAGAIN (Resource temporarily unavailable)
write(5, "GET /v1.23/containers/json HTTP/"..., 89) = 89
futex(0xc820026d08, FUTEX_WAKE, 1)      = 1
futex(0x22509c8, FUTEX_WAIT, 0, NULL

E o mesmo acontece com todos os containerd serviço:

ps -ef | grep container[d]
root      1513  1489  0 Nov02 ?        00:00:53 containerd -l /var/run/docker/libcontainerd/docker-containerd.sock --runtime runc --start-timeout 2m
root      2774  1513  0 Nov02 ?        00:00:00 containerd-shim a90d4642fd88ab38c66a733e2cef8f427533e736d14d48743d42f55dec62447f /var/run/docker/libcontainerd/a90d4642fd88ab38c66a733e2cef8f427533e736d14d48743d42f55dec62447f runc
root      3946  1513  0 Nov02 ?        00:00:00 containerd-shim c8903c4a137fbb297efc3fcf2c69d746e94431f22c7fdf1a46ff7c69d04ffb0d /var/run/docker/libcontainerd/c8903c4a137fbb297efc3fcf2c69d746e94431f22c7fdf1a46ff7c69d04ffb0d runc
root      4783  1513  0 Nov02 ?        00:03:36 containerd-shim d8c2203adfc26f7d11a62d9d90ddf97f04c458f72855ee1987ed1af911a2ab55 /var/run/docker/libcontainerd/d8c2203adfc26f7d11a62d9d90ddf97f04c458f72855ee1987ed1af911a2ab55 runc
root     16684  1513  0 Nov02 ?        00:00:00 containerd-shim 4d62424ca8cceb29c877bf129cd46341a53e191c9858b93aca3d5cbcfaaa1876 /var/run/docker/libcontainerd/4d62424ca8cceb29c877bf129cd46341a53e191c9858b93aca3d5cbcfaaa1876 runc
root     16732  1513  0 Nov02 ?        00:03:24 containerd-shim 2f8e2a858306322c10aa7823c92f22133f1c5e5f267ce61e542c1d8bd537b121 /var/run/docker/libcontainerd/2f8e2a858306322c10aa7823c92f22133f1c5e5f267ce61e542c1d8bd537b121 runc
root     20902  1513  0 Nov02 ?        00:00:05 containerd-shim 58572e7fab122d593bdb096b0dd33551c22ce50a0c51d6662bc0c7b3d3bf9248 /var/run/docker/libcontainerd/58572e7fab122d593bdb096b0dd33551c22ce50a0c51d6662bc0c7b3d3bf9248 runc

$ sudo strace -T -e verbose=all -v -p 1513
Process 1513 attached
futex(0x1028dc8, FUTEX_WAIT, 0, NULL

@ liquid-sky strace em um dockerd normal também mostrará futex(0x22509c8, FUTEX_WAIT, 0, NULL que não mostra nada significativo, eu acho ... é melhor você adicionar -f para que o strace rastreie todos os tópicos .

Acho que isso pode estar relacionado a esse problema. No sentido de que executamos o contêiner a cada minuto com --rm e o Docker trava nesse contêiner específico, no entanto, alguns nós onde docker ps está travado não têm unregistered loopback device mensagem.

Por precaução, um snippet de strace -f do daemon do Docker:

[pid  1507] select(0, NULL, NULL, NULL, {0, 20} <unfinished ...>
[pid  1766] write(23, "\2\0\0\0\0\0\0\321I1108 10:48:12.429657   "..., 217) = 217
[pid  1507] <... select resumed> )      = 0 (Timeout)
[pid  1766] futex(0xc822075d08, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid  1507] clock_gettime(CLOCK_MONOTONIC, {514752, 140621361}) = 0
[pid  1875] <... epoll_wait resumed> {{EPOLLIN|EPOLLOUT|EPOLLRDHUP, {u32=1298424080, u64=140528333381904}}}, 128, -1) = 1
[pid  1507] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1875] epoll_wait(6,  <unfinished ...>
[pid  1507] <... clock_gettime resumed> {1478602092, 431376727}) = 0
[pid  1507] select(0, NULL, NULL, NULL, {0, 20} <unfinished ...>
[pid  1514] <... read resumed> "I1108 10:48:12.431656    12 mast"..., 32768) = 1674
[pid  1507] <... select resumed> )      = 0 (Timeout)
[pid  1514] futex(0xc822075d08, FUTEX_WAKE, 1 <unfinished ...>
[pid  1507] clock_gettime(CLOCK_MONOTONIC,  <unfinished ...>
[pid  1766] <... futex resumed> )       = 0
[pid  1514] <... futex resumed> )       = 1
[pid  1766] select(0, NULL, NULL, NULL, {0, 100} <unfinished ...>
[pid  1514] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1507] <... clock_gettime resumed> {514752, 142476308}) = 0
[pid  1514] <... clock_gettime resumed> {1478602092, 432632124}) = 0
[pid  1507] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1514] write(45, "{\"log\":\"I1108 10:48:12.431656   "..., 349 <unfinished ...>
[pid  1507] <... clock_gettime resumed> {1478602092, 432677401}) = 0
[pid  1514] <... write resumed> )       = 349
[pid  1507] select(0, NULL, NULL, NULL, {0, 20} <unfinished ...>
[pid  1514] clock_gettime(CLOCK_REALTIME, {1478602092, 432812895}) = 0
[pid  1766] <... select resumed> )      = 0 (Timeout)
[pid  1514] write(45, "{\"log\":\"I1108 10:48:12.431763   "..., 349 <unfinished ...>
[pid  1507] <... select resumed> )      = 0 (Timeout)
[pid  1514] <... write resumed> )       = 349
[pid  1507] clock_gettime(CLOCK_MONOTONIC,  <unfinished ...>
[pid  1514] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1507] <... clock_gettime resumed> {514752, 142831922}) = 0
[pid  1514] <... clock_gettime resumed> {1478602092, 432948135}) = 0
[pid  1507] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1514] write(45, "{\"log\":\"I1108 10:48:12.431874   "..., 349 <unfinished ...>
[pid  1507] <... clock_gettime resumed> {1478602092, 432989394}) = 0
[pid  1514] <... write resumed> )       = 349
[pid  1507] select(0, NULL, NULL, NULL, {0, 20} <unfinished ...>
[pid  1766] read(44, "I1108 10:48:12.432255    12 mast"..., 32768) = 837
[pid  1514] clock_gettime(CLOCK_REALTIME, {1478602092, 433114452}) = 0
[pid  1766] read(44,  <unfinished ...>
[pid  1514] write(45, "{\"log\":\"I1108 10:48:12.431958   "..., 349) = 349
[pid  1507] <... select resumed> )      = 0 (Timeout)
[pid  1514] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1507] clock_gettime(CLOCK_MONOTONIC,  <unfinished ...>
[pid  1514] <... clock_gettime resumed> {1478602092, 433272783}) = 0
[pid  1507] <... clock_gettime resumed> {514752, 143176397}) = 0
[pid  1514] write(45, "{\"log\":\"I1108 10:48:12.432035   "..., 349 <unfinished ...>
[pid  1507] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1514] <... write resumed> )       = 349
[pid  1507] <... clock_gettime resumed> {1478602092, 433350170}) = 0
[pid  1514] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1507] select(0, NULL, NULL, NULL, {0, 20} <unfinished ...>
[pid  1514] <... clock_gettime resumed> {1478602092, 433416138}) = 0
[pid  1514] write(45, "{\"log\":\"I1108 10:48:12.432126   "..., 349) = 349
[pid  1514] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1507] <... select resumed> )      = 0 (Timeout)
[pid  1514] <... clock_gettime resumed> {1478602092, 433605782}) = 0
[pid  1507] clock_gettime(CLOCK_MONOTONIC,  <unfinished ...>
[pid  1514] write(45, "{\"log\":\"I1108 10:48:12.432255   "..., 349 <unfinished ...>
[pid  1507] <... clock_gettime resumed> {514752, 143537029}) = 0
[pid  1514] <... write resumed> )       = 349
[pid  1507] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1514] clock_gettime(CLOCK_REALTIME, {1478602092, 433748730}) = 0
[pid  1507] <... clock_gettime resumed> {1478602092, 433752245}) = 0
[pid  1514] write(45, "{\"log\":\"I1108 10:48:12.432343   "..., 348 <unfinished ...>
[pid  1507] futex(0xc8211b2d08, FUTEX_WAKE, 1 <unfinished ...>
[pid  1514] <... write resumed> )       = 348
[pid  1507] <... futex resumed> )       = 1
[pid 10488] <... futex resumed> )       = 0
[pid 10488] write(23, "\2\0\0\0\0\0\t\317I1108 10:48:12.431656   "..., 2519 <unfinished ...>
[pid  1514] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1507] select(0, NULL, NULL, NULL, {0, 20} <unfinished ...>
[pid 10488] <... write resumed> )       = 2519
[pid 10488] futex(0xc8211b2d08, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid  1875] <... epoll_wait resumed> {{EPOLLIN|EPOLLOUT|EPOLLRDHUP, {u32=1298424080, u64=140528333381904}}}, 128, -1) = 1
[pid  1514] <... clock_gettime resumed> {1478602092, 434094221}) = 0
[pid  1514] write(45, "{\"log\":\"I1108 10:48:12.432445   "..., 349) = 349
[pid  1514] futex(0xc820209908, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid  1507] <... select resumed> )      = 0 (Timeout)
[pid  1507] clock_gettime(CLOCK_MONOTONIC, {514752, 144370753}) = 0
[pid  1507] futex(0x224fe10, FUTEX_WAIT, 0, {60, 0} <unfinished ...>
[pid  1875] epoll_wait(6,  <unfinished ...>
[pid  1683] <... futex resumed> )       = -1 ETIMEDOUT (Connection timed out)
[pid  1683] clock_gettime(CLOCK_MONOTONIC, {514752, 292709791}) = 0
[pid  1683] futex(0x224fe10, FUTEX_WAKE, 1) = 1
[pid  1507] <... futex resumed> )       = 0

Estou usando o devicemapper com loopback no centos 7.

Não tenho certeza sobre o que aconteceu, mas dmsetup udevcookies & dmsetup udevcomplete <cookie> funciona para mim.

@thaJeztah você poderia ajudar a explicar o que aconteceu?

Estou repetindo o que já foi comentado muitas vezes aqui. Se você encontrar um travamento , envie o sinal SIGUSR1 para o processo daemon e copie o rastreio que está gravado nos logs. A saída do Strace não é útil para depurar travamentos, provavelmente é de um processo do cliente e geralmente nem mostra se o processo está travado ou apenas suspenso.

Eu tenho um dump do USR1 que @tonistiigi pediu com um hang-under-load.

$ docker info
Containers: 18
 Running: 15
 Paused: 0
 Stopped: 3
Images: 232
Server Version: 1.12.3
Storage Driver: devicemapper
 Pool Name: vg_ex-docker--pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 107.4 GB
 Backing Filesystem: xfs
 Data file: 
 Metadata file: 
 Data Space Used: 132.8 GB
 Data Space Total: 805.3 GB
 Data Space Available: 672.5 GB
 Metadata Space Used: 98.46 MB
 Metadata Space Total: 4.001 GB
 Metadata Space Available: 3.903 GB
 Thin Pool Minimum Free Space: 80.53 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: true
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Library Version: 1.02.107-RHEL7 (2016-06-09)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: null bridge host overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 3.10.0-327.36.2.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 56
Total Memory: 251.6 GiB
Name: server.masked.example.com
ID: Z7J7:CLEG:KZPK:TNEI:QLYL:JBTO:XNM4:NX2X:KPQC:VHPC:6SFS:G4GR
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

docker.txt

do log fornecido, parece que travou em dm_udev_wait

goroutine 2747 [syscall, 12 minutes, locked to thread]:
github.com/docker/docker/pkg/devicemapper._Cfunc_dm_udev_wait(0xc80d4d887c, 0xc800000000)
\t??:0 +0x41
github.com/docker/docker/pkg/devicemapper.dmUdevWaitFct(0xd4d887c, 0x44288e)
\t/root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/pkg/devicemapper/devmapper_wrapper.go:222 +0x22
github.com/docker/docker/pkg/devicemapper.UdevWait(0xc821c7e8f8, 0x0, 0x0)
\t/root/rpmbuild/BUILD/docker-engine/.gopath/src
Nov 17 06:50:13 server docker: /github.com/docker/docker/pkg/devicemapper/devmapper.go:259 +0x3b
github.com/docker/docker/pkg/devicemapper.activateDevice(0xc82021a880, 0x1e, 0xc8202f0cc0, 0x57, 0x9608, 0x1900000000, 0x0, 0x0, 0x0, 0x0)
\t/root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/pkg/devicemapper/devmapper.go:771 +0x8b8
github.com/docker/docker/pkg/devicemapper.ActivateDevice(0xc82021a880, 0x1e, 0xc8202f0cc0, 0x57, 0x9608, 0x1900000000, 0x0, 0x0)
\t/root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/pkg/devicemapper/devmapper.go:732 +0x78
github.com/docker/docker/daemon/graphdriver/devmapper.(*DeviceSet).activateDeviceIfNeeded(0xc8200b6340, 0xc8208e0a40, 0xc8200b6300, 0x0, 0x0)
\t/root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/daemon/graphdriver/devmapper/deviceset.go:539 +0x58d
github.com/docker/docker/daemon/graphdriver/devmapper.(*DeviceSet).MountDevice(0xc8200b6340, 0xc820a00200, 0x40, 0xc820517ab0, 0x61, 0x0, 0x0, 0x0, 0x0)
\t/root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/daemon/graphdriver/devmapper/deviceset.go:2269 +0x2cd
github.com/docker/docker/daemon/graphdriver/devmapper.(*Driver).Get(0xc82047bf40, 0xc820a00200, 0x40, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
\t/root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/daemon/graphdriver/devmapper/driver.go:185 +0x62f
github.com/docker/docker/daemon/graphdriver.(*NaiveDiffDriver).Get(0xc8201c2680, 0xc820a00200, 0x40, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
\t<autogenerated>:30 +0xa6

problemas semelhantes # 27900 # 27543

@ AaronDMarasco-VSI Você já tentou dmsetup udevcomplete_all ?

@ coolljt0725 Não, desculpe, depois de despejar o log para relatórios, reiniciei o daemon sem brincar mais com ele.

@tonistiigi , rastreamento de pilha completo do daemon do Docker após SIGUSR1 pode ser encontrado aqui

O rastreamento de @ liquid-sky parece estar bloqueado no soquete netlink

goroutine 13038 [syscall, 9838 minutes, locked to thread]:
syscall.Syscall6(0x2d, 0x16, 0xc820fc3000, 0x1000, 0x0, 0xc8219bc028, 0xc8219bc024, 0x0, 0x300000002, 0x66b5a6)
    /usr/lib/go1.6/src/syscall/asm_linux_amd64.s:44 +0x5
syscall.recvfrom(0x16, 0xc820fc3000, 0x1000, 0x1000, 0x0, 0xc8219bc028, 0xc8219bc024, 0x427289, 0x0, 0x0)
    /usr/lib/go1.6/src/syscall/zsyscall_linux_amd64.go:1712 +0x9e
syscall.Recvfrom(0x16, 0xc820fc3000, 0x1000, 0x1000, 0x0, 0x1000, 0x0, 0x0, 0x0, 0x0)
    /usr/lib/go1.6/src/syscall/syscall_unix.go:251 +0xb9
github.com/vishvananda/netlink/nl.(*NetlinkSocket).Receive(0xc820c6c5e0, 0x0, 0x0, 0x0, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go:341 +0xae
github.com/vishvananda/netlink/nl.(*NetlinkRequest).Execute(0xc820dded20, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go:228 +0x20b
github.com/vishvananda/netlink.LinkSetMasterByIndex(0
 x7f1e88c67c20, 0xc820e00630, 0x3, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/vishvananda/netlink/link_linux.go:231 +0x3b0
github.com/vishvananda/netlink.LinkSetMaster(0x7f1e88c67c20, 0xc820e00630, 0xc8219bc550, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/vishvananda/netlink/link_linux.go:205 +0xb7
github.com/docker/libnetwork/drivers/bridge.addToBridge(0xc820c78830, 0xb, 0x177bf88, 0x7, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/docker/libnetwork/drivers/bridge/bridge.go:782 +0x275
github.com/docker/libnetwork/drivers/bridge.(*driver).CreateEndpoint(0xc820316640, 0xc8201f6840, 0x40, 0xc821879500, 0x40, 0x7f1e88c67bd8, 0xc820f38580, 0xc821a87bf0, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/docker/libnetwork/drivers/bridge/bridge.go:1004 +0x1436
github.com/docker/libnetwork.(*network).addEndpoint(0xc820f026c0, 0xc8209f2300, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/docker/libnetwork/network.go:749 +0x21b
github.com/docker/libnetwork.(*network).CreateEndpoint(0xc820f026c0, 0xc820eb1909, 0x6, 0xc8210af160, 0x4, 0x4, 0x0, 0x0, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/docker/libnetwork/network.go:813 +0xaa7
github.com/docker/docker/daemon.(*Daemon).connectToNetwork(0xc82044e480, 0xc820e661c0, 0x177aea8, 0x6, 0xc820448c00, 0x0, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/.gopath/src/github.com/docker/docker/daemon/container_operations.go:539 +0x39f
github.com/docker/docker/daemon.(*Daemon).allocateNetwork(0xc82044e480, 0xc820e661c0, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker
 -1.11.2/.gopath/src/github.com/docker/docker/daemon/container_operations.go:401 +0x373
github.com/docker/docker/daemon.(*Daemon).initializeNetworking(0xc82044e480, 0xc820e661c0, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/.gopath/src/github.com/docker/docker/daemon/container_operations.go:680 +0x459
github.com/docker/docker/daemon.(*Daemon).containerStart(0xc82044e480, 0xc820e661c0, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/.gopath/src/github.com/docker/docker/daemon/start.go:125 +0x219
github.com/docker/docker/daemon.(*Daemon).ContainerStart(0xc82044e480, 0xc820ed61d7, 0x40, 0x0, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/.gopath/src/github.com/docker/docker/daemon/start.go:75 +0x575

cc @aboch

Como outros sugeriram, isso é provavelmente um efeito colateral de algo muito ruim acontecendo no kernel.
Estamos adicionando https://github.com/docker/libnetwork/pull/1557 para tentar mitigar essa situação.

Talvez eu tenha outros dois três rastreamentos de pilha com algumas mensagens de erro (retiradas do journalctl syslog).
Estou executando alguns testes rspec / serverspec para imagens do docker e, neste estado, o docker parece não responder. O teste é interrompido por mais de 20 minutos (tentará novamente 5 vezes se falhar).
Cada teste de imagem é concluído em menos de 5 minutos, o teste agora está sendo executado por pelo menos 30 ou 60 minutos.

https://gist.github.com/mblaschke/d5d38cb34f6178e50e465c6e1f02131c

uname -a:
Linux webdevops.infogene.fr 4.4.0-47-generic # 68-Ubuntu SMP Quarta-feira 26 de outubro 19:39:52 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux

informações do docker:
Recipientes: 5
Em execução: 1
Pausado: 0
Parado: 4
Imagens: 1208
Versão do servidor: 1.12.3
Driver de armazenamento: aufs
Dir raiz: / var / lib / docker / aufs
Sistema de arquivos de backup: extfs
Dirs: 449
Compatível com Dirperm1: verdadeiro
Driver de registro: arquivo json
Driver Cgroup: cgroupfs
Plugins:
Volume: local
Rede: sobreposição nula de host de ponte
Enxame: inativo
Runtimes: runc
Tempo de execução padrão: runc
Opções de segurança: apparmor seccomp
Versão do kernel: 4.4.0-47-genérico
Sistema operacional: Ubuntu 16.04.1 LTS
OSType: linux
Arquitetura: x86_64
CPUs: 7
Memória total: 11,73 GiB
Nome: webdevops.infogene.fr
ID: DGNM: G3MV : ZMMV: HY6K : UPLU: CMEV : VHCA: RVY3 : CRV7: FS5M: KMVQ: MQO5
Docker Root Dir: / var / lib / docker
Modo de depuração (cliente): falso
Modo de depuração (servidor): falso
Registro: https://index.docker.io/v1/
AVISO: Sem suporte para limite de troca
Registros inseguros:
127.0.0.0/8

Aqui também a saída do resultado de serverspec:

https://gist.github.com/mblaschke/21a521367a2a2b71301607482647a748

@mblaschke Eu examinei seus rastros (https://gist.github.com/tonistiigi/0fb0abfb068a89975c072b68e6ed07ce para melhor visualização). Não consigo encontrar nada suspeito lá. Todos os goroutines de longa execução são de uma cópia IO aberta, o que é normal se houver containers ou execs em execução, pois esses goroutines não possuem bloqueios. Pelos rastreamentos, eu esperaria que outros comandos como docker ps ou docker exec/stop não estivessem bloqueados em seu caso e o travamento que você viu foi apenas que você esperava que um determinado contêiner ou exec terminasse, mas não foi t. Isso pode estar relacionado ao próprio aplicativo estar pendurado em algo ou não ter nos enviado nenhum evento sobre o contêiner (cc @mlaventure).

Os avisos que você tem nos logs devem ser corrigidos com https://github.com/docker/containerd/pull/351 . Eles devem apenas causar spam e não ser nada sério. Como o log de depuração não está habilitado nos logs, não consigo ver se há algum comando suspeito enviado ao daemon. Não parece haver nenhum log significativo por minutos antes de você realizar o rastreamento de pilha.

O mesmo código funciona com o Docker 1.10.3, mas não depois do Docker 1.11.x. Os testes de serverespec estão falhando aleatoriamente com tempos limite.
Tenho a sensação de que isso está acontecendo com mais frequência quando executamos os testes em paralelo (por exemplo, executando 2 ou 4 testes em CPU de 4 núcleos) do que no modo serial, mas o resultado é o mesmo. Não há nenhum teste executado com êxito.
Com o Docker 1.11, todo o daemon do docker estava travado, desde o Docker 1.12 apenas o exec falha ou atinge o tempo limite.

@mblaschke Também dei uma olhada no rastreamento, realmente parece que o exec não está terminando seu

Qual programa exec você está executando? Ele bifurca novos processos com seu próprio id de sessão?

Estamos executando (docker exec) ip addr regularmente em todos os contêineres para encontrar seus endereços IP atribuídos por https://github.com/rancher/rancher , que infelizmente não fazem parte dos metadados do docker ( ainda)

Estamos vendo o problema de travamento regularmente em nosso cluster de produção.
Com ip addr não deveria haver muita mágica com processos rodando dentro de seu próprio id de sessão, certo?

@mlaventure
Estamos usando serverspec / rspec para teste e estão executando testes muito simples (verificações de arquivos, verificações de comandos simples, verificações simples de aplicativos). Na maioria das vezes, mesmo as verificações de permissão de arquivo simples estão falhando.

Os testes estão aqui (mas eles precisam de algumas configurações de ambiente para execução):
https://github.com/webdevops/Dockerfile/tree/develop/tests/serverspec

você pode tentar com nossa base de código:

1. make requirements por buscar todos os módulos python (pip) e ruby
2. bin/console docker:pull --threads=auto (buscar ~ 180 imagens do hub)
3. bin/console test:serverspec --threads=auto para executar todos os testes em modo paralelo ou bin/console test:serverspec em modo serial

@GameScripting Estou ficando confuso agora: sweat_smile:. Você está se referindo ao mesmo contexto do qual @mblaschke está sendo executado?

Se não, qual versão do docker você está usando?

E para responder à sua pergunta, não, é improvável que ip addr faça algo assim.

Qual imagem você está usando? Qual é o comando docker exec exato sendo usado?

Desculpe, não era minha intenção criar mais confusão.
Não estou me referindo ao mesmo contexto, não uso a suíte de testes a que ele estava se referindo. Eu queria fornecer mais contexto (esperançosamente útil) e / ou informações sobre o que estamos fazendo que pode causar o problema.

O principal problema para resolver esse bug é que ninguém ainda foi capaz de criar etapas reproduzíveis e estáveis ​​para acionar o travamento.

Parece que @mblaschke encontrou algo, então ele é capaz de acionar o bug de forma confiável.

Eu uso o CoreOS estável (1185.3.0) com Docker 1.11.2.
Eu executo um relógio com docker exec para meu contêiner Redis para verificar algumas variáveis. Pelo menos um dia o daemon Docker trava.

Mas eu encontrei uma solução alternativa até você encontrar uma solução. Eu uso o utilitário ctr de containerd (https://github.com/docker/containerd) para iniciar um processo dentro do contêiner em execução. Ele também pode ser usado para iniciar e parar contêineres. Acho que está integrado ao docker 1.11.2.
Infelizmente, há outro bug no CoreOS que relatei aqui: https://github.com/docker/containerd/issues/356#event -874038823 (eles o corrigiram desde então), então você precisa limpar / tmp regularmente, mas pelo menos ele tem está trabalhando para mim há uma semana na produção.

O próximo exemplo do docker exec:

docker exec -i container_name /bin/sh 'echo "Hello"'

pode ser traduzido para ctr:

/usr/bin/ctr --address=/run/docker/libcontainerd/docker-containerd.sock containers exec --id=${id_of_the_running_container} --pid=any_unique_process_name -a --cwd=/ /bin/sh -c 'echo "Hello"'

Portanto, você pode traduzir scripts temporariamente para ctr como uma solução alternativa.

@mblaschke Os comandos que você postou falharam para mim, mas não parecem falhas do docker. https://gist.github.com/tonistiigi/86badf5a41dff3fe53bd68d8e83e4ec4 Você poderia ativar os logs de depuração. A construção master também armazena mais dados de depuração sobre o daemon interno e permite rastrear o containerd também com os sinais sigusr1. Como estamos rastreando um processo travado, mesmo ps aux poderia ajudar.

@tonistiigi
Esqueci a lista negra alpina (problemas de compilação atualmente), então execute: bin/console test:serverspec --threads=auto --blacklist=:alpine

Desculpa :(

@mblaschke Ainda não parece um problema do docker. Ele está pendurado em docker exec <id> /usr/bin/php -i . Se eu rastrear a imagem que está sendo usada e iniciá-la manualmente, vejo que esta imagem não tem php real instalado:

root<strong i="8">@254424aecc57</strong>:/# php -v
HipHop VM 3.11.1 (rel)
Compiler: 3.11.1+dfsg-1ubuntu1
Repo schema: 2f678922fc70b326c82e56bedc2fc106c2faca61

E este HipHopVM não suporta -i mas apenas blocos.

@tonistiigi
Eu estava caçando esse bug nas últimas versões do Docker há muito tempo e não o vi em nossa suíte de teste ... Nós o consertamos, obrigado e desculpe / o

Eu pesquisei os logs de construção e encontrei uma falha de teste (problema aleatório, não nos testes hhvm) ao usar 1.12.3. Continuaremos a enfatizar o Docker e tentar encontrar o problema.

@ coolljt0725 Acabei de voltar ao trabalho e descobri que o Docker travou novamente. docker ps travou em uma sessão, e sudo service docker stop travou também. Abriu uma terceira sessão:

$ sudo lvs
  LV          VG     Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  docker-pool vg_ex  twi-aot--- 750.00g             63.49  7.88                            
$ sudo dmsetup udevcomplete_all
This operation will destroy all semaphores with keys that have a prefix 3405 (0xd4d).
Do you really want to continue? [y/n]: y
2 semaphores with keys prefixed by 3405 (0xd4d) destroyed. 0 skipped.

Assim que isso foi concluído, as outras duas sessões foram desbloqueadas. Eu estava verificando o espaço em disco porque isso tinha sido um problema antes, então foi o primeiro lugar que procurei. Os 2 semáforos podem ter sido as duas chamadas que recebi, mas havia muitas chamadas docker suspensas do meu servidor Jenkins, e é por isso que eu estava bisbilhotando ...

Um exemplo de saída travada depois que fiz a chamada dmsetup , a docker run começou dias atrás:

docker run -td -v /opt/Xilinx/:/opt/Xilinx/:ro -v /opt/Modelsim/:/opt/Modelsim/:ro -v /data/jenkins_workspace_modelsim/workspace/examples_hdl/APPLICATION/bias/HDL_PLATFORM/modelsim_pf/TARGET_OS/7:/build --name jenkins-examples_hdl-APPLICATION--bias--HDL_PLATFORM--modelsim_pf--TARGET_OS--7-546 jenkins/build:v3-C7 /bin/sleep 10m
docker: An error occurred trying to connect: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/create?name=jenkins-examples_hdl-APPLICATION--bias--HDL_PLATFORM--modelsim_pf--TARGET_OS--7-546: EOF.
See 'docker run --help'.

Docker 1.11.2 suspenso, rastreamento de pilha: https://gist.github.com/Calpicow/871621ba807d6eb9b18b91e8c2eb4eef

o rastreamento de @Calpicow parece estar preso no devicemapper. Mas não olha para o caso udev_wait. @ coolljt0725 @rhvgoyal

goroutine 488 [syscall, 10 minutes, locked to thread]:
github.com/docker/docker/pkg/devicemapper._C2func_dm_task_run(0x7fbffc010f80, 0x0, 0x0, 0x0)
    ??:0 +0x47
github.com/docker/docker/pkg/devicemapper.dmTaskRunFct(0x7fbffc010f80, 0xc800000001)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/pkg/devicemapper/devmapper_wrapper.go:96 +0x21
github.com/docker/docker/pkg/devicemapper.(*Task).run(0xc8200266d8, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engin
e/.gopath/src/github.com/docker/docker/pkg/devicemapper/devmapper.go:155 +0x37
github.com/docker/docker/pkg/devicemapper.SuspendDevice(0xc821b07380, 0x55, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/pkg/devicemapper/devmapper.go:627 +0x99
github.com/docker/docker/pkg/devicemapper.CreateSnapDevice(0xc821013f80, 0x25, 0x1a, 0xc821b07380, 0x55, 0x17, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/pkg/devicemapper/devmapper.go:759 +0x92
github.com/docker/docker/daemon/graphdriver/devmapper.(*DeviceSet).createRegisterSnapDevice(0xc8203be9c0, 0xc82184d1c0, 0x40, 0xc821a78f40, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/daemon/graphdriver/devmapper/deviceset.go:860 +0x557
github.com/docker/docker/daemon/graphdriver/devmapper.(*DeviceSet).AddDevice(0xc8203be9c0, 0xc82184d1c0, 0x40, 0xc8219c47c0, 0x40, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/daemon/graphdriver/devmapper/deviceset.go:1865 +0x81f
github.com/docker/docker/daemon/graphdriver/devmapper.(*Driver).Create(0xc8200ff770, 0xc82184d1c0, 0x40, 0xc8219c47c0, 0x40, 0x0, 0x0, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/daemon/graphdriver/devmapper/driver.go:124 +0x5f
github.com/docker/docker/daemon/graphdriver.(*NaiveDiffDriver).Create(0xc820363940, 0xc82184d1c0, 0x40, 0xc8219c47c0, 0x40, 0x0, 0x0, 0x0, 0x0)
    <autogenerated>:24 +0xaa
github.com/docker/docker/layer.(*layerStore).Register(0xc820363980, 0x7fc02faa3898, 0xc821a6ae00, 0xc821ace370, 0x47, 0x0, 0x0, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/layer/layer_store.go:266 +0x382
github.com/docker/docker/distribution/xfer.(*LayerDownloadManager).makeDownloadFunc.func1.1(0xc8210cd740, 0xc8210cd680, 0x7fc02fb6b758, 0xc820f422d0, 0xc820ee15c0, 0xc820ee1680, 0xc8210cd6e0, 0xc820e8e0b0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/distribut
ion/xfer/download.go:316 +0xc01
created by github.com/docker/docker/distribution/xfer.(*LayerDownloadManager).makeDownloadFunc.func1
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/distribution/xfer/download.go:341 +0x191

@Calpicow Você tem algum log de dmesg ? e você pode mostrar a saída de dmsetup status ?

Meu docker ps trava, mas outros comandos como info / restart / images funcionam perfeitamente.

Eu tenho um enorme despejo SIGUSR1 abaixo também (não cabia aqui). https://gist.github.com/ahmetalpbalkan/34bf40c02a78e319eaf5710acb15cf9a

• Versão do servidor docker: 1.11.2
• Driver de armazenamento: overlay
• Versão do kernel: 4.7.3-coreos-r3
• Sistema operacional: CoreOS 1185.5.0 (MoreOS)

Parece que tenho uma tonelada (tipo 700) desses goroutines:

...
goroutine 1149 [chan send, 1070 minutes]:
github.com/vishvananda/netlink.LinkSubscribe.func2(0xc821159d40, 0xc820fa4c60)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/vishvananda/netlink/link_linux.go:898 +0x2de
created by github.com/vishvananda/netlink.LinkSubscribe
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/vishvananda/netlink/link_linux.go:901 +0x107

goroutine 442 [chan send, 1129 minutes]:
github.com/vishvananda/netlink.LinkSubscribe.func2(0xc8211eb380, 0xc821095920)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/vishvananda/netlink/link_linux.go:898 +0x2de
created by github.com/vishvananda/netlink.LinkSubscribe
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/vishvananda/netlink/link_linux.go:901 +0x107
...

@ahmetalpbalkan Você parece bloqueado aguardando o retorno de um soquete netlink.
Este é um bug no kernel, mas 1.12.5 deve ter pelo menos um tempo limite neste soquete netlink.
Se eu tivesse que adivinhar, você teria algo em sua saída de dmesg como device_count = 1; waiting for <interface> to become free

@ cpuguy83 sim eu vi o https://github.com/coreos/bugs/issues/254 que parecia semelhante ao meu caso, porém não vejo aquelas mensagens de "espera" nos logs do kernel que a pessoa e você mencionou.

parece que o 1.12.5 ainda não atingiu nem mesmo o fluxo alfa do coreos. existe uma versão do kernel / docker que eu possa fazer o downgrade e fazê-la funcionar?

@ahmetalpbalkan Yay, para outro bug do kernel.
É por isso que introduzimos o tempo limite no soquete netlink ... provavelmente você não conseguirá iniciar / parar nenhum novo contêiner, mas pelo menos o Docker não será bloqueado.

É saber exatamente o que é o bug? O bug do kernel foi relatado no upstream? Ou existe mesmo uma versão do kernel onde esse bug foi corrigido?

O problema

Aqui está outro com Docker v1.12.3

despejar
dmesg
dmsetup

Syslog relevante:

Jan  6 01:41:19 ip-100-64-32-70 kernel: INFO: task kworker/u31:1:91 blocked for more than 120 seconds.
Jan  6 01:41:19 ip-100-64-32-70 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan  6 01:41:19 ip-100-64-32-70 kernel: kworker/u31:1   D ffff880201fc98e0     0    91      2 0x00000000
Jan  6 01:41:19 ip-100-64-32-70 kernel: Workqueue: kdmremove do_deferred_remove [dm_mod]
Jan  6 01:41:20 ip-100-64-32-70 kernel: ffff88020141bcf0 0000000000000046 ffff8802044ce780 ffff88020141bfd8
Jan  6 01:41:20 ip-100-64-32-70 kernel: ffff88020141bfd8 ffff88020141bfd8 ffff8802044ce780 ffff880201fc98d8
Jan  6 01:41:20 ip-100-64-32-70 kernel: ffff880201fc98dc ffff8802044ce780 00000000ffffffff ffff880201fc98e0
Jan  6 01:41:20 ip-100-64-32-70 kernel: Call Trace:
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff8163b959>] schedule_preempt_disabled+0x29/0x70
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff81639655>] __mutex_lock_slowpath+0xc5/0x1c0
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff81638abf>] mutex_lock+0x1f/0x2f
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffffa0392e9d>] __dm_destroy+0xad/0x340 [dm_mod]
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffffa03947e3>] dm_destroy+0x13/0x20 [dm_mod]
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffffa0398d6d>] dm_hash_remove_all+0x6d/0x130 [dm_mod]
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffffa039b50a>] dm_deferred_remove+0x1a/0x20 [dm_mod]
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffffa0390dae>] do_deferred_remove+0xe/0x10 [dm_mod]
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff8109d5fb>] process_one_work+0x17b/0x470
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff8109e3cb>] worker_thread+0x11b/0x400
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff8109e2b0>] ? rescuer_thread+0x400/0x400
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff810a5aef>] kthread+0xcf/0xe0
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff810a5a20>] ? kthread_create_on_node+0x140/0x140
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff81645818>] ret_from_fork+0x58/0x90
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff810a5a20>] ? kthread_create_on_node+0x140/0x140
Jan  6 01:41:20 ip-100-64-32-70 kernel: INFO: task dockerd:31587 blocked for more than 120 seconds.
Jan  6 01:41:20 ip-100-64-32-70 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan  6 01:41:20 ip-100-64-32-70 kernel: dockerd         D 0000000000000000     0 31587      1 0x00000080
Jan  6 01:41:20 ip-100-64-32-70 kernel: ffff8800e768fab0 0000000000000086 ffff880034215c00 ffff8800e768ffd8
Jan  6 01:41:20 ip-100-64-32-70 kernel: ffff8800e768ffd8 ffff8800e768ffd8 ffff880034215c00 ffff8800e768fbf0
Jan  6 01:41:20 ip-100-64-32-70 kernel: ffff8800e768fbf8 7fffffffffffffff ffff880034215c00 0000000000000000
Jan  6 01:41:20 ip-100-64-32-70 kernel: Call Trace:
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff8163a879>] schedule+0x29/0x70
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff81638569>] schedule_timeout+0x209/0x2d0
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff8108e4cd>] ? mod_timer+0x11d/0x240
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff8163ac46>] wait_for_completion+0x116/0x170
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff810b8c10>] ? wake_up_state+0x20/0x20
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff810ab676>] __synchronize_srcu+0x106/0x1a0
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff810ab190>] ? call_srcu+0x70/0x70
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff81219e3f>] ? __sync_blockdev+0x1f/0x40
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff810ab72d>] synchronize_srcu+0x1d/0x20
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffffa039318d>] __dm_suspend+0x5d/0x220 [dm_mod]
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffffa0394c9a>] dm_suspend+0xca/0xf0 [dm_mod]
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffffa0399fe0>] ? table_load+0x380/0x380 [dm_mod]
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffffa039a174>] dev_suspend+0x194/0x250 [dm_mod]
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffffa0399fe0>] ? table_load+0x380/0x380 [dm_mod]
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffffa039aa25>] ctl_ioctl+0x255/0x500 [dm_mod]
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff8112482d>] ? call_rcu_sched+0x1d/0x20
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffffa039ace3>] dm_ctl_ioctl+0x13/0x20 [dm_mod]
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff811f1e75>] do_vfs_ioctl+0x2e5/0x4c0
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff8128bbee>] ? file_has_perm+0xae/0xc0
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff81640d01>] ? __do_page_fault+0xb1/0x450
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff811f20f1>] SyS_ioctl+0xa1/0xc0
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff816458c9>] system_call_fastpath+0x16/0x1b

@Calpicow Obrigado, o seu parece que o Devicemapper travou.

github.com/docker/docker/pkg/devicemapper._C2func_dm_task_run(0x7fd3a40231b0, 0x7fd300000000, 0x0, 0x0)
    ??:0 +0x4c
github.com/docker/docker/pkg/devicemapper.dmTaskRunFct(0x7fd3a40231b0, 0xc821a91620)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/pkg/devicemapper/devmapper_wrapper.go:96 +0x75
github.com/docker/docker/pkg/devicemapper.(*Task).run(0xc820345838, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/pkg/devicemapper/devmapper.go:155 +0x37
github.com/docker/docker/pkg/devicemapper.SuspendDevice(0xc8219c8600, 0x5a, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/pkg/devicemapper/devmapper.go:648 +0x99
github.com/docker/docker/pkg/devicemapper.CreateSnapDevice(0xc821a915f0, 0x25, 0x21, 0xc8219c8600, 0x5a, 0x1f, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/pkg/devicemapper/devmapper.go:780 +0x92
github.com/docker/docker/daemon/graphdriver/devmapper.(*DeviceSet).createRegisterSnapDevice(0xc820433040, 0xc821084080, 0x40, 0xc8210842c0, 0x140000000, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/daemon/graphdriver/devmapper/deviceset.go:861 +0x550
github.com/docker/docker/daemon/graphdriver/devmapper.(*DeviceSet).AddDevice(0xc820433040, 0xc821084080, 0x40, 0xc82025b5e0, 0x45, 0x0, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/daemon/graphdriver/devmapper/deviceset.go:1887 +0xa5c
github.com/docker/docker/daemon/graphdriver/devmapper.(*Driver).Create(0xc82036af00, 0xc821084080, 0x40, 0xc82025b5e0, 0x45, 0x0, 0x0, 0x0, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/daemon/graphdriver/devmapper/driver.go:131 +0x6f
github.com/docker/docker/daemon/graphdriver/devmapper.(*Driver).CreateReadWrite(0xc82036af00, 0xc821084080, 0x40, 0xc82025b5e0, 0x45, 0x0, 0x0, 0x0, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/daemon/graphdriver/devmapper/driver.go:126 +0x86
github.com/docker/docker/daemon/graphdriver.(*NaiveDiffDriver).CreateReadWrite(0xc82021c500, 0xc821084080, 0x40, 0xc82025b5e0, 0x45, 0x0, 0x0, 0x0, 0x0, 0x0)
    <autogenerated>:28 +0xbe
github.com/docker/docker/layer.(*layerStore).CreateRWLayer(0xc82021c580, 0xc82154f980, 0x40, 0xc82025b2c0, 0x47, 0x0, 0x0, 0xc820981380, 0x0, 0x0, ...)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/layer/layer_store.go:476 +0x5a9
github.com/docker/docker/daemon.(*Daemon).setRWLayer(0xc820432ea0, 0xc8216d12c0, 0x0, 0x0)

Você pode abrir uma edição separada com todos os detalhes?
Obrigado!

30003