Estou enfrentando o mesmo problema. Estou investigando.

Estamos enfrentando o mesmo problema também.

Sim, é um problema no docker 1.9. Fiz o downgrade para 1.8.3 e todos os problemas foram resolvidos. Agora estou investigando uma solução alternativa. vai postar aqui! Tks

Estou tendo o mesmo problema com o docker 1.9.1a

Eu tenho o docker 1.8.3, então talvez o processo de instalação de uma versão diferente do docker resolva a situação. @bsao.

tendo este mesmo problema com docker versão 1.9.1, compilar a34a1d5

Você está vendo isso apenas no boot2docker?

Não consigo fazer repo em um Ubuntu de estoque com aufs ou na minha máquina. deixe-me tentar com boot2docker para ver se consigo repo lá.

+1 no Docker 1.9.1 para ubuntu: 14.10 usando OSX

Este é um problema que começou a aparecer depois que eu liguei a VPN para o trabalho. Mesmo depois que desliguei a VPN e reiniciei a máquina docker no OSX, ele continuou a ter esse problema. Reinstalei o Docker 1.9.1 e, em seguida, 1.8.3, ainda vendo o problema. Impede que eu use a maioria, senão todas as minhas janelas de encaixe no Mac.

+1 no Docker 1.9.1 para ubuntu 12.04 usando OS X 10.11

Os desenvolvedores em meu escritório também descobriram isso por acidente.

Esta versão / compilação funcionou : Docker versão 1.9.0, compilação 76d6bc9

Esta versão / build pendurados: Docker versão 1.9.1, a34a1d5 construção

@crosbymichael Infelizmente não tentei em nenhum outro ambiente além do Boot2Docker.

Alguém com conhecimento de git-bissecting e docker pode usar os IDs de compilação fornecidos por @ chico1198!

Eu tive o mesmo problema com o 1.9.1 no OSX El Capitan, o downgrade para 1.9.0 não ajudou.

O mesmo problema aqui no OSX 10.9.3 com:
Docker versão 1.9.1, compilação a34a1d5
Docker versão 1.9.0, compilação 76d6bc9

@crosbymichael Eu ps auxf , isto é o que eu vi:

root      1290  0.4  1.8 1346656 75692 ?       Sl   Nov27   4:53 /usr/local/bin/docker daemon -D -g /var/lib/docker -H unix:// -H tcp://0.0.0.0:2376 [...]
root      8556  0.0  0.0      0     0 ?        Ss   05:12   0:00  \_ [sh]
root     24221 99.8  0.0      0     0 ?        Zl   05:33  64:17  |   \_ [java] <defunct>
root     24657  0.0  0.0      0     0 ?        Ss   06:07   0:00  \_ [sh]
root      6174 79.6  0.0      0     0 ?        Zl   06:22  12:33      \_ [java] <defunct>
root      7295 49.3  0.0      0     0 ?        Zl   06:32   2:49      \_ [java] <defunct>

+1 com docker 1.9.1 no OSX 10.11 com tentativa de construir imagem do ubuntu 14.04

+1
use DockerToolbox-1.9.1a.pkg

docker version                                                                                      2 master?
Client:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.3
 Git commit:   a34a1d5
 Built:        Fri Nov 20 17:56:04 UTC 2015
 OS/Arch:      darwin/amd64

Server:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.3
 Git commit:   a34a1d5
 Built:        Fri Nov 20 17:56:04 UTC 2015
 OS/Arch:      linux/amd64

Fazer downgrade para o Docker 1.8.3 é minha solução temporária. Aqui está target que uso no meu Makefile .

downgrade-docker:
  docker-machine ssh $(DOCKER_MACHINE_NAME) sudo /etc/init.d/docker stop
  docker-machine ssh $(DOCKER_MACHINE_NAME) "while sudo /etc/init.d/docker status ; do sleep 1; done"
  docker-machine ssh $(DOCKER_MACHINE_NAME) "sudo curl 'https://get.docker.com/builds/Linux/x86_64/docker-1.8.3' -o /usr/local/bin/docker-1.8.3"
  docker-machine ssh $(DOCKER_MACHINE_NAME) "sudo ln -sf /usr/local/bin/docker-1.8.3 /usr/local/bin/docker"
  # FIXME: Starting machine is not enough; always fails with message like "Need TLS certs for 127.0.0.1,10.0.2.15,192.168.99.100"
  #docker-machine ssh $(DOCKER_MACHINE_NAME) sudo /etc/init.d/docker start
  docker-machine stop $(DOCKER_MACHINE_NAME) 
  docker-machine start $(DOCKER_MACHINE_NAME) 

Não consegui reproduzir isso. Ele sempre trava em "configurar certificados"? Você tentou enviar um ^D para fechar algum cano? Você também pode tentar enviar um SIGUSR1 para o daemon e colar o rastreamento de pilha aqui quando ele travar?

+1 com docker 1.9.1 no OS X 10.10

Tentei fazer o downgrade para 1.8.3 usando o Makefile de @osterman e também tive problemas com a chave SSH:

ip-10-100-0-211:docker-dev leaf$ docker-machine start default
(default) OUT | Starting VM...
Too many retries waiting for SSH to be available.  Last error: Maximum number of retries (60) exceeded

Testei fazendo diferentes instalações openjdk dentro do debian: jessie e ubuntu
OSX 10.11.1, boot2docker 1.9.1: trava
OSX 10.11.1, boot2docker 1.9.0: funciona
Ubuntu 14.04 com docker 1.9.1: funciona

O boot2docker vms foi criado com:
docker-machine create -d virtualbox --virtualbox-boot2docker-url = https://github.com/boot2docker/boot2docker/releases/download/v1.9.0/boot2docker.iso
e
docker-machine create -d virtualbox --virtualbox-boot2docker-url = https://github.com/boot2docker/boot2docker/releases/download/v1.9.1/boot2docker.iso

No Ubuntu 14.04, o docker foi instalado seguindo a documentação em https://docs.docker.com/engine/installation/ubuntulinux/

+1, executando docker 1.9.1 build a34a1d5 no OSX Yosemite 10.10.5.

Eu não consigo reproduzir isso.

Mesmo problema aqui.
Existe alguma maneira de fazer o downgrade para uma versão anterior do Windows?

Eu mesma encontrei.
https://github.com/docker/docker/releases

+1, docker 1.9.1 @ El Capitan

+1, Docker 1.9.1 no OS X 10.11.1

+1, Docker 1.9.1a, OS X 10.10.5

+1, Docker 1.9.1 build a34a1d5, Windows 10

+1, Docker 1.9.1 build a34a1d5, OS X 10.11.1, Docker-Machine 0.5.1 build 7e8e38e

+1

O mesmo na máquina Docker no OSX 10.11.1
Docker versão 1.9.1, compilação a34a1d5
docker-machine versão 0.5.1 (HEAD)

Consigo reproduzir isso na docker-machine, OS X 10.10.5, então pode ser algo relacionado ao boot2docker. docker top também me dá <defunct> para um processo java;

docker top dreamy_sammet                                                                  Tue Dec  1 15:58:47 2015
UID                 PID                 PPID                C                   STIME               TTY                 TIME                CMD
root                2538                1023                0                   14:44               ?                   00:00:00            /bin/sh -c apt-get update && apt-get install -y -qq --no-install-recommends build-essential wget curl unzip python python-dev php5-mysql php5-cli php5-cgi openjdk-7-jre-headless openssh-client python-openssl && apt-get clean
root                2566                2538                1                   14:44               ?                   00:00:16            apt-get install -y -qq --no-install-recommends build-essential wget curl unzip python python-dev php5-mysql php5-cli php5-cgi openjdk-7-jre-headless openssh-client python-openssl
root                4830                2566                0                   14:46               pts/0               00:00:00            /usr/bin/dpkg --status-fd 14 --configure libgdbm3:amd64 libjson-c2:amd64 libbsd0:amd64 libedit2:amd64 libkeyutils1:amd64 libkrb5support0:amd64 libk5crypto3:amd64 libkrb5-3:amd64 libgssapi-krb5-2:amd64 libidn11:amd64 libsasl2-modules-db:amd64 libsasl2-2:amd64 libldap-2.4-2:amd64 libmagic1:amd64 libsqlite3-0:amd64 libwrap0:amd64 libxml2:amd64 perl-modules:all perl:amd64 mime-support:all libexpat1:amd64 libpython2.7-stdlib:amd64 python2.7:amd64 libpython-stdlib:amd64 python:amd64 libasan1:amd64 libasyncns0:amd64 libatomic1:amd64 libavahi-common-data:amd64 libavahi-common3:amd64 libdbus-1-3:amd64 libavahi-client3:amd64 libcilkrts5:amd64 libisl10:amd64 libcloog-isl4:amd64 libcups2:amd64 librtmp1:amd64 libssh2-1:amd64 libcurl3:amd64 libogg0:amd64 libflac8:amd64 libpng12-0:amd64 libfreetype6:amd64 ucf:all fonts-dejavu-core:all fontconfig-config:all libfontconfig1:amd64 libglib2.0-0:amd64 libgomp1:amd64 x11-common:all libice6:amd64 libicu52:amd64 libitm1:amd64 liblcms2-2:amd64 liblsan0:amd64 libmpfr4:amd64 mysql-common:all libmysqlclient18:amd64 libnspr4:amd64 libnss3:amd64 libonig2:amd64 libpcsclite1:amd64 libsm6:amd64 libvorbis0a:amd64 libvorbisenc2:amd64 libsndfile1:amd64 libxau6:amd64 libxdmcp6:amd64 libxcb1:amd64 libx11-data:all libx11-6:amd64 libx11-xcb1:amd64 libxext6:amd64 libxi6:amd64 libxtst6:amd64 libpulse0:amd64 libpython2.7:amd64 libc-dev-bin:amd64 linux-libc-dev:amd64 libc6-dev:amd64 libexpat1-dev:amd64 libpython2.7-dev:amd64 libquadmath0:amd64 libsctp1:amd64 libtsan0:amd64 libubsan0:amd64 tzdata-java:all java-common:all libjpeg62-turbo:amd64 ca-certificates-java:all openjdk-7-jre-headless:amd64 libmpc3:amd64 libpsl0:amd64 wget:amd64 bzip2:amd64 libperl4-corelibs-perl:all lsof:amd64 openssh-client:amd64 patch:amd64 xz-utils:amd64 binutils:amd64 cpp-4.9:amd64 cpp:amd64 libgcc-4.9-dev:amd64 gcc-4.9:amd64 gcc:amd64 libstdc++-4.9-dev:amd64 g++-4.9:amd64 g++:amd64 make:amd64 libtimedate-perl:all libdpkg-perl:all dpkg-dev:all build-essential:amd64 curl:amd64 libpython-dev:amd64 libqdbm14:amd64 psmisc:amd64 php5-common:amd64 php5-json:amd64 php5-cli:amd64 php5-cgi:amd64 php5-mysql:amd64 python-ply:all python-pycparser:all python-cffi:amd64 python-pkg-resources:all python-six:all python-cryptography:amd64 python2.7-dev:amd64 python-dev:amd64 python-openssl:all unzip:amd64
root                6711                4830                0                   14:46               pts/0               00:00:00            /bin/bash /var/lib/dpkg/info/ca-certificates-java.postinst configure
root                6725                6711                97                  14:46               pts/0               00:12:25            [java] <defunct>

/ cc @tianon @nathanleclaire @jeffdm talvez algum de vocês tenha uma ideia onde procurar ou o que depurar, não consegui realmente encontrar algo

Quanta RAM a sua VM tem? Pode ser OOM, visto que se parece com o
processo morre inesperadamente. : desapontado:

Parece que a memória não é o problema, mas o processo <defunct> consome 100% da CPU;

CONTAINER           CPU %               MEM USAGE / LIMIT   MEM %               NET I/O               BLOCK I/O
d263da116bfd        99.51%              689.3 MB / 2.1 GB   32.82%              157.9 MB / 2.754 MB   25.15 MB / 130.4 MB

O contêiner parece estar travado também, e eu tive que reiniciar a VM para matá-lo

+1 Docker versão 1.9.1, compilação a34a1d5, Win 7.

Já tive problemas semelhantes que acabaram sendo OOM, embora o comando stats mostre a memória disponível para o contêiner. O problema aconteceu logo depois que o gerenciador de tarefas mostrou 0 de memória física livre, enquanto as estatísticas continuaram a mostrar <100%.

O estranho é que o processo continuou rodando, então não foi morto. Posso tentar novamente com um -m, no entanto, é estranho que isso aconteça no 1.9.x, mas (seguindo esta discussão) não no 1.8. Além disso, executar o mesmo em um droplet DigitalOcean de 1 GB (também 1.9.1) teve sucesso. Talvez aquele use swap, deve verificar se

Na verdade, continuou acontecendo comigo depois que desinstalei o 1.9.1 e instalei o 1.8.3. Parece que a desinstalação não foi muito completa no Mac porque o acionamento do shell ocorreu sem demora no 1.8.3, ao contrário de uma primeira execução normal, onde ele configura as chaves ssh e outras coisas.

_USER POLL_

_A melhor maneira de ser notificado quando há mudanças nesta discussão é clicando no botão Inscrever-se no canto superior direito._

As pessoas listadas abaixo apreciaram sua discussão significativa com um +1 aleatório:

@mattes

31 participantes neste assunto e contando.

@ bean5 por favor, mantenha seus comentários construtivos

@thaJeztah Eu não tive a concluí que

Consigo duplicar esse problema em minha configuração (usando a máquina Docker no Mac).

Aqui estão minhas descobertas até agora.

Conforme observado por outros participantes, a maneira mais simples de duplicar isso foi usar o boot2docker 1.9.1 ISO com AUFS. Este Dockerfile deve reproduzir minimamente o problema com bastante rapidez:

FROM debian:jessie

ENV DEBIAN_FRONTEND noninteractive
RUN apt-get update && apt-get install -y --no-install-recommends openjdk-7-jre-headless

Olhando para dmesg , vejo alguns erros AUFS após tentar tal compilação, mas não estou 100% certo de que eles estão relacionados:

docker<strong i="13">@default</strong>:~$ dmesg | tail
aufs au_opts_verify:1597:docker[14186]: dirperm1 breaks the protection by the permission bits on the lower branch
aufs au_opts_verify:1597:docker[14186]: dirperm1 breaks the protection by the permission bits on the lower branch
aufs au_opts_verify:1597:docker[14186]: dirperm1 breaks the protection by the permission bits on the lower branch
device veth955cc15 entered promiscuous mode
IPv6: ADDRCONF(NETDEV_UP): veth955cc15: link is not ready
eth0: renamed from vethc63e038
IPv6: ADDRCONF(NETDEV_CHANGE): veth955cc15: link becomes ready
docker0: port 2(veth955cc15) entered forwarding state
docker0: port 2(veth955cc15) entered forwarding state
docker0: port 2(veth955cc15) entered forwarding state

Se eu criar uma máquina Docker 1.9.1 que usa overlay como o driver de armazenamento:

$ docker-machine create -d virtualbox --engine-storage-driver overlay overlay

O processo NÃO travou e esta linha foi executada com sucesso! Parece que AUFS e / ou kernel é o problema.

boot2docker / boot2docker _did_ bump ambas as versões do kernel e o commit AUFS para a versão 1.9.1, então esses são fatores que precisam ser descartados ou investigados posteriormente:

• https://github.com/boot2docker/boot2docker/compare/v1.9.0...master#diff -3254677a7917c6c01f55212f86c57fbfR23
• https://github.com/boot2docker/boot2docker/compare/v1.9.0...master#diff -3254677a7917c6c01f55212f86c57fbfR32

Atualmente tentando 1.9.0 ISO com um binário 1.9.1 para ver se a área de superfície da área de bug potencial pode ser reduzida ainda mais.

O Dockerfile irá construir bem e não travar em um boot2docker 1.9.0 ISO com um binário Docker 1.9.1. O problema parece não estar no Docker 1.9.1, mas sim no ambiente no qual ele está sendo executado.

Estou usando a versão 1.9.1 sem problemas no aufs, mas tenho significativamente mais cpu / ram / armazenamento do que a configuração padrão da máquina.

Eu apenas tentei aumentar a memória para 4 GB para minha VM, mas ainda consigo reproduzir

@ cpuguy83 AUFS no boot2docker 1.9.1?

Conforme observado acima, o b2d agrupa uma versão muito específica do AUFS.

Sim

Containers: 13
Images: 191
Server Version: 1.9.1
Storage Driver: aufs
 Root Dir: /mnt/sda1/var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 221
 Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.1.13-boot2docker
Operating System: Boot2Docker 1.9.1 (TCL 6.4.1); master : cef800b - Fri Nov 20 19:33:59 UTC 2015
CPUs: 1
Total Memory: 3.859 GiB
Name: default
ID: XMQH:4YAW:ZDSA:OWC7:GAPC:US5P:YQ4M:SVMQ:VXNL:RRZC:YNHT:ZBHE
Debug mode (server): true
 File Descriptors: 12
 Goroutines: 19
 System Time: 2015-12-01T23:05:28.760107918Z
 EventsListeners: 0
 Init SHA1:
 Init Path: /usr/local/bin/docker
 Docker Root Dir: /mnt/sda1/var/lib/docker
Labels:
 provider=virtualbox

Também vejo alguns processos java se tornando extintos em um contêiner. Consigo reproduzir esse problema com as seguintes etapas
execute o contêiner:

docker run --rm -it myJavaContainerFromCentos7 bash

crie Foo.java com o seguinte:

class Foo {
    public static void main (String[] a) {
        System.out.println("hello world");
    }
}

compilar e executá-lo resulta em um processo java extinto, com 1 núcleo usando 100% cpu:
javac Foo.java && java Foo

entretanto ... se um System.exit(0); for adicionado após o println, tudo estará bem:

class Foo {
    public static void main (String[] a) {
        System.out.println("hello world");
        System.exit(0);  // clean exit, no hang
    }
}

informação da versão:
osx 10.10.3
docker 1.9.1
boot2docker versão 1.9.1 uname -a é "linux ci 4.1.13-boot2docker"
numproc = 1

saída strace com System.exit (0);

open("/usr/java/jdk1.7.0_75/jre/lib/amd64/jvm.cfg", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=677, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f27b1dab000
read(3, "# Copyright (c) 2003, Oracle and"..., 4096) = 677
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0x7f27b1dab000, 4096)            = 0
stat("/usr/java/jdk1.7.0_75/jre/lib/amd64/server/libjvm.so", {st_mode=S_IFREG|0755, st_size=15224066, ...}) = 0
futex(0x7f27b17580d0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
open("/usr/java/jdk1.7.0_75/jre/lib/amd64/server/libjvm.so", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240\245\36\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=15224066, ...}) = 0
mmap(NULL, 15167976, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f27b031c000
mprotect(0x7f27b0e8f000, 2097152, PROT_NONE) = 0
mmap(0x7f27b108f000, 802816, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xb73000) = 0x7f27b108f000
mmap(0x7f27b1153000, 262632, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f27b1153000
close(3)                                = 0
open("/usr/java/jdk1.7.0_75/bin/../lib/amd64/jli/libm.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=11922, ...}) = 0
mmap(NULL, 11922, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f27b1da9000
close(3)                                = 0
open("/lib64/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260T\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1141552, ...}) = 0
mmap(NULL, 3150168, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f27b001a000
mprotect(0x7f27b011b000, 2093056, PROT_NONE) = 0
mmap(0x7f27b031a000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x100000) = 0x7f27b031a000
close(3)                                = 0
mprotect(0x7f27b031a000, 4096, PROT_READ) = 0
munmap(0x7f27b1da9000, 11922)           = 0
mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f27b1ca4000
mprotect(0x7f27b1ca4000, 4096, PROT_NONE) = 0
clone(child_stack=0x7f27b1da3fb0,                                                                                                    flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,  parent_tidptr=0x7f27b1da49d0, tls=0x7f27b1da4700, child_tidptr=0x7f27b1da49d0) = 118
futex(0x7f27b1da49d0, FUTEX_WAIT, 118, NULLhellowerld
 <unfinished ...>
 +++ exited with 0 +++

saída strace _without_ System.exit (0);

open("/usr/java/jdk1.7.0_75/jre/lib/amd64/jvm.cfg", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=677, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fac9a490000
read(3, "# Copyright (c) 2003, Oracle and"..., 4096) = 677
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0x7fac9a490000, 4096)            = 0
stat("/usr/java/jdk1.7.0_75/jre/lib/amd64/server/libjvm.so", {st_mode=S_IFREG|0755, st_size=15224066, ...}) = 0
futex(0x7fac99e3d0d0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
open("/usr/java/jdk1.7.0_75/jre/lib/amd64/server/libjvm.so", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240\245\36\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=15224066, ...}) = 0
mmap(NULL, 15167976, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fac98a01000
mprotect(0x7fac99574000, 2097152, PROT_NONE) = 0
mmap(0x7fac99774000, 802816, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xb73000) = 0x7fac99774000
mmap(0x7fac99838000, 262632, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fac99838000
close(3)                                = 0
open("/usr/java/jdk1.7.0_75/bin/../lib/amd64/jli/libm.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=11922, ...}) = 0
mmap(NULL, 11922, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fac9a48e000
close(3)                                = 0
open("/lib64/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260T\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1141552, ...}) = 0
mmap(NULL, 3150168, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fac986ff000
mprotect(0x7fac98800000, 2093056, PROT_NONE) = 0
mmap(0x7fac989ff000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x100000) = 0x7fac989ff000
close(3)                                = 0
mprotect(0x7fac989ff000, 4096, PROT_READ) = 0
munmap(0x7fac9a48e000, 11922)           = 0
mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7fac9a389000
mprotect(0x7fac9a389000, 4096, PROT_NONE) = 0
clone(child_stack=0x7fac9a488fb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7fac9a4899d0, tls=0x7fac9a489700, child_tidptr=0x7fac9a4899d0) = 142
futex(0x7fac9a4899d0, FUTEX_WAIT, 142, NULLhellowerld
) = 0
exit_group(0)                           = ?

o processo agora está travado, mas você pode entrar no contêiner:

docker exec -it myContainer bash

e veja o seguinte:

ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 23:47 ?        00:00:00 bash
root       138     1  0 23:51 ?        00:00:00 strace java Foo
root       141   138 24 23:51 ?        00:01:21 [java] <defunct>
root       151     0  1 23:57 ?        00:00:00 bash
root       167   151  0 23:57 ?        00:00:00 ps -ef

uma olhada rápida nas estatísticas:

CONTAINER           CPU %               MEM USAGE / LIMIT     MEM %               NET I/O               BLOCK I/O
myContainer                  24.72%              64.18 MB / 8.365 GB   0.77%               11.09 MB / 202.6 kB   8.192 kB / 14.99

Tudo funciona bem no 1.8.3.

+1, Docker versão 1.9.1, build a34a1d5, OS X

+1, Docker versão 1.9.1, build a34a1d5, OS X 10.10.5, Docker Machine Version: 0.5.1 (HEAD)

+1

Docker versão 1.9.1, compilação a34a1d5 , OS X 10.11.1 (15B42)

+1

Docker versão 1.9.1, compilação a34a1d5 no OS X 10.11.1

Esse problema é realmente muito bizarro. Se eu strace o comando falho apt-get , o final da saída é:

stat("/etc/apt/sources.list", {st_mode=S_IFREG|0644, st_size=161, ...}) = 0
open("/etc/apt/sources.list", O_RDONLY) = 5
read(5, "deb http://httpredir.debian.org/"..., 8191) = 161
pipe([6, 7])                            = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fc6fc88aa10) = 14
close(7)                                = 0
fcntl(6, F_GETFL)                       = 0 (flags O_RDONLY)
fstat(6, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc6fc892000
lseek(6, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
read(6, Process 14 attached
 <unfinished ...>
[pid    14] rt_sigaction(SIGPIPE, {SIG_DFL, [PIPE], SA_RESTORER|SA_RESTART, 0x7fc6fb531180}, {SIG_IGN, [PIPE], SA_RESTORER|SA_RESTART, 0x7fc6fb531180}, 8) = 0
[pid    14] rt_sigaction(SIGQUIT, {SIG_DFL, [QUIT], SA_RESTORER|SA_RESTART, 0x7fc6fb531180}, {SIG_DFL, [], 0}, 8) = 0
[pid    14] rt_sigaction(SIGINT, {SIG_DFL, [INT], SA_RESTORER|SA_RESTART, 0x7fc6fb531180}, {SIG_DFL, [], 0}, 8) = 0
[pid    14] rt_sigaction(SIGWINCH, {SIG_DFL, [WINCH], SA_RESTORER|SA_RESTART, 0x7fc6fb531180}, {0x7fc6fc0e5750, [WINCH], SA_RESTORER|SA_RESTART, 0x7fc6fb531180}, 8) = 0
[pid    14] rt_sigaction(SIGCONT, {SIG_DFL, [CONT], SA_RESTORER|SA_RESTART, 0x7fc6fb531180}, {SIG_DFL, [], 0}, 8) = 0
[pid    14] rt_sigaction(SIGTSTP, {SIG_DFL, [TSTP], SA_RESTORER|SA_RESTART, 0x7fc6fb531180}, {SIG_DFL, [], 0}, 8) = 0
[pid    14] getrlimit(RLIMIT_NOFILE, {rlim_cur=1024*1024, rlim_max=1024*1024}) = 0
[pid    14] fcntl(3, F_SETFD, FD_CLOEXEC) = 0
[pid    14] getrlimit(RLIMIT_NOFILE, {rlim_cur=1024*1024, rlim_max=1024*1024}) = 0
[pid    14] fcntl(4, F_SETFD, FD_CLOEXEC) = 0
[pid    14] getrlimit(RLIMIT_NOFILE, {rlim_cur=1024*1024, rlim_max=1024*1024}) = 0
[pid    14] fcntl(5, F_SETFD, FD_CLOEXEC) = 0
[pid    14] getrlimit(RLIMIT_NOFILE, {rlim_cur=1024*1024, rlim_max=1024*1024}) = 0
[pid    14] fcntl(6, F_SETFD, FD_CLOEXEC) = 0
[pid    14] getrlimit(RLIMIT_NOFILE, {rlim_cur=1024*1024, rlim_max=1024*1024}) = 0
[pid    14] fcntl(7, F_SETFD, FD_CLOEXEC) = 0
[pid    14] getrlimit(RLIMIT_NOFILE, {rlim_cur=1024*1024, rlim_max=1024*1024}) = 0
[pid    14] fcntl(8, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad file descriptor)
[pid    14] getrlimit(RLIMIT_NOFILE, {rlim_cur=1024*1024, rlim_max=1024*1024}) = 0
[pid    14] fcntl(9, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad file descriptor)
[pid    14] getrlimit(RLIMIT_NOFILE, {rlim_cur=1024*1024, rlim_max=1024*1024}) = 0
[pid    14] fcntl(10, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad file descriptor)
[pid    14] getrlimit(RLIMIT_NOFILE, {rlim_cur=1024*1024, rlim_max=1024*1024}) = 0
[pid    14] fcntl(11, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad file descriptor)

Onde esses erros (descritor de arquivo ruim) continuam em loop indefinidamente.

RLIMIT_NOFILE
              Specifies a value one greater than the maximum file descriptor
              number that can be opened by this process.  Attempts (open(2),
              pipe(2), dup(2), etc.)  to exceed this limit yield the error
              EMFILE.  (Historically, this limit was named RLIMIT_OFILE on
              BSD.)

SIGPIPE está falhando? isso pode corresponder ao meu post anterior, onde vi java "hello world" causando processos zumbis sem um "System.exit (0);" - ou talvez isso seja um problema completamente diferente. desculpe pelo barulho.

o que acontece com sua CPU durante o loop indefinidamente?

@andrewgdavis está em 100%

java "hello world" causando processos zumbis sem um "System.exit (0);"

Isso certamente soa semelhante ao problema encontrado aqui.

Eu posso definitivamente confirmar o problema do b2d (até fiz a bissetriz para rastreá-lo mais positivamente para o aumento do kernel 4.1.13). Também posso reproduzir em 4.2.6 com b2d.

Como um problema adicional, meu host Gentoo está atualmente em patchs 4.1.13 + AUFS também, e estou vendo exatamente o mesmo problema, então definitivamente descartamos qualquer coisa específica do b2d.

Acho que pode valer a pena vasculhar os commits entre 4.1.12 e 4.1.13 para ver se algo que possa estar relacionado salta.

(ou seja, https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.1.13)

Sim, algo quebra no kernel 4.1.12 => 4.1.13. Posso confirmar que criar um ISO boot2docker para o primeiro não desarma esse bug, mas o anterior sim.

Portanto, não está especificamente relacionado ao boot2docker, mas parece estar relacionado à versão do kernel interagindo com o AUFS.

ou talvez a maneira específica como o driver AUFS no Docker interage com o
kernel mais novo - TBD, provavelmente com uma bissetriz git estável no Linux entre 4.1.12
e 4.1.13: choro:

eu tenho uma teoria do cabelo do cérebro ...

http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?h=v4.1.13&id=6c0da28df5dac10672efe955eb89051a850008eb

o commit acima faz uma mudança em filemap.c para generic_perform_write (struct arquivo * arquivo, struct iov_iter * i, loff_t pos)

abaixo está o pedaço de código que eu pessoalmente quero testar porque o comentário descreve as condições de corrida de deadlock e livelock e vejo a cpu atrelada a 100%. mas isso sou apenas eu e minha esteira de conclusões precipitadas.

4.1.13 mm / filemap.c # l_2448

...
 2448 again:
 2449       /*
 2450        * Bring in the user page that we will copy from _first_.
 2451        * Otherwise there's a nasty deadlock on copying from the
 2452        * same page as we're writing to, without it being marked
 2453        * up-to-date.
 2454        *
 2455        * Not only is this an optimisation, but it is also required
 2456        * to check that the address is actually valid, when atomic
 2457        * usercopies are used, below.
 2458        */
 2459       if (unlikely(iov_iter_fault_in_readable(i, bytes))) {
 2460           status = -EFAULT;
 2461           break;
 2462       }
 2463 
 2464       if (fatal_signal_pending(current)) {
 2465           status = -EINTR;
 2466           break;
 2467       }
 2468 
 2469       status = a_ops->write_begin(file, mapping, pos, bytes, flags,
 2470                       &page, &fsdata);
 2471       if (unlikely(status < 0))
 2472           break;
 2473 
 2474       if (mapping_writably_mapped(mapping))
 2475           flush_dcache_page(page);
 2476 
 2477       copied = iov_iter_copy_from_user_atomic(page, i, offset, bytes);
 2478       flush_dcache_page(page);
 2479 
 2480       status = a_ops->write_end(file, mapping, pos, bytes, copied,
 2481                       page, fsdata);
 2482       if (unlikely(status < 0))
 2483           break;
 2484       copied = status;
 2485 
 2486       cond_resched();
 2487 
 2488       iov_iter_advance(i, copied);
 2489       if (unlikely(copied == 0)) {
 2490           /*
 2491            * If we were unable to copy any data at all, we must
 2492            * fall back to a single segment length write.
 2493            *
 2494            * If we didn't fallback here, we could livelock
 2495            * because not all segments in the iov can be copied at
 2496            * once without a pagefault.
 2497            */
 2498           bytes = min_t(unsigned long, PAGE_CACHE_SIZE - offset,
 2499                       iov_iter_single_seg_count(i));
 2500           goto again;
 2501       }
 2502       pos += copied;
 2503       written += copied;
 2504 
 2505       balance_dirty_pages_ratelimited(mapping);
 2506   } while (iov_iter_count(i));

@andrewgdavis pode-se usar esse commit durante o git bisect como um ponto de teste específico!

Observando um travamento semelhante ao desligar mongodb . Definitivamente presente no 1.9.x. Não presente em 1.8.x.

Consegui resolver esse problema sozinho aumentando a memória da VM da docker-machine de 1024 para 2048 MB e atribuindo 2 CPUs em vez de 1.

Trabalho:

VM: Ubuntu 14.04 (2 gb de RAM)
Docker Engine: 1.9.1
Imagem base do Docker: ubuntu: mais recente

Não funciona:

VM: Ubuntu 15.10 (2 gb de RAM)
Docker Engine: 1.9.1,1.9.0,1.8.3
Imagem base do Docker: ubuntu: mais recente , ubuntu: 14.04

@marsinvasion Se possível, você pode imprimir a saída de uname -a em ambos os sistemas testados?

VM: Ubuntu 14.04
Linux ubuntu 3.19.0-25-generic # 26 ~ 14.04.1-Ubuntu SMP Sex. 24 de julho 21:16:20 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux

VM: Ubuntu 15.10
Linux ubuntu 4.2.0-19-generic # 23-Ubuntu SMP Quarta, 11 de novembro 11:39:30 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux

+1
Docker versão 1.9.1, compilação a34a1d5 no OS X 10.11.1

Encontrado no OS X 10.9.5 com docker 1.9.1.

Inspirado por @marsinvasion , obtive uma solução alternativa bem-sucedida, dando à minha docker-machine 2 CPUs e 4096 MB de RAM.

Opa, falei em breve. Ele parou de funcionar ao alterar um Dockerfile em que estou trabalhando e reexecutando a compilação.

Também vendo este bug terrível (docker-machine boot2docker 1.9.1 no OS X), de uma imagem do ubuntu: 15.04 anteriormente construída. Parece que é necessário reiniciar meu servidor docker para que esses contêineres zumbis desapareçam.

Achei que https://github.com/docker-library/java/issues/19 estava relacionado, mas talvez não, aqui estamos travando, lá eles obtiveram um erro sobre não encontrar "java".

Alternei meu servidor para sobreposição como uma solução alternativa. Antes disso, ele também criou vários contêineres de zumbis.

Docker versão 1.9.1, compilação a34a1d5 no OS X 10.11.1

Alguém sabe o que está envolvido na migração de um sistema boot2docker.iso existente para https://docs.docker.com/engine/userguide/storagedriver/overlayfs-driver/ ou é mais fácil fazer uma reconstrução completa? Essa página tem avisos ameaçadores sobre construções de imagens CentOS - quais são as soluções alternativas "yum", está relacionado a https://github.com/docker/docker/issues/10180?

Foi corrigido no 1.9.1a - instale-o se você estiver no OSX - https://github.com/docker/toolbox/releases/download/v1.9.1a/DockerToolbox-1.9.1a.pkg

Definitivamente não foi corrigido pelo Docker Toolbox 1.9.1a. Sofrendo desse bug com essa versão. Olhando para trás pelos comentários, parece que eu não sou o único.

não, ainda não está construindo

Tive que deletar a VM no virtualbox e começar do zero para que funcionasse.

Além disso, tentei excluir e criar uma nova VM várias vezes, sem sucesso.

Instalou o 1.9.1a, fez docker-machine rm default e usou o Docker Quickstart Terminal para regenerar a máquina padrão. Imagens reconstruídas (que derivam de java:7-jre ) e executadas ainda não funcionam. Continua a funcionar bem com a máquina de sobreposição construída conforme sugerido acima:

$ docker-machine create -d virtualbox --engine-storage-driver overlay overlay

^ obrigado! Posso confirmar que a máquina de sobreposição está funcionando.

Usar overlay como driver de armazenamento do mecanismo também funcionou para corrigir o travamento de desligamento do MongoDB.

Você pode contornar a falha de compilação do Dockerfile instalando o Oracle java em vez do OpenJDK:

# Oracle java is bulkier but avoids boot2docker/aufs docker issue 18180
RUN apt-get install -y software-properties-common python-software-properties && add-apt-repository -y ppa:webupd8team/java && apt-get update
RUN echo oracle-java8-installer shared/accepted-oracle-license-v1-1 select true | /usr/bin/debconf-set-selections
RUN apt-get install -y oracle-java8-installer && apt-get install -y oracle-java8-set-default

Mas eu estava subestimando o escopo do problema, o boot2docker 1.9.1 leva a processos java zumbi, mesmo em contêineres CentOS onde o openjdk pode ser instalado corretamente.
root 322 11.1 0.0 0 0 ? Zsl 18:43 29:48 [java] <defunct>

Não consigo configurar meu servidor docker com --engine-storage-driver overlay porque crio imagens baseadas em CentOS e overlayfs não é compatível com yum (https://github.com/ docker / docker / issues / 10180).

Tenho certeza de que o pessoal do Docker _não_ recomendaria isso, mas a maneira como superei esse problema de bloqueio foi construindo um boot2docker.iso que usa o docker 1.9.1 com um AUFS um pouco mais antigo. Instruções em https://github.com/boot2docker/boot2docker/issues/1099#issuecomment -163052066.

tentei oracle jdk1.7.0_75 e jdk1.8.0_65; travar e criar um processo java extinto.

DE: https://github.com/docker/docker/issues/10589
@neverfox exatamente o mesmo problema aqui, com a mesma imagem +1

~ docker version
Client:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.5.1
 Git commit:   a34a1d5
 Built:        Sat Nov 21 00:49:19 UTC 2015
 OS/Arch:      darwin/amd64

Server:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.3
 Git commit:   a34a1d5
 Built:        Fri Nov 20 17:56:04 UTC 2015
 OS/Arch:      linux/amd64


~ docker-machine inspect default
{
    "ConfigVersion": 3,
    "Driver": {
        "Driver": {
            "VBoxManager": {},
            "IPAddress": "192.168.99.100",
            "MachineName": "default",
            "SSHUser": "docker",
            "SSHPort": 61012,
            "SSHKeyPath": "/Users/myuser/.docker/machine/machines/default/id_rsa",
            "StorePath": "/Users/myuser/.docker/machine",
            "SwarmMaster": false,
            "SwarmHost": "tcp://0.0.0.0:3376",
            "SwarmDiscovery": "",
            "CPU": 1,
            "Memory": 4096,
            "DiskSize": 20000,
            "Boot2DockerURL": "",
            "Boot2DockerImportVM": "",
            "HostOnlyCIDR": "192.168.99.1/24",
            "HostOnlyNicType": "82540EM",
            "HostOnlyPromiscMode": "deny",
            "NoShare": false
        },
        "Locker": {}
    },
    "DriverName": "virtualbox",
    "HostOptions": {
        "Driver": "",
        "Memory": 0,
        "Disk": 0,
        "EngineOptions": {
            "ArbitraryFlags": [],
            "Dns": null,
            "GraphDir": "",
            "Env": [],
            "Ipv6": false,
            "InsecureRegistry": [],
            "Labels": [],
            "LogLevel": "",
            "StorageDriver": "",
            "SelinuxEnabled": false,
            "TlsVerify": true,
            "RegistryMirror": [],
            "InstallURL": "https://get.docker.com"
        },
        "SwarmOptions": {
            "IsSwarm": false,
            "Address": "",
            "Discovery": "",
            "Master": false,
            "Host": "tcp://0.0.0.0:3376",
            "Image": "swarm:latest",
            "Strategy": "spread",
            "Heartbeat": 0,
            "Overcommit": 0,
            "ArbitraryFlags": [],
            "Env": null
        },
        "AuthOptions": {
            "CertDir": "/Users/myuser/.docker/machine/certs",
            "CaCertPath": "/Users/myuser/.docker/machine/certs/ca.pem",
            "CaPrivateKeyPath": "/Users/myuser/.docker/machine/certs/ca-key.pem",
            "CaCertRemotePath": "",
            "ServerCertPath": "/Users/myuser/.docker/machine/machines/default/server.pem",
            "ServerKeyPath": "/Users/myuser/.docker/machine/machines/default/server-key.pem",
            "ClientKeyPath": "/Users/myuser/.docker/machine/certs/key.pem",
            "ServerCertRemotePath": "",
            "ServerKeyRemotePath": "",
            "ClientCertPath": "/Users/myuser/.docker/machine/certs/cert.pem",
            "StorePath": "/Users/myuser/.docker/machine/machines/default"
        }
    },
    "Name": "default",
    "RawDriver": "eyJWQm94TWFuYWdlciI6e30sIklQQWRkcmVzcyI6IjE5Mi4xNjguOTkuMTAwIiwiTWFjaGluZU5hbWUiOiJkZWZhdWx0IiwiU1NIVXNlciI6ImRvY2tlciIsIlNTSFBvcnQiOjYxMDEyLCJTU0hLZXlQYXRoIjoiL1VzZXJzL2RhdmlkZnJhbmNvZXVyLy5kb2NrZXIvbWFjaGluZS9tYWNoaW5lcy9kZWZhdWx0L2lkX3JzYSIsIlN0b3JlUGF0aCI6Ii9Vc2Vycy9kYXZpZGZyYW5jb2V1ci8uZG9ja2VyL21hY2hpbmUiLCJTd2FybU1hc3RlciI6ZmFsc2UsIlN3YXJtSG9zdCI6InRjcDovLzAuMC4wLjA6MzM3NiIsIlN3YXJtRGlzY292ZXJ5IjoiIiwiQ1BVIjoxLCJNZW1vcnkiOjQwOTYsIkRpc2tTaXplIjoyMDAwMCwiQm9vdDJEb2NrZXJVUkwiOiIiLCJCb290MkRvY2tlckltcG9ydFZNIjoiIiwiSG9zdE9ubHlDSURSIjoiMTkyLjE2OC45OS4xLzI0IiwiSG9zdE9ubHlOaWNUeXBlIjoiODI1NDBFTSIsIkhvc3RPbmx5UHJvbWlzY01vZGUiOiJkZW55IiwiTm9TaGFyZSI6ZmFsc2V9"
}
➜  ~  docker inspect 74
[
{
    "Id": "7471b734d7e7e47270511453a04d903c974cba77a2a0d259255355a653f95e04",
    "Created": "2015-11-27T13:23:11.515987776Z",
    "Path": "/docker-entrypoint.sh",
    "Args": [
        "cassandra",
        "-f"
    ],
    "State": {
        "Status": "running",
        "Running": true,
        "Paused": false,
        "Restarting": false,
        "OOMKilled": false,
        "Dead": false,
        "Pid": 1263,
        "ExitCode": 0,
        "Error": "",
        "StartedAt": "2015-11-27T13:23:11.612899257Z",
        "FinishedAt": "0001-01-01T00:00:00Z"
    },
    "Image": "338a92b912e4d5a84c4f399a9475a1476f8226eff85c2592c8e80ba58b13d225",
    "ResolvConfPath": "/mnt/sda1/var/lib/docker/containers/7471b734d7e7e47270511453a04d903c974cba77a2a0d259255355a653f95e04/resolv.conf",
    "HostnamePath": "/mnt/sda1/var/lib/docker/containers/7471b734d7e7e47270511453a04d903c974cba77a2a0d259255355a653f95e04/hostname",
    "HostsPath": "/mnt/sda1/var/lib/docker/containers/7471b734d7e7e47270511453a04d903c974cba77a2a0d259255355a653f95e04/hosts",
    "LogPath": "/mnt/sda1/var/lib/docker/containers/7471b734d7e7e47270511453a04d903c974cba77a2a0d259255355a653f95e04/7471b734d7e7e47270511453a04d903c974cba77a2a0d259255355a653f95e04-json.log",
    "Name": "/pensive_kalam",
    "RestartCount": 0,
    "Driver": "aufs",
    "ExecDriver": "native-0.2",
    "MountLabel": "",
    "ProcessLabel": "",
    "AppArmorProfile": "",
    "ExecIDs": null,
    "HostConfig": {
        "Binds": null,
        "ContainerIDFile": "",
        "LxcConf": [],
        "Memory": 0,
        "MemoryReservation": 0,
        "MemorySwap": 0,
        "KernelMemory": 0,
        "CpuShares": 0,
        "CpuPeriod": 0,
        "CpusetCpus": "",
        "CpusetMems": "",
        "CpuQuota": 0,
        "BlkioWeight": 0,
        "OomKillDisable": false,
        "MemorySwappiness": -1,
        "Privileged": false,
        "PortBindings": {},
        "Links": null,
        "PublishAllPorts": false,
        "Dns": [],
        "DnsOptions": [],
        "DnsSearch": [],
        "ExtraHosts": null,
        "VolumesFrom": null,
        "Devices": [],
        "NetworkMode": "default",
        "IpcMode": "",
        "PidMode": "",
        "UTSMode": "",
        "CapAdd": null,
        "CapDrop": null,
        "GroupAdd": null,
        "RestartPolicy": {
            "Name": "no",
            "MaximumRetryCount": 0
        },
        "SecurityOpt": null,
        "ReadonlyRootfs": false,
        "Ulimits": null,
        "LogConfig": {
            "Type": "json-file",
            "Config": {}
        },
        "CgroupParent": "",
        "ConsoleSize": [
            0,
            0
        ],
        "VolumeDriver": ""
    },
    "GraphDriver": {
        "Name": "aufs",
        "Data": null
    },
    "Mounts": [
        {
            "Name": "2249b03f9a598e5ac3f306983877292baa299c4499c9db77eb9bfcb88fd2f541",
            "Source": "/mnt/sda1/var/lib/docker/volumes/2249b03f9a598e5ac3f306983877292baa299c4499c9db77eb9bfcb88fd2f541/_data",
            "Destination": "/var/lib/cassandra",
            "Driver": "local",
            "Mode": "",
            "RW": true
        }
    ],
    "Config": {
        "Hostname": "7471b734d7e7",
        "Domainname": "",
        "User": "",
        "AttachStdin": false,
        "AttachStdout": true,
        "AttachStderr": true,
        "ExposedPorts": {
            "7000/tcp": {},
            "7001/tcp": {},
            "7199/tcp": {},
            "9042/tcp": {},
            "9160/tcp": {}
        },
        "Tty": false,
        "OpenStdin": false,
        "StdinOnce": false,
        "Env": [
            "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
            "CASSANDRA_VERSION=2.1.11",
            "CASSANDRA_CONFIG=/etc/cassandra"
        ],
        "Cmd": [
            "cassandra",
            "-f"
        ],
        "Image": "cassandra:2.1.11",
        "Volumes": {
            "/var/lib/cassandra": {}
        },
        "WorkingDir": "",
        "Entrypoint": [
            "/docker-entrypoint.sh"
        ],
        "OnBuild": null,
        "Labels": {},
        "StopSignal": "SIGTERM"
    },
    "NetworkSettings": {
        "Bridge": "",
        "SandboxID": "e2f074e4b10e67cd7ac22d6e73d50304fc3f0a68d67c7fee6d7f8d647c9eb9b1",
        "HairpinMode": false,
        "LinkLocalIPv6Address": "",
        "LinkLocalIPv6PrefixLen": 0,
        "Ports": {
            "7000/tcp": null,
            "7001/tcp": null,
            "7199/tcp": null,
            "9042/tcp": null,
            "9160/tcp": null
        },
        "SandboxKey": "/var/run/docker/netns/e2f074e4b10e",
        "SecondaryIPAddresses": null,
        "SecondaryIPv6Addresses": null,
        "EndpointID": "63596aa5ec20516d477921fec4197d086b4dd4f1ad25014b5ddf027b82891966",
        "Gateway": "172.17.0.1",
        "GlobalIPv6Address": "",
        "GlobalIPv6PrefixLen": 0,
        "IPAddress": "172.17.0.2",
        "IPPrefixLen": 16,
        "IPv6Gateway": "",
        "MacAddress": "02:42:ac:11:00:02",
        "Networks": {
            "bridge": {
                "EndpointID": "63596aa5ec20516d477921fec4197d086b4dd4f1ad25014b5ddf027b82891966",
                "Gateway": "172.17.0.1",
                "IPAddress": "172.17.0.2",
                "IPPrefixLen": 16,
                "IPv6Gateway": "",
                "GlobalIPv6Address": "",
                "GlobalIPv6PrefixLen": 0,
                "MacAddress": "02:42:ac:11:00:02"
            }
        }
    }
}
]

Simplesmente executei docker run -it cassandra:2.1.11 e seu terminal ficará preso, não há como parar o contêiner. Você tem que parar a VM inteira.

+1

Conseguiu duplicar o problema hoje cedo no Docker 1.9.1 executando Mac OSX 10.11.1 (15B42)

Consegui contornar isso instalando o Docker 1.9.0

_A desculpas por falta de informação estava na minha máquina de trabalho mais cedo durante o dia - vou fornecer informações atualizadas mais tarde _

: +1:

O mesmo aqui com Docker 1.9.1 e OS X 10.11.

Para pessoas com esse problema

Até agora reduzimos isso para não ser um bug _docker_, mas um problema de kernel em combinação com AUFS no kernel que é usado pela versão atual do boot2docker; consulte https://github.com/docker/docker/issues/18180#issuecomment -161832035

• Se você quiser se manter informado sobre o progresso, use o botão de inscrição nesta página. não comente se não tiver novas informações que possam ajudar a resolver esse problema.
• se você quiser ajudar a resolver isso, executar um git-bissect do kernel pode ajudar https://github.com/docker/docker/issues/18180#issuecomment -161834068
• lembre-se de que cada comentário enviará mais de 2.000 e-mails aos assinantes e inúmeros cachorros morrerão: sorria:

Acabei de testar Storage Driver: devicemapper (com Server Version: 1.9.1 e kernel 4.2.6), e o bug _não_ se reproduz, então ainda estamos em "interação estranha entre alguma mudança no kernel mais recente e os patches AUFS "terra. : desapontado:

Testado, e o bug ainda está presente no kernel 4.1.14 fresco , então ainda estamos sentados em algum commit que foi feito backport para 4.1.13 interagindo estranhamente com os patches AUFS (e não tivemos sorte com ele já ter sido corrigido no o provisório).

Decidi dar uma chance à velha faculdade e clonar o repositório boot2docker; em seguida, modificou o commit do aufs no dockerfile para a versão anterior. Portanto, docker 1.9.1 kernel 4.1.13 + versão AUFS anterior que foi enviada antes de 1.9.1. A compilação está lenta na minha máquina ... há uma configuração docker swarm que eu possa executar em conjunto com uma bissetriz git e agregar os resultados? isso seria doce.

de qualquer forma, postarei meus resultados em breve se funcionar ...

atualizar:
4.1.13 + este commit AUFS ainda exibe o problema.
ENV AUFS_COMMIT 1724fe65683d126a92c6baeea0b3c7d0306c63ef

Não estou ciente de nenhuma configuração fácil para agregar os resultados, embora uma possa ser concebida.

FWIW, https://sources.debian.net/src/ca-certificates-java/jessie/debian/postinst.in/ é o script exato que está rodando naquele pacote, e https://sources.debian.net/src /ca-certificates-java/jessie/src/main/java/org/debian/security/UpdateCertificates.java/ é a fonte Java exata que está sendo executada quando obtemos a CPU pendurada + extinta + indexada.

Tive um problema relacionado (o processo java trava) hoje.

Ambiente do host: Linux lenovo 4.2.0-19-generic # 23-Ubuntu SMP Quarta-feira, 11 de novembro 11:39:30 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux
Distro: Ubuntu 15.10
Docker Engine: 1.9.1
Máquina Docker: 0.5.0 (04cfa58)

Estou seguindo o tutorial de vários hosts de rede . A única diferença é que estou brincando com a imagem oracle / nosql . Essa imagem é baseada no Oracle Linux e usa OpenJDK.

@brunoborges sim, pode ser o mesmo problema, consulte https://github.com/docker/docker/issues/18500#issuecomment -163334612

@brunoborges apenas verifique sua versão do boot2docker.iso - se for 1.9.1 você pode tentar fazer o downgrade para 1.9.0 e recriar sua máquina e extrair imagens mais uma vez.
Se você for por aqui, poderia escrever um breve relatório aqui?

Então eu comecei a me perguntar por que isso só acontece em java, e não em outras linguagens. Em uma das minhas postagens anteriores, fui capaz de detalhar as reproduções mais básicas simplesmente compilando e executando

class Foo {
public static void main(String[] a) {
  System.out.println("hellowerld");
  }
}

para o caso de falha que resultou em processo java extinto
e depois

class Foo {
public static void main(String[] a) {
  System.out.println("hellowerld");
  System.exit(0);
  }
}

para o caso esperado (não extinto).

Em seguida, tentei reproduzir algo semelhante usando python. Não tive sucesso - mas tentei. Para os interessados, eu estava tentando exibir a última saída de strace exit_group(0) = ? que foi vista do processo java zumbi. (Este link me forneceu muitas informações sobre python threading / seccomp / etc http://stackoverflow.com/questions/25678139/how-do-you-cleanly-exit-after-enabling-seccomp-in-python)

Então, vamos para a terra do kernel: Depois de reconstruir o boot2docker iso, mexendo com as versões do aufs e versões do kernel (nada do que realmente fez diferença), fiquei farto de como o processo de compilação estava lento usando numproc = 1. Então eu mudei para 6. ==> note não mais 1 cpu (quem tem apenas 1 cpu hoje em dia?). De repente, o caso de falha

class Foo {
public static void main(String[] a) {
  System.out.println("hellowerld");
  }
}

começou a trabalhar.

Obviamente, a próxima coisa a tentar era baixá-lo de volta para 1 cpu. ==> FALHA. de volta a um processo java extinto.

Então, eu queria explorar mais sobre como o java é encerrado. Não está bem definido. mas com apenas 1 cpu este processo java foi executado com sucesso: (por favor, não tire sarro do meu java horrível.)

import java.util.Iterator;
import java.util.Set;

class Foo {

static public final Object a = new Object();
static {
  final Object aa = a;
  Runtime.getRuntime().addShutdownHook(new Thread() {
        <strong i="21">@Override</strong>
        public void run() {
                System.out.println("added one");
                if (aa == null)
                        { System.out.println("out"); }
        }
  });
  System.out.println("exit");
  Set<Thread> threadSet = Thread.getAllStackTraces().keySet();

  Thread[] threadArray = threadSet.toArray(new Thread[threadSet.size()]);
  for(Thread xxx : threadArray)
  {
    System.out.println(xxx.toString());
  }
////  System.exit(0);
}
static public void main(String[] a) {}

Alguém mais pode confirmar este comportamento? << a questão agora é discutível

Atualização: Mesmo com mais de um núcleo, um processo java extinto pode ocorrer. (Eu estava executando o cassandra-cli e aconteceu.)

docker-machine ssh myVM

ps -ef:
docker    6606  5863  0 Dec11 ?        00:00:00 /bin/sh /cassandra/bin/cassandra-cli -f /home/foo/my.cli -h 172.17.0.2
docker    6651  6606 99 Dec11 ?        00:41:29 [java] <defunct>

cat /proc/6606/stack
[<ffffffff8106e491>] do_wait+0x1ab/0x23f
[<ffffffff8106e5bc>] SYSC_wait4+0x97/0xb0
[<ffffffff8106d66b>] child_wait_callback+0x0/0x43
[<ffffffff8155466e>] system_call_fastpath+0x12/0x71
[<ffffffffffffffff>] 0xffffffffffffffff

cat /proc/6651/stack
[<ffffffff8106f06c>] do_exit+0x88f/0x8cc
[<ffffffff81075f8d>] signal_wake_up_state+0x23/0x36
[<ffffffff8106f104>] do_group_exit+0x36/0xa6
[<ffffffff8106f180>] __wake_up_parent+0x0/0x1d
[<ffffffff8155466e>] system_call_fastpath+0x12/0x71
[<ffffffffffffffff>] 0xffffffffffffffff

Tendo o mesmo problema de travamento ao construir o bitbucket-server - update-ca-certificates funciona bem, mas o posthook jdk trava para sempre. Apenas um problema ao usar o boot2docker 1.9.1. Mudou para a imagem do RancherOS e não teve problemas. OSX 10.10.

Com El Capitan, Docker 1.9.1 e Ubuntu 14.04.1 eu obtenho: Configurando ca-certificados-java que trava infinitamente.

@stremlenye revertido para 1.9.0. Ainda trava.

@brunoborges docker 1.9.0or boot2docker.iso 1.9.0?

@stremlenye Docker 1.9.0 ... quais são as instruções para obter boot2docker.iso 1.9.0 em meu sistema?

@brunoborges Confira este comentário acima:

https://github.com/docker/docker/issues/18180#issuecomment -160660738

carsten-ulrich-saitow-ag explica como criar uma nova docker-machine com a iso 1.9.0 usando o sinalizador --virtualbox-boot2docker-url. Esse conselho salvou meu bacon! Depois de fazer isso, poderia instalar novamente meu RPM JRE em meus contêineres.

@ mobsy74 @stremlenye tentou com boot2docker 1.9.0 e às vezes trava.

@brunoborges Obrigado por tentar isso. Então, vou ficar com 1.8.3 até que esse bug seja corrigido.

@stremlenye você quer dizer boot2docker 1.8.3?

@brunoborges sim

Oi,
Eu tive o mesmo problema.
o problema foi resolvido ao fazer o downgrade das ferramentas docker de 1.9.1 para 1.9.0
https://github.com/docker/toolbox/releases/download/v1.9.0/DockerToolbox-1.9.0.pkg

Habilitar vários cpus (na máquina docker) resolveu isso para mim.

--virtualbox-cpu-count=4

@heiths, você pode compartilhar versões das ferramentas do docker?

imho, boot2docker deve se afastar de aufs para um dos outros drivers de armazenamento disponíveis. Há um bom motivo pelo qual o aufs nunca foi incluído no kernel do Linux.

@robvanmieghem cada driver tem suas limitações. Aufs é bastante estável no geral, e overlayfs tem alguns problemas de bloqueio (dependendo do uso)

@brunoborges DockerToolbox-1.9.1c - funcionou para mim no windows e osx.

@thaJeztah nunca disse que overlayfs é a solução perfeita. Eu acho que btrfs é uma boa opção para boot2docker, porém, boot2docker é dedicado a rodar containers docker e além do fato de que btrfs é totalmente suportado no kernel do linux, é realmente fácil olhar o conteúdo.

Existem tantas opiniões sobre isso quanto combinações de distro e sistema de arquivos :) Nenhuma solução será perfeita para todos os casos de uso, então, no espírito do código aberto e do linux, acho que a melhor decisão a fazer é fornecer melhor suporte para múltiplas escolhas de distro. Já temos a opção de Boot2Docker ou RancherOS e acredito que algum trabalho foi feito para reconstruir o boot2docker em uma distro debian. docker-machine suportará ubuntu em nuvem e bare metal, então tenho certeza de que um vm iso baseado em ubuntu não seria difícil de juntar, assim como outros, como um construído em alpine ou CoreOS etc. Então, para cada um deles, há a escolha do sistema de arquivos - novamente, o RancherOS agora oferece ZFS como uma instalação opcional, enquanto o CoreOS costumava usar BTRFS por padrão e eu acredito que ainda é uma opção e a partir do kernel 3.19 Ubuntu oferece suporte a OverlayFS pronto para uso - qualquer um com base em Snappy Core imagem b2d? ;)

Agora, se pudéssemos padronizar a nomenclatura do parâmetro docker-machine e remover as referências a 'boot2docker' para reduzir a confusão - usar o parâmetro boot2docker-url para instalar o RancherOS não é intuitivo;)

@ far-blue +1

@heiths +1. Isso resolveu para mim também no OSX com 1.9.1c

Definir CPU para> 1 evita o problema para mim. 1.9.1c não ajudou.

@heiths @fredriksvensson Na verdade, esse problema apareceu aleatoriamente em vários ambientes de contêineres e também tentei aumentar a quantidade de CPUs (memória também, mas isso não é um ponto). Alguns ciclos de stop <all> / start <all> mostraram que o problema não desapareceu. Eu recomendo que você verifique seu ambiente da mesma forma para garantir que a solução seja estável para você.
/ cc @timechanter

Oh, definitivamente não foi embora. Mas 10% de chance de travar versus 100% de travar é pelo menos administrável a curto prazo.

@heiths --virtualbox-cpu-count=4 também funcionou para mim.

@timechanter +1 Definir CPUs para> 1 evitou o problema para mim pelo menos uma vez; parece uma solução alternativa eficaz no momento.

OSX 10.10.5

Caixa de ferramentas do Docker desinstalada 1.9.1. Fazer downgrade para a caixa de ferramentas Docker 1.9.0 funcionou para mim.

Mesmo problema no El Capitan MacOSX

@heiths --virtualbox-cpu-count=4 funciona para mim.

Aconteceu para mim no Windows 7 com Docker Toolbox 1.9.1b e 1.9.1e.

"Configurando ca-certificados-java (20130815ubuntu1) ..." - El Capitan MacOSX. Por favor ajudem, pessoal !!! Não consigo consertar

@ troian88 downgrade para boot2docker.iso 1.9.0 ou 1.8.3.

@ troian88 , use uma máquina docker com várias cpu's.

Pode confirmar que --virtualbox-cpu-count=2 é uma solução temporária para um Setting up ca-certificates-java suspenso com Docker 1.9.1

Para pessoas com esse problema

Até agora reduzimos isso para não ser um bug _docker_, mas um problema de kernel em combinação com AUFS no kernel que é usado pela versão atual do boot2docker; consulte https://github.com/docker/docker/issues/18180#issuecomment -161832035

• Se você quiser se manter informado sobre o progresso, use o botão de inscrição nesta página. não comente se não tiver novas informações que possam ajudar a resolver esse problema.
• se você quiser ajudar a resolver isso, executar um git-bissect do kernel pode ajudar https://github.com/docker/docker/issues/18180#issuecomment -161834068
• lembre-se de que cada comentário enviará mais de 2.000 e-mails aos assinantes e inúmeros cachorros morrerão: sorria:

@externl @stremlenye Obrigado.

Olhando para as pilhas LWP, descobri que o bug é causado por aufs_destroy_inode .

Eu vou olhar mais para isso.

Parece ser um deadlock relacionado a inode-> i_mutex .

# uname -a
Linux suda-PC2 4.2.0-21-generic #25-Ubuntu SMP Wed Dec 2 18:42:25 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

# ps -eLf | grep java
root     23358 23091 23358  0    2 10:48 ?        00:00:00 [java] <defunct>
root     23358 23091 23359 99    2 10:48 ?        00:53:41 [java] <defunct>
root     25679 28603 25679  0    1 11:42 pts/22   00:00:00 grep --color=auto java

# cat /proc/23358/stack # this is not so much helpful
[<ffffffff8107e002>] do_exit+0x822/0xb10
[<ffffffff8107e383>] do_group_exit+0x43/0xb0
[<ffffffff8107e404>] SyS_exit_group+0x14/0x20
[<ffffffff817f0232>] entry_SYSCALL_64_fastpath+0x16/0x75
[<ffffffffffffffff>] 0xffffffffffffffff

# cat /proc/23358/task/23359/stack # seems very helpful
[<ffffffff81183fe5>] generic_file_write_iter+0xf5/0x1e0
[<ffffffff811fc98b>] new_sync_write+0x9b/0xe0
[<ffffffffc061c273>] do_xino_fwrite+0x53/0x90 [aufs]
[<ffffffffc061c2fe>] xino_fwrite.part.27+0xe/0x10 [aufs]
[<ffffffffc061c388>] xino_fwrite+0x88/0xa0 [aufs]
[<ffffffffc063bf8f>] au_xigen_inc+0x5f/0xc0 [aufs]
[<ffffffffc061d0c7>] au_xino_delete_inode+0x177/0x1f0 [aufs]
[<ffffffffc062f336>] au_iinfo_fin+0xc6/0x1b0 [aufs]
[<ffffffffc0617c76>] aufs_destroy_inode+0x16/0x30 [aufs]
[<ffffffff812186ac>] destroy_inode+0x3c/0x60
[<ffffffff812187eb>] evict+0x11b/0x180
[<ffffffff81218a39>] iput+0x199/0x220
[<ffffffff81214155>] __dentry_kill+0x195/0x1f0
[<ffffffff812142e5>] dput+0x135/0x230
[<ffffffff811ff098>] __fput+0x188/0x220
[<ffffffff811ff17e>] ____fput+0xe/0x10
[<ffffffff81098b8b>] task_work_run+0x9b/0xb0
[<ffffffff8107db80>] do_exit+0x3a0/0xb10
[<ffffffff8107e337>] SyS_exit+0x17/0x20
[<ffffffff817f0232>] entry_SYSCALL_64_fastpath+0x16/0x75
[<ffffffffffffffff>] 0xffffffffffffffff



# gdb /usr/lib/debug/boot/vmlinux-4.2.0-21-generic -ex 'l *(generic_file_write_iter+0xf5)'
0xffffffff81183fe5 is in generic_file_write_iter (/build/linux-1vdNXv/linux-4.2.0/mm/filemap.c:2652).

# gdb /usr/lib/debug/lib/modules/4.2.0-21-generic/kernel/fs/aufs/aufs.ko -ex 'l *(aufs_destroy_inode+0x16)'
0xca6 is in aufs_destroy_inode (/build/linux-1vdNXv/linux-4.2.0/fs/aufs/super.c:56).

Nota

As pessoas estão dizendo que o bug pode ser evitado quando executado em várias CPUs.
No entanto, ainda posso acertar o bug com minha caixa física de 4 CPUs. (embora <1% de probabilidade.)
Portanto, --virtualbox-cpu-count=2 _NOT_ garante que você pode evitar o bug.

Observe que o número de CPUs ainda é importante.
Posso determinar o bug quando executo taskset 0x1 java . ( taskset atribui CPUs específicas ao processo).

@AkihiroSuda muito obrigado por investigar isso. Mantenha-nos informados! :coração:

Observe que esse problema também ocorre no Windows 7 ao usar o Docker 1.8.3.

Estamos vendo o mesmo (exatamente os mesmos rastreamentos de pilha do comentário de AkihiroSuda acima) em kernels mais antigos:
Linux 3.19.0-42-generic #48~14.04.1-Ubuntu SMP x86_64 com Docker version 1.9.1, build a34a1d5

Posso confirmar a afirmação de @AkihiroSuda sobre múltiplas CPUs - também achei isso no meu host, que tem 8 núcleos.

Essa depuração do AUFS parece realmente interessante - talvez valha a pena registrar um problema com o AUFS e ver se os mantenedores do AUFS podem ajudar a depurar. Provavelmente seria útil para eles se pudéssemos reproduzir apenas com AUFS (sem Docker), mas isso não é exatamente trivial. :sorriso:

@tianon Fiz uma postagem sobre aufs-users: http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/5335

@AkihiroSuda , eu vi isso travar com um caso de uso não Java. Ou seja, tentando desligar um daemon MongoDB bifurcado. Isso não ocorre na inicialização do MongoDB ou no uso regular, mas ocorre de forma confiável no desligamento.

@jakirkham Obrigado, parece que uma configuração de thread específica (tende a aparecer em Java, MongoDB e talvez em outras coisas) é necessária para acionar o bug.

BTW, pensando bem, talvez o travamento do AUFS seja um "resultado" do bug, e não "a causa" do bug.
Estou examinando este tópico: http://www.serverphorums.com/read.php?12 , 673905
(Não percebi que zap_pid_ns_processes() também estava travado há dois dias, porque eu tinha usado o bash como o processo de inicialização naquela época. Https://github.com/docker/docker/issues/18180#issuecomment- 166186061)

https://github.com/docker/docker/issues/18180#issuecomment -161843456
@andrewgdavis , você está certo!

O bug parece ser uma regressão causada pelo commit 296291cd para o kernel Linux ( mm/filemap.c ).

Fiz um Boot2Docker ISO ( boot2docker-v1.9.1-fix1.iso ) que omite o commit 296291cd: https://github.com/AkihiroSuda/boot2docker/releases/tag/v1.9.1-fix1

Espero que funcione para todos. :risonho:

O commit 296291cd produz um loop infinito -EINTR em mm/filemap.c:generic_perform_write , que fs/aufs/xino.c:do_xino_fwrite() não pode tolerar:

static ssize_t do_xino_fwrite(vfs_writef_t func, struct file *file, void *kbuf,
                  size_t size, loff_t *pos)
{
..
    do {
         /* cannot escape from this loop 
            when func returns -EINTR infinitely! */
        err = func(file, buf.u, size, pos);
    } while (err == -EAGAIN || err == -EINTR);
..
}

Como do_xino_fwrite() loops infinitamente, zap_pid_ns_processes() (executado em outro LWP) não pode retornar de schedule() quando executado em um único processador.
É por isso que estamos descobrindo o bug.

@ gilles-duboscq
Você está descobrindo o bug porque a Canonical originalmente fez backport do commit 296291cd para a árvore do kernel 3.19: http://kernel.ubuntu.com/git/ubuntu/ubuntu-vivid.git/commit/?id=6b08592b8acc677d5b9bb7986343fdd6e0ad3303

@AkihiroSuda nossa, obrigado por encontrar! Quais são os próximos passos? Esse patch deve ser revertido ou existe uma maneira de melhorá-lo? Você está pensando em enviar um patch para o kernel upstream?

@AkihiroSuda , sua correção funciona

@thaJeztah

Essa não é uma pergunta fácil.
Sem o commit 296291cd, sendfile(2) pode não ser morto.
Temo que este sendfile inalterável possa causar um problema de segurança (ou seja, ataque de exaustão do processo por um usuário anônimo) em alguns ambientes.

Estou tentando melhorar o commit 296291cd, mas pode demorar um pouco.

De qualquer forma, relatei esse bug ao bugzilla do kernel: https://bugzilla.kernel.org/show_bug.cgi?id=109971

Também criei um contêiner Docker akihirosuda/test18180 para facilitar a depuração: https://github.com/AkihiroSuda/test18180/tree/v0.0.1

$ docker run -it --rm akihirosuda/test18180
[INFO] Checking whether hitting docker#18180.
<-- hangs up here with commit 296291cd
[INFO] OK. not hitting docker#18180.
[INFO] Checking whether sendfile(2) is killable.
[INFO] If the container hangs up here, you are still facing the bug that linux<strong i="18">@296291cd</strong> tried to fix.
<-- hangs up here without commit 296291cd
[INFO] OK. sendfile(2) is killable.
<-- No kernel can reach here

@AkihiroSuda hm, certo, soa como um problema, sim. Muito obrigado pelo repro-container e pesquisa; pelo menos há uma tarefa muito específica para trabalhar, com sorte outras pessoas se juntarão a ela, tentando ajudar a encontrar uma solução. Muito obrigado pelo seu excelente trabalho até agora.

Eu fui atingido no OS X El Capitan Darwin Kernel versão 15.2.0
Docker versão 1.9.1, compilação d12ea79c9de6d144ce6bc7ccfe41c507cca6fd35
boot2docker 1.9.1

O downgrade para boot2docker 1.9.0 com os comandos abaixo funcionou para mim:

docker-machine rm default
docker-machine create -d virtualbox --virtualbox-boot2docker-url=https://github.com/boot2docker/boot2docker/releases/download/v1.9.0/boot2docker.iso default

@thaJeztah
AUFS vai oferecer suporte a 296291cd.
http://article.gmane.org/gmane.linux.file-systems.aufs.user/5343

Portanto, o próximo passo é aguardar a atualização do AUFS.

Você é um herói, @AkihiroSuda! Obrigado por trabalhar com o upstream para resolver isso! :coração:

Se alguém quiser aplicar a correção @AkihiroSuda , isso funciona

docker-machine rm default
docker-machine create -d virtualbox --virtualbox-boot2docker-url=https://github.com/AkihiroSuda/boot2docker/releases/download/v1.9.1-fix1/boot2docker-v1.9.1-fix1.iso default

Para qualquer pessoa no Ubuntu 14.04, fazer o downgrade para o kernel 3.13.0-71 ou mais antigo deve resolver o problema. 296291cd foi portado para trás depois disso .

@ebpitts obrigado pela dica, aqui estão algumas etapas relativas para fazer o downgrade do kernel do Ubuntu 14.04 para 3.13.0-71 com Docker 1.9.1 instalado.

sudo apt-get install linux-image-3.13.0-71-generic
sudo apt-get install linux-generic linux-headers-generic linux-image-generic
sudo reboot

Neste ponto, você deve ter dois kernels para escolher durante a inicialização. No entanto, eu estava executando em uma caixa Vagrant remota sobre SSH, portanto, nenhum carregador de inicialização GRUB para mim ... então, removi o kernel padrão mais recente (3.13.0-74 no meu caso) como uma opção de inicialização:

sudo apt-get remove linux-image-3.13.0-74-generic
sudo apt-get install linux-generic linux-headers-generic linux-image-generic

A saída do comando tinha algumas coisas sobre o Grub sendo atualizado, então você pode inspecionar /boot/grub/grub.cfg e ver qual será a opção de inicialização padrão ao reiniciar. Parece que tive que fazer isso remover / adicionar novamente os cabeçalhos, mas uma vez que o arquivo grub.cfg parecia bom ( 3.13.0-71-generic era a única e primeira opção de inicialização), vá em frente e reinicie:

sudo reboot

E, então, volte SSH para minha caixa:

$ uname -r
3.13.0-71-generic

Mas agora parecia que docker não estava funcionando. Portanto, a reinstalação completa requer a remoção primeiro:

sudo apt-get autoremove --purge docker-engine
rm -rf /var/lib/docker 

E, honestamente, minha próxima tentativa de executar um docker build no mesmo contêiner que estava pendurado no título do OP ("Configurando ca-certificados-java"), _ainda_ morreu e travou minha máquina desta vez , mas agora que não tenho acesso SSH, irei para casa e esperarei até 2016 para tentar ver se alguém tem uma solução melhor até então = /

Então ... Não posso afirmar que mesmo depois de fazer o downgrade do kernel para 3.13.0-71 depois de acertar esse problema no Ubuntu 14.04 + Docker 1.9.1 é mesmo eficaz. Que nojo.

Sim, só para confirmar, executei $ docker run -it --rm akihirosuda/test18180 e ainda trava.

[INFO] Checking whether hitting docker#18180.
........................................................................................
[INFO] OK. not hitting docker#18180.
[INFO] Checking whether sendfile(2) is killable.
[INFO] If the container hangs up here, you are still 
       facing the bug that linux<strong i="7">@296291cd</strong> tried to fix.

Isso ocorre após o downgrade do Ubuntu 14.04 para a versão do kernel 3.13.0-71 com AUFS

$ docker info
Containers: 3
Images: 18
Server Version: 1.9.1
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 24
 Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-71-generic
Operating System: Ubuntu 14.04.3 LTS
CPUs: 1
Total Memory: 490 MiB
Name: myrunner
ID: MLBL:bla:blah

@ebpitts, você tem certeza que o downgrade do kernel no Ubuntu é realmente a correção?

Interessante, mesmo quando eu defino o driver de armazenamento explicitamente devicemapper em /var/default/docker :

DOCKER_OPTS="--dns 8.8.8.8 --dns 8.8.4.4 --storage-driver=devicemapper"

e reinicie o serviço docker, executando docker info :

$ docker info
Containers: 1
Images: 16
Server Version: 1.9.1
Storage Driver: devicemapper
 Pool Name: docker-8:1-399761-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 107.4 GB
 Backing Filesystem:
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 2.817 GB
 Data Space Total: 107.4 GB
 Data Space Available: 35.25 GB
 Metadata Space Used: 2.74 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.145 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.77 (2012-10-15)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-71-generic
Operating System: Ubuntu 14.04.3 LTS
CPUs: 1
Total Memory: 490 MiB
Name: myrunner
ID: MLBL:bla:blah

Ainda estou pendurado na imagem de teste akihirosuda/test18180:latest .

Fiz o downgrade para Docker 1.8.3 (não é tão fácil sem apt-get ) em minha caixa do Ubuntu 14 usando o binário bruto, aqui estão as etapas ... para qualquer outra pessoa ... Estou de volta aos negócios (por favor note que também fiz downgrade do kernel para 3.13.0-71-generic anteriormente, veja acima)

Eu instalei o binário 1.8.3 de https://get.docker.com/builds/Linux/x86_64/docker-1.8.3 , então movi para /usr/bin/docker , dei a ele sudo chmod +x /usr/bin/docker permissões executáveis.

Então, peguei o script sysvinit-debian bruto, comentei o corpo check_init() e substituí-o simplesmente por echo '' e o coloquei em /etc/init.d . Então eu o configurei para rodar na inicialização como root com ln -s /etc/init.d/docker /etc/rc2.d/S99docker , e executei sudo reboot . Depois disso, estou de volta executando o serviço docker 1.8.3 na inicialização de uma instalação binária. Não sei por que essas etapas não estão realmente documentadas na página de instalação do binário no site do docker. Enfim.

$ service docker status
 * Docker is running

$ docker version
Client:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   f4bf5c7
 Built:        Mon Oct 12 18:01:15 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 18:01:15 UTC 2015
 OS/Arch:      linux/amd64

$ docker info
Containers: 4
Images: 38
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 46
 Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-71-generic
Operating System: Ubuntu 14.04.3 LTS
CPUs: 1
Total Memory: 490 MiB
Name: runner
ID: BLAH

Parece bom aqui - posso executar $ docker run -it hello-world corretamente. Executando akihirosuda/test18180 ainda trava na verdade (???), mas eu sou capaz de construir e executar meu contêiner original sem ficar preso em Setting up ca-certificates-java , o que me trouxe aqui em primeiro lugar.

Para referência, estou no Ubuntu 15.04 vivid, Linux 3.19.0-42-generic. Também afetado.

Como não posso usar overlay (preciso de convidados RHEL), criei uma partição btrfs em uma unidade sobressalente e montei-a em / var / lib / docker (pare o daemon do docker antes). O Docker agora está usando o btrfs felizmente, mas a imagem de @akihirosuda ainda trava na segunda verificação (estranho).

@mikeatlas
Obrigado por testar minha imagem test18180 .

O resultado não é estranho.
A segunda verificação ( Checking whether sendfile(2) is killable. ) desliga nos kernels antigos.
Você precisa de um kernel mais novo com 296291cd para passar na segunda verificação.

| AUFS? | Kernel inclui 296291cd? | Resultado Esperado |
| --- | --- | --- |
| Y | Y | Pendura (primeiro cheque: Checking whether hitting docker#18180. ) |
| Y | N | Trava (2ª verificação: Checking whether sendfile(2) is killable. ) |
| N | Y | Passe |
| N | N | Trava (2ª verificação: Checking whether sendfile(2) is killable. ) |

@cfstras Obrigado, vou dar uma olhada nisso.

@cfstras , é reproduzível e abri # 19073.

@mikeatlas RE: https://github.com/docker/docker/issues/18180#issuecomment -168111226

EDITAR:
Anteriormente, eu estava errado sobre por que o docker não funcionava depois de mudar as versões do kernel, mas posso confirmar que a instalação do pacote extra para meu kernel e, em seguida, reinstalar o docker resolveu este problema para mim:

sudo apt-get remove docker-engine
sudo apt-get install linux-image-extra-3.13.0-71-generic
curl -sSL https://get.docker.com/ | sh

@lwcolton interessante, linux-image-extra-3.13.0-71-generic não é um pacote que pensei em instalar (mas instalei os pacotes extras genéricos depois, como observado) .... mas ainda assim, tive a impressão de que o módulo AUFS é muito mais antigo que apenas o kernel 3.13.0-71 relativamente recente. Independentemente disso, fazer o downgrade para o Docker 1.8.3 também não foi muito doloroso e, se eu tivesse que passar pelo processo novamente, preferiria fazer o downgrade do Docker a fazer o downgrade do kernel do Linux em qualquer dia da semana.

@dschep Observe para outros que mudar para OverlayFS requer a versão do kernel 3.18 + no Linux e, como citado na página do Docker, _Tão promissor como o OverlayFS é, ele ainda é relativamente novo.

@mikeatlas Acho que esta é a maior limitação até agora no OverlayFS: "_Portanto, usar o yum dentro de um contêiner em um host Docker usando o driver de armazenamento de sobreposição provavelmente não funcionará sem implementar soluções alternativas. _".

@brunoborges yum está atualmente sendo corrigido para funcionar em overlayfs, então, em breve, as versões mais recentes do yum deverão ser capazes de funcionar em overlayfs (ainda haverá alguns problemas, portanto, depende do seu caso de uso / situação em que você se deparar eles). O uso excessivo de inode pode ser outro problema.

Acho que também estou enfrentando esse problema. O rastreamento de chamada menciona o apparmor, mas desabilitar o apparmor não faz diferença. Usar o mapeador de dispositivos eliminou o problema.

dmesg:

[ 2761.400178] INFO: task flake8:4231 blocked for more than 120 seconds.
[ 2761.403014]       Not tainted 3.13.0-74-generic #118-Ubuntu
[ 2761.405419] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 2761.408741] flake8          D ffff8807707d3180     0  4231   1798 0x00000000
[ 2761.408745]  ffff8806bcb07c70 0000000000000082 ffff880035b34800 ffff8806bcb07fd8
[ 2761.408748]  0000000000013180 0000000000013180 ffff880035b34800 ffff8806b95054f8
[ 2761.408750]  ffff8806b95054fc ffff880035b34800 00000000ffffffff ffff8806b9505500
[ 2761.408752] Call Trace:
[ 2761.408759]  [<ffffffff81729499>] schedule_preempt_disabled+0x29/0x70
[ 2761.408762]  [<ffffffff8172b305>] __mutex_lock_slowpath+0x135/0x1b0
[ 2761.408765]  [<ffffffff811c903e>] ? lookup_fast+0x14e/0x2c0
[ 2761.408767]  [<ffffffff8172b39f>] mutex_lock+0x1f/0x2f
[ 2761.408770]  [<ffffffff811ca9cd>] do_last+0x2bd/0x1200
[ 2761.408772]  [<ffffffff8131666b>] ? apparmor_file_alloc_security+0x5b/0x180
[ 2761.408776]  [<ffffffff812d8c86>] ? security_file_alloc+0x16/0x20
[ 2761.408779]  [<ffffffff811cde8b>] path_openat+0xbb/0x640
[ 2761.408782]  [<ffffffff8109ac3a>] ? try_to_wake_up+0x1fa/0x2c0
[ 2761.408785]  [<ffffffff811ce4af>] ? getname_flags+0x4f/0x190
[ 2761.408787]  [<ffffffff811cf27a>] do_filp_open+0x3a/0x90
[ 2761.408790]  [<ffffffff811dc0d7>] ? __alloc_fd+0xa7/0x130
[ 2761.408793]  [<ffffffff811bd839>] do_sys_open+0x129/0x280
[ 2761.408795]  [<ffffffff811bd9ae>] SyS_open+0x1e/0x20
[ 2761.408798]  [<ffffffff8173575d>] system_call_fastpath+0x1a/0x1f

root# docker info
Containers: 14
Images: 565
Server Version: 1.9.1
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 593
 Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-74-generic
Operating System: Ubuntu 14.04.2 LTS
CPUs: 16
Total Memory: 29.44 GiB
Name: ...
ID: ...
Username: ...
Registry: https://index.docker.io/v1/
WARNING: No swap limit support

ps auxfg:

9013       4195  0.0  0.0 175808 24012 ?        Ssl  Jan08   0:01  \_ /usr/local/bin/python3.4 /usr/local/bin/flake8 .
9013       4224 99.9  0.0      0     0 ?        Zl   Jan08 1042:10  |   \_ [flake8] <defunct>
9013       4230  0.0  0.0      0     0 ?        Z    Jan08   0:00  |   \_ [flake8] <defunct>
root      14058  0.0  0.0 171780 21960 ?        Ssl  03:33   0:00  \_ /usr/local/bin/python3.5 /usr/local/bin/flake8 .
root      14148 99.9  0.0      0     0 ?        Zl   03:33 639:25      \_ [flake8] <defunct>

Isso foi corrigido no AUFS upstream - boot2docker foi atualizado para incluir a correção (que sairá com a próxima versão), e todos os usuários não boot2docker afetados devem aplicar a versão AUFS atualizada. : +1:

@tianon , você tem alguma referência aos bugs do upstream?

http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/5345 é o anúncio de lançamento do upstream - não tenho certeza se há mais discussão do que isso

http://comments.gmane.org/gmane.linux.file-systems.aufs.user/5337 tem mais da discussão de fundo para o problema

obrigado!

Isso foi corrigido no AUFS upstream - boot2docker foi atualizado para incluir a correção (que sairá com a próxima versão), e todos os usuários não boot2docker afetados devem aplicar a versão AUFS atualizada. : +1:

Agradável.

A versão com erros do AUFS foi usada no Docker Hub?

@tianon "Aplicar a versão atualizada do AUFS" significa para usuários não boot2docker (todos executando o docker engine _não_ em desenvolvimento no Mac OS X, para o qual o b2d é construído, principalmente) que terão que esperar por uma atualização do kernel do Linux com este patch AUFS ... Ou ... considerando quantas instalações / pessoas parecem ser afetadas, instruções simplificadas / mínimas poderiam ser fornecidas por alguém sobre como corrigir o AUFS para 4.1.13+? O guia para 4.1.13+ definitivamente não é trivial para ler; corrigir o próprio kernel do Linux para essa correção específica não é exatamente para os fracos de coração.

Só para constar, se eu construir este boot2docker.iso e colocá-lo em ~/.docker/machine/cache e criar uma nova VM com docker-machine essa VM usará esta nova cópia de boot2docker .

Só para eu entender, se eu construir este boot2docker.iso e colocá-lo em ~ / .docker / machine / cache e criar uma nova VM com docker-machine, essa VM usará essa nova cópia do boot2docker.

Tecnicamente sim, isso funcionaria, mas uma opção melhor pode ser usar --virtualbox-boot2docker-url , por exemplo:

$ docker-machine create -d \
    --virtualbox-boot2docker-url file://$(pwd)/boot2docker.iso \
    newvm

Ah, ok, obrigado pelo esclarecimento. Bem, isso parece estar funcionando então.

Enviou uma solicitação para atualizar AUFS para Canonical: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043

Haverá uma nova versão do boot2docker, já que 1.9.1 não parece ter a correção?

editar. com a imagem boot2docker @AkihiroSuda, consegui continuar. Obrigado a todos!

Sim, essa correção é após 1.9.1. @tianon disse que um lançamento está planejado. Normalmente, ele sai ao mesmo tempo que docker sai para o lançamento. Como eles tendem a seguir um ciclo de 2 semanas de lançamentos, espero que um lançamento seja iminente. Nesse ínterim, @AkihiroSuda criou uma correção que você pode usar ou pode criar a sua própria, o que é realmente simples e leva tempo.

Obrigado @AkihiroSuda pela imagem, funciona! :)

+1 Debian Wheezy e Ubuntu 15.04

O lançamento do

Oh, desculpe, devo ter confundido. Obrigado por me esclarecer, @tiborvass. Você percebeu, @shusso?

@jakirkham eu fiz, obrigado: +1:

Consegui criar uma caixa virtual de host docker-machine usando esta correção:

https://github.com/AkihiroSuda/boot2docker/releases/tag/v1.9.1-fix1

Atualmente, os hosts docker-machine que crio no google compute engine, com a opção --driver google, parecem ter esse problema. Não há opção com o driver do google para especificar um .iso diferente, então não posso usar a correção acima no google compute.

Alguém sabe de uma solução alternativa? ou mesmo se o Google está ciente do problema, ou onde devo registrar um relatório de bug para eles.

O driver do google docker-machine é mantido pelo docker ou pelo google?

O driver pode ser encontrado aqui; https://github.com/docker/machine/tree/master/drivers/google

Acho que a imagem da VM que está sendo executada no Google Compute deve ser esta aqui:

https://github.com/docker/machine/blob/master/drivers/google/google.go#L35

Isso é:

" https://www.googleapis.com/compute/v1/projects/ubuntu-os-cloud/global/images/ubuntu-1510-wily-v20151114 "

Analisando o acima, uma possível solução alternativa parece ser a sugerida por @nathanleclaire

$ docker-machine create -d google --engine-storage-driver overlay overlay

Também parece haver uma opção "--google-machine-image" disponível para o driver Google para docker-machine. O comando:

$ gcloud compute images list

Lista as imagens públicas disponíveis. Percebi que um novo ubuntu wily foi colocado recentemente.

Apenas para confirmar:

$ docker-machine create -d google --engine-storage-driver overlay overlay

Trabalhou. Também investigarei a criação de uma imagem de máquina personalizada usando o boot2docker fixo e tentando conectá-la com a docker-machine.

Para qualquer um acertando isso no boot2docker, por favor, entregue o RC em
https://github.com/tianon/boot2docker-legacy/releases/tag/v1.10.0-rc1 a
tiro. : +1:

@tianon eu testo com a seguinte imagem trecloux / docker-java-zombie
E parece bom .... mas ainda trava com a imagem akihirosuda / test18180

Trabalho realmente impressionante eliminador de insetos !!

@trecloux você está usando btrfs e travando o sendfile?
Se sim, é um problema conhecido: https://github.com/docker/docker/issues/19073

@AkihiroSuda Estou usando a imagem boot2docker v1.10.0-rc1 com aufs:

$ docker info
Containers: 1
Images: 2
Server Version: 1.10.0-rc1
Storage Driver: aufs
 Root Dir: /mnt/sda1/var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 35
 Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.1.15-boot2docker
Operating System: Boot2Docker 1.10.0-rc1 (TCL 6.4.1); master : c4985d5 - Fri Jan 15 19:29:39 UTC 2016
CPUs: 1
Total Memory: 996.2 MiB
Name: b2d10rc1
ID: 34JP:KEQA:O4QJ:U2SE:BO2V:43JG:NL57:ORK7:HHMY:2P4U:2E3V:7B4I
Debug mode (server): true
 File Descriptors: 10
 Goroutines: 22
 System Time: 2016-01-19T08:24:26.145616582Z
 EventsListeners: 0
 Init SHA1:
 Init Path: /usr/local/bin/docker
 Docker Root Dir: /mnt/sda1/var/lib/docker
Username: trecloux
Registry: https://index.docker.io/v1/
Labels:
 provider=virtualbox

Aqui está o resultado de sua imagem de teste:

$ docker run -ti --rm akihirosuda/test18180
[INFO] Checking whether hitting docker#18180.
....................................................................................................
[INFO] OK. not hitting docker#18180.
[INFO] Checking whether sendfile(2) is killable.
[INFO] If the container hangs up here, you are still facing the bug that linux<strong i="10">@296291cd</strong> tried to fix.
/test.sh: line 22:  1008 Killed                  /sendfile-test

@trecloux É o comportamento esperado. Nada está desligando.

@AkihiroSuda Ok, desculpe. E obrigado pelo seu esforço :-)
Portanto, @tianon : 1.10.0-rc1 parece bom.

mesmo problema aqui. Aguenta a configuração de certificados CA, a CPU fica louca ...

$ docker version
Client:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.3
 Git commit:   a34a1d5
 Built:        Fri Nov 20 17:56:04 UTC 2015
 OS/Arch:      darwin/amd64

executando MacOSX 10.11.2

@sgoendoer tente usar a imagem de @AkihiroSuda com docker-machine create --driver virtualbox --virtualbox-boot2docker-url="file:/path_to_the_image" nameofmachine

para usuários não boot2docker, alguma ideia com qual versão do kernel isso será corrigido? 3.13.0-71 parece funcionar, 3.13.0-74 e 3.13.0-76 parecem estar corrompidos ...

Mesmo problema aqui; Portanto, não há uma solução fácil para isso?
Isso foi corrigido na versão RC? Tentando aquele agora. Embora provavelmente cause outros problemas.

ÚLTIMAS SOLUÇÕES RÁPIDAS (atualização: 21 de janeiro, 15:33 UTC)

| Distro | Solução Alternativa |
| --- | --- |
| Geral | Use devicemapper / overlay / btrfs (mas pode causar outro problema ..) |
| Boot2Docker | : white_check_mark: Atualize para v1.10.0-rc1 |
| Ubuntu 14.04LTS | : arrow_down: Downgrade do kernel para 3.13.0-71 ou mais antigo |
| Ubuntu 15.04 | : arrow_down: Downgrade do kernel para 3.19.0-39 ou mais antigo (: aviso: não testado) |
| Ubuntu 15.10 | : arrow_down: Downgrade do kernel para 4.2.0-18 ou mais antigo |
| Debian 7/8 | : arrow_down: Downgrade do kernel para a versão 3.16.7-ckt11 do lançamento 3.16.0 ( apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 ) ou anterior |
| Debian 9 | : white_check_mark: (não suporta AUFS desde kernel 3.18-1 ~ exp1) |
| Gentoo | : white_check_mark: Atualize para os mais recentes (: aviso: não testado) |
| RHEL / CentOS | : white_check_mark: (não suporta AUFS) |
| openSUSE | : white_check_mark: (não suporta AUFS) |

Tíquetes de emissão de distribuidores

| Distro | Status | URL do problema |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: Fechado | https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | : white_medium_square: Em andamento | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | Ainda não confirmado | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

@AkihiroSuda v1.10.0-rc1 não consertou os zumbis pra mim, quem também pegou o problema?

root     21996  0.0  0.0      0     0 ?        Ss   08:47   0:00  \_ [bash]
root     23810 99.7  0.0      0     0 ?        Zl   08:50   7:42  |   \_ [phantomjs] <defunct>

wait4(-1, 
[{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 469
wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 28
rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7f60c9ec3d40}, {0x4438a0, [], SA_RESTORER, 0x7f60c9ec3d40}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
close(3)                                = -1 EBADF (Bad file descriptor)
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
wait4(-1, 0x7ffc5ec19e58, WNOHANG, NULL) = -1 ECHILD (No child processes)
rt_sigreturn(0xffffffffffffffff)        = 0
read(0, "", 1)                          = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
exit_group(0)   

Depois de iniciar o strace no processo extinto, depois de algum tempo isso apareceu, mas depois disso o zumbi ainda existe:

root     21996  0.0  0.0      0     0 ?        Ss   08:47   0:00  \_ [bash]
root     23810 99.9  0.0      0     0 ?        Zl   08:50  26:06      \_ [phantomjs] <defunct>

Desta vez não está mais acessível via strace, acho que ainda está conectado, mesmo que não esteja.
: ~ # strace -p 23810

attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted

@wzrdtales
Você poderia obter pilhas LWP como em https://github.com/docker/docker/issues/18180#issuecomment -166186061?
Além disso, qual é o seu cmdline e versão do phantomjs?

Claro, phantomjs versão: 1.9

cmdline

$builddir/node_modules/phantomjs/lib/phantom/bin/phantomjs $builddir/node_modules/testem/assets/phantom.js http://localhost:7357/3891

:~# cat /proc/21996/stack # bash
[<ffffffff8106fee9>] do_wait+0x1e9/0x260
[<ffffffff81071042>] SyS_wait4+0xa2/0x110
[<ffffffff8106ecd0>] child_wait_callback+0x0/0x70
[<ffffffff810f945a>] zap_pid_ns_processes+0xfa/0x190
[<ffffffff81070b26>] do_exit+0x8e6/0xa80
[<ffffffff81070d46>] do_group_exit+0x46/0xb0
[<ffffffff81070dc7>] SyS_exit_group+0x17/0x20
[<ffffffff8154e50d>] system_call_fast_compare_end+0x10/0x15
[<ffffffffffffffff>] 0xffffffffffffffff

:~# cat /proc/23810/stack #phantomjs
[<ffffffff81070935>] do_exit+0x6f5/0xa80
[<ffffffff81070d46>] do_group_exit+0x46/0xb0
[<ffffffff8107ffd3>] get_signal_to_deliver+0x233/0x610
[<ffffffff81014507>] do_signal+0x67/0xad0
[<ffffffff811bcf38>] new_sync_read+0x78/0xb0
[<ffffffff8101e045>] read_tsc+0x5/0x20
[<ffffffff810d2442>] ktime_get_ts+0x42/0xd0
[<ffffffff811d091e>] poll_select_copy_remaining+0xfe/0x150
[<ffffffff8101501b>] do_notify_resume+0xab/0xc0
[<ffffffff8154e7ca>] int_signal+0x12/0x17
[<ffffffffffffffff>] 0xffffffffffffffff

E também a pilha de tarefas:

:~# cat /proc/23810/task/23839/stack 
[<ffffffff8114ef6a>] __generic_file_write_iter+0x14a/0x360
[<ffffffff8114f1ca>] generic_file_write_iter+0x4a/0xd0
[<ffffffff811bd0ec>] new_sync_write+0x6c/0xb0
[<ffffffff811bd080>] new_sync_write+0x0/0xb0
[<ffffffff811bd0fb>] new_sync_write+0x7b/0xb0
[<ffffffffa050c377>] xino_fwrite.part.28+0x67/0xb0 [aufs]
[<ffffffffa050c4b5>] xino_fwrite+0x75/0x90 [aufs]
[<ffffffff811fa97a>] fsnotify_clear_marks_by_inode+0x2a/0x110
[<ffffffff811d84b8>] iput+0x48/0x1b0
[<ffffffffa052b780>] au_xigen_inc+0x50/0xa0 [aufs]
[<ffffffffa050d33d>] au_xino_delete_inode+0x1ad/0x220 [aufs]
[<ffffffff811e5143>] __inode_wait_for_writeback+0x63/0xc0
[<ffffffffa051f485>] au_iinfo_fin+0xc5/0x1d0 [aufs]
[<ffffffffa0507cae>] aufs_destroy_inode+0xe/0x30 [aufs]
[<ffffffff811cab10>] do_unlinkat+0x170/0x2c0
[<ffffffff8108d4f1>] task_work_run+0xa1/0xc0
[<ffffffff81015025>] do_notify_resume+0xb5/0xc0
[<ffffffff8154e50d>] system_call_fast_compare_end+0x10/0x15
[<ffffffffffffffff>] 0xffffffffffffffff

Também para adicionar informações do sistema:

uname -a
Linux mg_build_server_12 3.16.0-0.bpo.4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u2~bpo70+1 (2016-01-03) x86_64 GNU/Linux

:~# docker info
Containers: 34
 Running: 9
 Paused: 0
 Stopped: 25
Images: 1058
Server Version: 1.10.0-rc1
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 1197
 Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Plugins: 
 Volume: local
 Network: null host bridge
Kernel Version: 3.16.0-0.bpo.4-amd64
Operating System: Debian GNU/Linux 7 (wheezy)
OSType: linux
Architecture: x86_64
CPUs: 16
Total Memory: 23.58 GiB

@wzrdtales Você está usando Docker (não Boot2Docker) v1.10.0-rc1 no Debian?
Não funciona porque o problema é um bug do kernel, e não do Docker.

Estou pesquisando os kernels do Debian e atualizarei a lista https://github.com/docker/docker/issues/18180#issuecomment -173436661.

@AkihiroSuda y, é diretamente no debian. Eu supervisionei o debian point em sua lista, obrigado por apontar :)

Para debian, não devemos usar kernels baseados na v3.16.7-ckt20
http://kernel.ubuntu.com/git/ubuntu/linux.git/tag/?h=linux-3.16.y&id=v3.16.7-ckt20
http://kernel.ubuntu.com/git/ubuntu/linux.git/commit/?h=linux-3.16.y&id=475a23000dd8d2f264bab9d6eb71a2a6b9d4de72

@wzrdtales Eu atualizei a lista, por favor use o kernel ckt11.

@AkihiroSuda : FWIW, acredito que a recomendação de rebaixar para v3.16.7-ckt11 coloca você em risco de CVE-2016-0728, que tem um escalonamento de raiz público conhecido. Acabei de pingar https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 , mas para sua informação, antes de fazer o downgrade.

@zmerlynn Obrigado por apontar isso!

ÚLTIMAS SOLUÇÕES RÁPIDAS (Atualização: 26 de janeiro 1h49 UTC)

| Distro | Solução Alternativa |
| --- | --- |
| Geral | Use devicemapper / overlay / btrfs (mas pode causar outro problema ..).
Se você pode atualizar AUFS e construir o kernel manualmente, você também pode usar AUFS v20160111 ou posterior. |
| Boot2Docker | : white_check_mark: Atualize para v1.10.0-rc1 |
| Ubuntu 14.04LTS | : arrow_down: Downgrade do kernel para 3.13.0-71 ou mais antigo |
| Ubuntu 15.04 | : arrow_down: Downgrade do kernel para 3.19.0-39 ou mais antigo (: aviso: não testado) |
| Ubuntu 15.10 | : arrow_down: Downgrade do kernel para 4.2.0-18 ou mais antigo |
| Debian 7/8 | : arrow_down: Downgrade do kernel para a versão 3.16.7-ckt11 do lançamento 3.16.0 ( apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 ) ou anterior |
| Debian 9 | : white_check_mark: (não suporta AUFS desde kernel 3.18-1 ~ exp1) |
| Gentoo | : white_check_mark: Atualize para os mais recentes (: aviso: não testado) |
| RHEL / CentOS | : white_check_mark: (não suporta AUFS) |
| openSUSE | : white_check_mark: (não suporta AUFS) |

: aviso: o downgrade do kernel pode ser um risco de segurança (por exemplo, CVE-2016-0728)

Tíquetes de emissão de distribuidores

| Distro | Status | URL do problema |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: Fechado | https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | : white_medium_square: Em andamento | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | : white_medium_square: Em andamento | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

Também encontramos este problema, o mongod está preso no estado R rodando com 100% da CPU.

Aqui está o verdadeiro truque para obter o rastreamento de pilha correto que me leva até aqui:

echo "l"> / proc / sysrq-trigger

a partir daí, você pode ver que a CPU 2 está presa em um loop infinito pelo AUFS

[38841.947453] CPU: 2 PID: 25084 Comm: mongod Not tainted 4.2.0-25-generic #30~14.04.1-Ubuntu
[38841.947454] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
[38841.947455] task: ffff88037383cb00 ti: ffff880097afc000 task.ti: ffff880097afc000
[38841.947456] RIP: 0010:[<ffffffff813b6fe0>]  [<ffffffff813b6fe0>] iov_iter_init+0x0/0x40
[38841.947457] RSP: 0018:ffff880097aff920  EFLAGS: 00000246
[38841.947458] RAX: 0000000000002cd0 RBX: ffff88037b289700 RCX: 0000000000000001
[38841.947458] RDX: ffff880097aff928 RSI: 0000000000000001 RDI: ffff880097aff960
[38841.947459] RBP: ffff880097aff998 R08: 0000000000000004 R09: 0000000000000000
[38841.947460] R10: 0000000000000006 R11: 0000000000000005 R12: ffff880097affa70
[38841.947461] R13: ffff880097affa6c R14: ffff88037b289700 R15: ffffffff811ea830
[38841.947462] FS:  00007f7f2acf2b80(0000) GS:ffff88041fd00000(0000) knlGS:0000000000000000
[38841.947463] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[38841.947463] CR2: 00007f47dbdb0000 CR3: 00000000a3995000 CR4: 00000000000006e0
[38841.947464] Stack:
[38841.947465]  ffffffff811ea8a9 ffff880097affa6c 0000000000000004 ffff88037b289700
[38841.947466]  0000000000002cd0 0000000000000000 0000000000000000 0000000000000000
[38841.947467]  0000000000000003 0000000000000000 0000000000000004 ffff880097aff928
[38841.947467] Call Trace:
[38841.947468]  [<ffffffff811ea8a9>] ? new_sync_write+0x79/0xb0
[38841.947469]  [<ffffffffc03fbbe3>] do_xino_fwrite+0x53/0x90 [aufs]
[38841.947470]  [<ffffffffc03fc05e>] xino_fwrite.part.27+0xe/0x10 [aufs]
[38841.947471]  [<ffffffffc03fc15a>] xino_fwrite+0x6a/0x80 [aufs]
[38841.947471]  [<ffffffffc041a634>] au_xigen_inc+0x54/0xa0 [aufs]
[38841.947472]  [<ffffffffc03fceab>] au_xino_delete_inode+0x17b/0x200 [aufs]
[38841.947473]  [<ffffffffc040e167>] au_iinfo_fin+0xc7/0x1c0 [aufs]
[38841.947474]  [<ffffffffc03f7c26>] aufs_destroy_inode+0x16/0x30 [aufs]
[38841.947475]  [<ffffffff8120529c>] destroy_inode+0x3c/0x60
[38841.947476]  [<ffffffff812053db>] evict+0x11b/0x180
[38841.947476]  [<ffffffff81205cb5>] iput+0x175/0x1e0
[38841.947477]  [<ffffffff81200c4d>] __dentry_kill+0x19d/0x1f0
[38841.947478]  [<ffffffff81200e39>] dput+0x199/0x200
[38841.947479]  [<ffffffff811f449a>] path_put+0x1a/0x30
[38841.947480]  [<ffffffff8174dfbd>] unix_release_sock+0x17d/0x2a0
[38841.947480]  [<ffffffff8174e101>] unix_release+0x21/0x40
[38841.947481]  [<ffffffff8169370f>] sock_release+0x1f/0x80
[38841.947482]  [<ffffffff81693782>] sock_close+0x12/0x20
[38841.947483]  [<ffffffff811ecb14>] __fput+0xe4/0x210
[38841.947483]  [<ffffffff811ecc8e>] ____fput+0xe/0x10
[38841.947484]  [<ffffffff8109360b>] task_work_run+0x9b/0xb0
[38841.947485]  [<ffffffff81085a45>] get_signal+0x565/0x600
[38841.947486]  [<ffffffff81014438>] do_signal+0x28/0x9a0
[38841.947487]  [<ffffffff8105d00e>] ? kvm_clock_get_cycles+0x1e/0x20
[38841.947487]  [<ffffffff810e5ede>] ? ktime_get_ts64+0x4e/0xf0
[38841.947488]  [<ffffffff811fe5f9>] ? poll_select_copy_remaining+0xd9/0x120
[38841.947489]  [<ffffffff811ff3bd>] ? SyS_select+0xbd/0xf0
[38841.947490]  [<ffffffff81014e15>] do_notify_resume+0x65/0x80
[38841.947491]  [<ffffffff817bacc4>] int_signal+0x12/0x17
[38841.947492] Code: 6c 83 ea 04 48 83 c7 04 e9 58 ff ff ff b9 6c 6c 00 00 48 83 c7 02 83 ea 02 66 89 4f fe e9 39 ff ff ff 66 0f 1f 84 00 00 00 00 00 <55> 65 48 8b 04 25 44 3b 01 00 48 83 b8 18 c0 ff ff ff 48 89 e
5

pesquisar por do_xino_fwrite me leva até aqui!

Parece que estou encontrando esse problema também no Debian Stretch, onde ele fica travado na configuração de certificados.

Esta é a mensagem de erro: https://gist.github.com/clball/738feb46094802a1bcf7
Aqui estão as informações da versão: https://gist.github.com/clball/494fe8598dd0cdfd6d10
Aqui está o dockerfile: https://gist.github.com/8778f8db143478d6c8ab

Então, qual é a solução para OSX aqui, já existe uma atualização do docker?

Ainda não, mas há um candidato a lançamento. (https://github.com/tianon/boot2docker-legacy/releases/tag/v1.10.0-rc2)

A solução para mim foi mudar o back-end de armazenamento.

Adicione uma linha a / etc / default / docker
¡¡TENHA CUIDADO, você perderá seus dados de contêiner !!

DOCKER_OPTS="--storage-driver=devicemapper"

Eu recomendo parar o serviço docker, apagar a pasta docker em / var / lib e adicionar a linha e reiniciar o serviço docker.

@ referup-tarantegui apenas como uma advertência, o driver devicemapper é considerado terrivelmente ruim para o desempenho, a menos que seja montado diretamente em discos físicos reais. Vejo
https://jpetazzo.github.io/assets/2015-03-03-not-so-deep-dive-into-docker-storage-drivers.html#43 https://jpetazzo.github.io/assets/2015 -03-03-not-so-deep-dive-into-docker-storage-drivers.html # 44
e
https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/ "Mapeador de dispositivos e desempenho do Docker"

Existe uma versão B para o candidato a lançamento 2

https://github.com/boot2docker/boot2docker/releases/tag/v1.10.0-rc2-b

Atualizada a tabela sobre o Ubuntu.

ÚLTIMAS SOLUÇÕES RÁPIDAS (Atualização: 3 de fevereiro, 6:30 UTC)

| Distro | Solução Alternativa |
| --- | --- |
| Geral | Use devicemapper / overlay / btrfs (mas pode causar outro problema ..).
Se você pode atualizar AUFS e construir o kernel manualmente, você também pode usar AUFS v20160111 ou posterior. |
| Boot2Docker | : white_check_mark: Atualize para v1.10.0-rc3 |
| Ubuntu 14.04LTS | : white_check_mark: Atualize o kernel para 3.13.0-77.121hf1533043v20160201b1 (PPA) |
| Ubuntu 15.04 | : white_check_mark: Atualize o kernel para 3.19.0-49.55hf1533043v20160201b1 (PPA) |
| Ubuntu 15.10 | : white_check_mark: Atualize o kernel para 4.2.0-27.32hf1533043v20160201b1 (PPA) |
| Debian 7/8 | : arrow_down: Downgrade do kernel para a versão 3.16.7-ckt11 do lançamento 3.16.0 ( apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 ) ou anterior |
| Debian 9 | : white_check_mark: (não suporta AUFS desde kernel 3.18-1 ~ exp1) |
| Gentoo | : white_check_mark: Atualize para os mais recentes (: aviso: não testado) |
| RHEL / CentOS | : white_check_mark: (não suporta AUFS) |
| openSUSE | : white_check_mark: (não suporta AUFS) |

Tíquetes de emissão de distribuidores

| Distro | Status | URL do problema |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: Fechado | https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | : white_medium_square: Em andamento (ETA: 20 de fevereiro) | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | : white_medium_square: Em andamento | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

@AkihiroSuda , acho que você quis dizer v1.10.0-rc2 para boot2docker ou talvez o link deveria ir aqui (https://github.com/boot2docker/boot2docker/releases/tag/v1.10.0-rc3).

@jakirkham Obrigado, consertou o link.

rc3 está no repositório oficial em vez de no meu fork:
https://github.com/boot2docker/boot2docker/releases/tag/v1.10.0-rc3

Investigamos a dívida de tecnologia que nos obrigou a usar meu garfo e descobrimos que
ele foi corrigido desde docker-machine 0.5, então estamos avançando e
para cima. :sorriso:

btw, para aqueles que procuram mudar os kernels para as versões com patch chiluk listadas acima para Ubuntu PPAs. Por exemplo, para Ubuntu 14.04, linux-image-3.13.0-77-generic , suas etapas seriam:

$ sudo apt-get update
$ sudo apt-get install software-properties-common -y
$ sudo add-apt-repository ppa:chiluk/1533043
$ sudo apt-get update
$ sudo apt-get install linux-image-3.13.0-77-generic \
                       linux-image-extra-3.13.0-77-generic -y

Em seguida, você precisará atualizar sua configuração /etc/default/grub , executar sudo update-grub e reinicializar na nova compilação de kernel corrigida. Se você não fez isso antes, aqui está um guia sobre como definir um kernel padrão diferente no grub .

Posso confirmar que esse problema não existe no Docker 1.10.0, que corrigiu minha situação no OS X 10.11 também. Caso contrário, eu faria o downgrade para 1.9.0.

Ainda estou recebendo o problema de java contêiner / processo travado no docker 1.10:

root     30480  0.1  0.0      0     0 ?        Z    16:15   0:00 [update-hosts] <defunct>

@AkihiroSuda Estou tentando

E: Version '3.16.7-ckt11-1+deb8u3' for 'linux-image-3.16.0-4-amd64' was not found

Quando tento as sugestões do aliás, tive que sudo apt-get install software-properties-common para fazer sudo add-apt-repository ppa:chiluk/1533043 funcionar), recebo uma falha de atualização, que acho que é a razão pela qual a instalação não funciona

$ sudo add-apt-repository ppa:chiluk/1533043
You are about to add the following PPA to your system:
 This ppa contains the proposed fix for 1533043, and I would appreciate testing and results reported back to  LP#1533043.

Thank you,
 More info: https://launchpad.net/~chiluk/+archive/ubuntu/1533043
Press [ENTER] to continue or ctrl-c to cancel adding it

gpg: keyring `/tmp/tmp_j6e2_s5/secring.gpg' created
gpg: keyring `/tmp/tmp_j6e2_s5/pubring.gpg' created
gpg: requesting key E2B6D4A9 from hkp server keyserver.ubuntu.com
gpg: /tmp/tmp_j6e2_s5/trustdb.gpg: trustdb created
gpg: key E2B6D4A9: public key "Launchpad PPA for Dave Chiluk" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
OK
$ sudo apt-get update
Ign http://ftp.us.debian.org jessie InRelease
Hit http://security.debian.org jessie/updates InRelease
...
Get:15 https://apt.dockerproject.org debian-jessie/main Translation-en [454 B]
Ign https://apt.dockerproject.org debian-jessie/main Translation-en
Err http://ppa.launchpad.net jessie/main amd64 Packages
  404  Not Found
Ign http://ppa.launchpad.net jessie/main Translation-en_US
Ign http://ppa.launchpad.net jessie/main Translation-en
Fetched 8,877 B in 3s (2,935 B/s)
W: Failed to fetch http://ppa.launchpad.net/chiluk/1533043/ubuntu/dists/jessie/main/binary-amd64/Packages  404  Not Found

E: Some index files failed to download. They have been ignored, or old ones used instead.

$ sudo apt-get install linux-image-3.13.0-77-generic \
>                        linux-image-extra-3.13.0-77-generic -y
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package linux-image-3.13.0-77-generic
E: Couldn't find any package by regex 'linux-image-3.13.0-77-generic'
E: Unable to locate package linux-image-extra-3.13.0-77-generic
E: Couldn't find any package by regex 'linux-image-extra-3.13.0-77-generic'

Minhas informações do docker:

$ docker info
Containers: 98
 Running: 9
 Paused: 0
 Stopped: 89
Images: 1415
Server Version: 1.10.0
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 1371
 Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
 Volume: local
 Network: null host bridge
Kernel Version: 3.16.0-4-amd64
Operating System: Debian GNU/Linux 8 (jessie)
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 15.6 GiB
Name: r62
ID: VUJF:KPXB:UXL6:TP3G:75CE:WQND:PJGJ:GG45:MCMI:JTV5:Q3IR:6FHC
WARNING: No memory limit support
WARNING: No swap limit support
WARNING: No oom kill disable support
WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support
Labels:
 provider=generic

@jamshid obrigado pela dica sobre a necessidade de software-properties-common , atualizei meu post acima.

@jamshid : Depois de adicionar o PPA e fazer apt-get update , verifique e veja quais kernels estão disponíveis para sua máquina ... Parece que há uma compilação mais recente ( 3.13.0-78 ), mas não vejo disponível após eu mesmo executar uma atualização aqui. No entanto, veja como você _pode_ descobrir quais kernels estão disponíveis para instalação:

$ apt-cache search linux-image-3.13.0-7
[... snip older builds ...]
linux-image-3.13.0-77-generic - Linux kernel image for version 3.13.0 on 64 bit x86 SMP

Se você não vir algo próximo a linux-image-3.13.0-77-generic ou superior, algo diferente deve estar errado.

Oh, @jamshid , você está executando o Debian 8? Nota acima: Downgrade kernel to version 3.16.7-ckt11 of release 3.16.0 (apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3) or older

apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 no Debian 8 dá

Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Version '3.16.7-ckt11-1+deb8u3' for 'linux-image-3.16.0-4-amd64' was not found

Uma hora de pesquisa ativa para encontrar o pacote ckt11 não ajudou.
Por favor, alguma sugestão de como fazer o downgrade do kernel Debian 8 recente?

apt-cache policy linux-image-3.16.0-4-amd64
linux-image-3.16.0-4-amd64:
  Installed: 3.16.7-ckt20-1+deb8u3
  Candidate: 3.16.7-ckt20-1+deb8u3
  Version table:
 *** 3.16.7-ckt20-1+deb8u3 0
        500 http://security.debian.org/ jessie/updates/main amd64 Packages
        100 /var/lib/dpkg/status
     3.16.7-ckt20-1+deb8u2 0
        500 http://ftp.debian.org/debian/ jessie/main amd64 Packages
        500 http://httpredir.debian.org/debian/ jessie/main amd64 Packages

@davojan Você pode encontrar os pacotes instalados anteriormente em /var/cache/apt/archives . Você deve ser capaz de fazer downgrade com dpkg -i <old_package>.deb .

Confirmei que a instalação do novo kernel do PPA corrigiu o problema para mim (Ubuntu 14.04.3 / Kernel 3.13.0-78-generic / Docker 1.9.1)
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043

Alguém recebeu as instruções de downgrade para trabalhar com o Debian (não o Ubuntu)? Estou me perguntando se o motivo do meu apt-get update falhar com o erro abaixo (após adicionar o repo ppa):

W: Failed to fetch http://ppa.launchpad.net/chiluk/1533043/ubuntu/dists/jessie/main/binary-amd64/Packages  404  Not Found

é que apenas pacotes do ubuntu estão disponíveis em https://launchpad.net/~chiluk/+archive/ubuntu/1533043? Hmm, estou confuso, pensei que o Ubuntu fosse baseado no Debian.

@jamshid Ubuntu ppa não suporta Debian.

Se 3.16.7-ckt11-1 + deb8u3 infelizmente não estiver mais disponível, você pode corrigir o kernel mais recente: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207#47

(Posso fazer o upload do pacote deb, se alguém precisar)

Se alguém precisar do kernel, eu o carreguei aqui, é um pouco mais novo que deb8u3, mas não parece que teria o bug, pelo menos não o encontrei executando isso por um bom tempo, mas corrigindo o o kernel mais recente é provavelmente a melhor solução. No entanto, se você precisar:
https://wizardtales.com/linux-image-3.16.0-0.bpo.4-amd64_3.16.7-ckt11-1+deb8u6~bpo70+1_amd64.deb

@wzrdtales : +1:

Para aqueles que, como eu, ainda estão lutando para resolver isso, gostaria de apontar a TINI como uma boa alternativa:
https://github.com/krallin/tini

com poucas linhas no dockerfile, obtive um processo de inicialização decente, capaz de remover zumbis.
Isso permitirá evitar a transição para o mapeador de dispositivos.

Felicidades,
Francesco

Então, eu uso tini. No entanto, isso não me ajudou aqui, pois o problema que encontrei foi enquanto a imagem estava sendo construída.

Além disso, ao executar um contêiner, eu uso tini, mas isso ainda me afetou.

@fflatorre
Obrigado pela informação, mas o problema dos zumbis que o tini pode resolver parece diferente deste problema.
https://github.com/docker/docker/issues/18180#issuecomment -167042078

Na verdade, mesmo com tini, podemos pegar um zumbi:

FROM java:7
ENV TINI_VERSION v0.9.0
ADD https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini /tini
RUN chmod +x /tini
ENTRYPOINT ["/tini", "--"]
CMD ["taskset", "0x1", "java"]

$ docker build -t foobar .
$ docker run -it --rm foobar
Usage: java [-options] class [args...]
           (to execute a class)
...
See http://www.oracle.com/technetwork/java/javase/documentation/index.html for more details.
(hangs up here and becomes a zombie)

@AkihiroSuda @jakirkham Esqueci de mencionar que não estamos enfrentando esse problema ao construir a imagem. Construímos uma imagem muito básica e, em seguida, a lógica de provisionamento é delegada a vários scripts ansible. Durante o provisionamento, um dos processos (kafka) costumava travar. TINI até agora parece ter atenuado esse problema.
Eu reconheço que pode não ser uma solução para você, na verdade, sugiro rebaixá-lo de solução alternativa para placebo :)
Espero que possamos resolver em breve.

Tive o mesmo problema ao executar o Docker 1.9.1 no OSX 10.11.3:

$ docker -v
Docker version 1.9.1, build a34a1d5

Atualização para a versão mais recente do Docker Toolbox corrigida:

$ docker -v
Docker version 1.10.1, build 9e83765

Para obter informações, listei alguns problemas e soluções alternativas relacionadas aos drivers de armazenamento AUFS / Overlay / BtrFS / ZFS / devicemapper: https://github.com/AkihiroSuda/docker-issues/

Espero que isso possa ajudar aqueles que estão interessados ​​em # 18180 e outros.

@AkihiroSuda Tentei seguir o link https://launchpad.net/%7Echiluk/+archive/ubuntu/1533043/+packages mas não tenho permissão para ver a página.

Veja também: https://github.com/docker/toolbox/issues/318#issuecomment -184143546

@ schmunk42
Eu também não consegui acessar a página.
Acho que chiluk está refazendo pacotes. Você pode perguntar a ele em https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043

Para as pessoas que estão tendo problemas com isso, veja como resolver o problema no Ubuntu 14.04 usando o

Antes de começar, podemos confirmar que estamos executando em um kernel afetado executando (ou seja, <3.19.0-50 no Ubuntu 14.04):

$ uname -r
3.19.0-49-generic

Como sabemos disso, primeiro precisamos ativar os pacotes

$ echo "deb http://archive.ubuntu.com/ubuntu/ trusty-proposed restricted main multiverse universe" | sudo tee -a /etc/apt/sources.list
$ echo -e "Package: *\nPin: release a=trusty-proposed\nPin-Priority: 400" | sudo tee -a  /etc/apt/preferences.d/proposed-updates

Feito isso, vamos instalar o kernel atualizado:

$ sudo apt-get update
$ sudo apt-get install linux-image-3.19.0-50-generic/trusty-proposed linux-image-extra-3.19.0-50-generic/trusty-proposed

E vamos reiniciar

$ sudo shutdown -r now

Após a reinicialização, podemos confirmar que os mais recentes agora estão sendo executados no kernel mais recente:

$ uname -r
3.19.0-50-generic

Obrigado @vpetersson, estou tentando descobrir o que acontecerá quando esta versão do kernel for lançada, será apenas sobrescrever a instalação proposta ou você tem que fazer algo para voltar ao normal, por favor?

@IainColledge Sim, imagino que seja o caso, mas não tenho certeza.

Atualizada a tabela sobre Ubuntu e Debian.

ÚLTIMAS SOLUÇÕES RÁPIDAS

| Distro | Solução Alternativa |
| --- | --- |
| Geral | Use devicemapper / overlay / btrfs (mas pode causar outro problema ..).
Se você pode atualizar AUFS e construir o kernel manualmente, você também pode usar AUFS v20160111 ou posterior. |
| Boot2Docker | : white_check_mark: Atualize para v1.10.0 ou posterior |
| Ubuntu 14.04LTS | : white_check_mark: Atualize o kernel para 3.13.0-79.123 ou posterior |
| Ubuntu 15.04 | : white_check_mark: Atualize o kernel para 3.19.0-51.57 ou posterior |
| Ubuntu 15.10 | : white_check_mark: Atualize o kernel para 4.2.0-30.35 ou posterior |
| Debian 7/8 | : arrow_down: Downgrade do kernel para a versão 3.16.7-ckt11 do lançamento 3.16.0 ou mais antigo ( arquivo dpkg por @wzrdtales) |
| Debian 9 | : white_check_mark: (não suporta AUFS desde kernel 3.18-1 ~ exp1) |
| Gentoo | : white_check_mark: Atualize para os mais recentes (: aviso: não testado) |
| RHEL / CentOS | : white_check_mark: (não suporta AUFS) |
| openSUSE | : white_check_mark: (não suporta AUFS) |

Tíquetes de emissão de distribuidores

| Distro | Status | URL do problema |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: Fechado | https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | : white_check_mark: Fechado | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | : white_medium_square: Em andamento | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

Mais uma coisa; Listei alguns bugs conhecidos sobre drivers de armazenamento: https://github.com/AkihiroSuda/docker-issues

Apenas no caso de alguém querer ter o kernel debian "linux_3.16.7-ckt20-1 + deb8u3" mais recente com patches, mencionado anteriormente - eu o construí manualmente e está em https://fxposter.org/linux-image-3.16 .0-4-amd64_3.16.7-ckt20-1 + deb8u3a ~ test_amd64.deb.

surpreendente! Estou tendo esse problema há algumas semanas e acho que a correção para o Ubuntu acabou de ser lançada ontem: P

Confirmar que a última atualização do kernel 14.04LTS para 3.19.0-51 acaba com meus zumbis java. Obrigado!

O Debian apoiou esse problema.

ÚLTIMAS SOLUÇÕES RÁPIDAS

| Distro | Solução Alternativa |
| --- | --- |
| Geral | Use devicemapper / overlay / btrfs (mas pode causar outro problema ..).
Se você pode atualizar AUFS e construir o kernel manualmente, você também pode usar AUFS v20160111 ou posterior. |
| Boot2Docker | : white_check_mark: Atualize para v1.10.0 ou posterior |
| Ubuntu 14.04LTS | : white_check_mark: Atualize o kernel para 3.13.0-79.123 ou posterior |
| Ubuntu 15.04 | : white_check_mark: Atualize o kernel para 3.19.0-51.57 ou posterior |
| Ubuntu 15.10 | : white_check_mark: Atualize o kernel para 4.2.0-30.35 ou posterior |
| Debian 7 | : white_check_mark: Atualize o kernel para 3.2.73-2 + deb7u3 (do pacote linux-image-3.2.0-4-amd64) ou posterior |
| Debian 8 | : white_check_mark: Atualize o kernel para 3.16.7-ckt20-1 + deb8u4 (do pacote linux-image-3.16.0-4-amd64) ou posterior |
| Debian 9 | : white_check_mark: (não suporta AUFS desde kernel 3.18-1 ~ exp1) |
| Gentoo | : white_check_mark: Atualize para os mais recentes (: aviso: não testado) |
| RHEL / CentOS | : white_check_mark: (não suporta AUFS) |
| openSUSE | : white_check_mark: (não suporta AUFS) |

Tíquetes de emissão de distribuidores

| Distro | Status | URL do problema |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: Fechado | https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | : white_check_mark: Fechado | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | : white_check_mark: Fechado | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

atualizar o kernel de 14.04LTS funcionou para mim: +1:

Estou no OSX no Boot2Docker versão 1.10.2, build master: 611be10, Docker versão 1.10.2, build c3959b1 e peguei isso em docker-compose:

Recreating docker_preview_1
ERROR: An HTTP request took too long to complete. Retry with --verbose to obtain debug information.
If you encounter this issue regularly because of slow network conditions, consider setting COMPOSE_HTTP_TIMEOUT to a higher value (current value: 60).

Em seguida, tentei docker kill 38e1e2590dfa mas o processo trava para sempre. docker.log:

time="2016-03-09T14:49:13.053004077Z" level=debug msg="Calling POST /v1.21/containers/38e1e2590dfa5d77482b8fbf6b14f01e8d5278622b8e5d7262cd2cdeb777690b/stop"
time="2016-03-09T14:49:13.053058084Z" level=debug msg="POST /v1.21/containers/38e1e2590dfa5d77482b8fbf6b14f01e8d5278622b8e5d7262cd2cdeb777690b/stop?t=10"
time="2016-03-09T14:49:13.053097711Z" level=debug msg="Sending 15 to 38e1e2590dfa5d77482b8fbf6b14f01e8d5278622b8e5d7262cd2cdeb777690b"
time="2016-03-09T14:49:23.053530062Z" level=info msg="Container 38e1e2590dfa5d77482b8fbf6b14f01e8d5278622b8e5d7262cd2cdeb777690b failed to exit within 10 seconds of SIGTERM - using the force"
time="2016-03-09T14:49:23.053720529Z" level=debug msg="Sending 9 to 38e1e2590dfa5d77482b8fbf6b14f01e8d5278622b8e5d7262cd2cdeb777690b"
time="2016-03-09T14:49:33.054082100Z" level=info msg="Container 38e1e2590dfa failed to exit within 10 seconds of kill - trying direct SIGKILL"
time="2016-03-09T14:49:34.254353402Z" level=debug msg="Calling GET /v1.22/containers/json"
time="2016-03-09T14:49:34.254413283Z" level=debug msg="GET /v1.22/containers/json"
time="2016-03-09T14:49:54.293708866Z" level=debug msg="Calling POST /v1.22/containers/38e1e2590dfa/kill"
time="2016-03-09T14:49:54.293752784Z" level=debug msg="POST /v1.22/containers/38e1e2590dfa/kill?signal=KILL"
time="2016-03-09T14:49:54.293802705Z" level=debug msg="Sending 9 to 38e1e2590dfa5d77482b8fbf6b14f01e8d5278622b8e5d7262cd2cdeb777690b"
time="2016-03-09T14:50:04.294276946Z" level=info msg="Container 38e1e2590dfa failed to exit within 10 seconds of kill - trying direct SIGKILL"
time="2016-03-09T14:50:26.678957119Z" level=debug msg="clean 3 unused exec commands"

Apenas como uma observação (sei que está encerrado, mas não tenho certeza se faz sentido abrir como um novo problema). Eu estava tendo o mesmo problema em uma versão posterior até que mudei para o devmapper.

$ docker info
Containers: 4
 Running: 3
 Paused: 0
 Stopped: 1
Images: 81
Server Version: 1.12.1
Storage Driver: devicemapper
 Pool Name: docker-8:1-9044034-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 10.74 GB
 Backing Filesystem: xfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 2.726 GB
 Data Space Total: 107.4 GB
 Data Space Available: 96.43 GB
 Metadata Space Used: 4.387 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.143 GB
 Thin Pool Minimum Free Space: 10.74 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 WARNING: Usage of loopback devices is strongly discouraged for production use. Use `--storage-opt dm.thinpooldev` to specify a custom block storage device.
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.77 (2012-10-15)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: apparmor
Kernel Version: 3.13.0-77-generic
Operating System: Ubuntu 14.04.5 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 15.56 GiB
Name: ravn
ID: L2WX:3RQ7:W6IC:7MY3:M3ZC:7MP2:3ZMP:VHW4:TLXM:VLYO:NNZ5:2FVW
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
Insecure Registries:
 127.0.0.0/8

@einhverfr O problema foi corrigido no kernel 3.13.0-79.123 (o seu parece ser 3.13.0-77)

Esse problema pode realmente ser resolvido com uma atualização do Kernel? Estamos enfrentando o mesmo problema com o Docker 1.9.1 no Ubuntu 14.04 com Kernel 3.13.0-83-generic.

Client:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   a34a1d5
 Built:        Fri Nov 20 13:12:04 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:12:04 UTC 2015
 OS/Arch:      linux/amd64

@ martinm82 sim, esse problema era um problema do kernel. É possível que algo mais possa resultar em um comportamento semelhante, ou se houver uma regressão no kernel. No entanto, abra um novo problema se você estiver tendo problemas com a versão atual; tenha em mente que docker 1.9.1 é EOL, então não receberá mais atualizações.

Estou bloqueando a discussão sobre esse problema, porque o problema original aqui foi resolvido e quero evitar que esse problema colete problemas possivelmente não relacionados. Veja este comentário; https://github.com/docker/docker/issues/18180#issuecomment -193708192 para as versões do kernel necessárias para corrigir este problema