Estoy enfrentando el mismo problema. Estoy investigando

También nos enfrentamos al mismo problema.

Sí, es un problema em Docker 1.9. Había bajado a 1.8.3 y todos los problemas resueltos. Ahora estoy investigando una solución alternativa. publicará aquí! Tks

Tengo el mismo problema con Docker 1.9.1a

Tengo Docker 1.8.3, así que tal vez el proceso de instalar una versión diferente de Docker solucione la situación. @bsao.

teniendo este mismo problema con la versión 1.9.1 de la ventana acoplable, compile a34a1d5

¿Solo ves esto en boot2docker?

No puedo reposicionar en un ubuntu común con aufs o en mi máquina. déjame probar con boot2docker para ver si puedo reposicionar allí.

+1 en Docker 1.9.1 para ubuntu: 14.10 usando OSX

Este es un problema que comenzó a aparecer después de que encendí la VPN para trabajar. Incluso después de apagar la VPN y reiniciar la máquina acoplable en OSX, continuó teniendo este problema. Reinstalé Docker 1.9.1 y luego 1.8.3, y sigo viendo el problema. Me impide usar la mayoría, si no todas, mis ventanas acoplables en Mac.

+1 en Docker 1.9.1 para ubuntu 12.04 con OS X 10.11

Los desarrolladores de mi oficina también se encontraron con esto por accidente.

Esta versión / compilación funcionó : Docker versión 1.9.0, compilación 76d6bc9

Esta versión / compilación se colgó : Docker versión 1.9.1, compilación a34a1d5

@crosbymichael Lamentablemente, no lo he probado en ningún otro entorno que no sea Boot2Docker.

¡Alguien con el conocimiento de git-bisecting y docker podría usar los ID de compilación proporcionados por @ chico1198!

Experimenté el mismo problema con 1.9.1 en OSX El Capitan, la degradación a 1.9.0 no ayudó.

El mismo problema aquí en OSX 10.9.3 con:
Docker versión 1.9.1, compilación a34a1d5
Docker versión 1.9.0, compilación 76d6bc9

@crosbymichael Inicié sesión en boot2docker y ejecuté ps auxf , esto es lo que 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 con docker 1.9.1 en OSX 10.11 al intentar crear una imagen desde ubuntu 14.04

+1
usar 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

La degradación a Docker 1.8.3 es mi solución temporal. Aquí está el target que uso en mi 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) 

No pude reproducir esto. ¿Siempre se cuelga en "configurar certificados"? ¿Intentaste enviar un ^D para cerrar alguna tubería? ¿También puede intentar enviar un SIGUSR1 al demonio y pegar el seguimiento de la pila aquí cuando esté bloqueado?

+1 con Docker 1.9.1 en OS X 10.10

Intenté degradar a 1.8.3 usando el Makefile de @osterman y también tuve problemas con la clave 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

Lo probé haciendo diferentes instalaciones de openjdk dentro de debian: jessie y ubuntu
OSX 10.11.1, boot2docker 1.9.1: se bloquea
OSX 10.11.1, boot2docker 1.9.0: funciona
Ubuntu 14.04 con Docker 1.9.1: funciona

Los vms boot2docker fueron creados con:
docker-machine create -d virtualbox --virtualbox-boot2docker-url = https://github.com/boot2docker/boot2docker/releases/download/v1.9.0/boot2docker.iso
y
docker-machine create -d virtualbox --virtualbox-boot2docker-url = https://github.com/boot2docker/boot2docker/releases/download/v1.9.1/boot2docker.iso

En Ubuntu 14.04, la ventana acoplable se instaló siguiendo la documentación en https://docs.docker.com/engine/installation/ubuntulinux/

+1, ejecutando docker 1.9.1 build a34a1d5 en OSX Yosemite 10.10.5.

No puedo reproducir esto.

El mismo problema aquí.
¿Hay alguna forma de degradar a una versión anterior en Windows?

Lo encontré yo mismo.
https://github.com/docker/docker/releases

+1, docker 1.9.1 @ El Capitan

+1, Docker 1.9.1 en OS X 10.11.1

+1, Docker 1.9.1a, OS X 10.10.5

+1, Docker 1.9.1 compilación a34a1d5, Windows 10

+1, Docker 1.9.1 compilación a34a1d5, OS X 10.11.1, Docker-Machine 0.5.1 compilación 7e8e38e

+1

Lo mismo en la máquina Docker en OSX 10.11.1
Docker versión 1.9.1, compilación a34a1d5
docker-machine versión 0.5.1 (HEAD)

Puedo reproducir esto en docker-machine, OS X 10.10.5, por lo que puede ser algo relacionado con boot2docker. docker top también me da <defunct> para un proceso 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 tal vez alguno de ustedes tenga una idea de dónde buscar, o qué depurar, realmente no pude encontrar algo

¿Cuánta RAM tiene su VM? Podría ser OOM dado que parece el
El proceso muere inesperadamente. :decepcionado:

Parece que la memoria no es el problema, sin embargo, el proceso <defunct> consume el 100% de la 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

El contenedor parece estar atascado también, y tuve que reiniciar la máquina virtual para que se matara

+1 Docker versión 1.9.1, compilación a34a1d5, Win 7.

Me he encontrado con problemas similares que resultaron ser OOM, aunque el comando stats muestra la memoria disponible para el contenedor. El problema ocurrió poco después de que el administrador de tareas mostrara 0 memoria física libre, mientras que las estadísticas seguían mostrando <100%.

Lo extraño es que el proceso siguió ejecutándose, por lo que no se mató. Puedo volver a intentarlo con -m, sin embargo, es extraño que esto suceda en 1.9.x, pero (después de esta discusión) no en 1.8. Además, se logró ejecutar lo mismo en una gota de DigitalOcean de 1 GB (también 1.9.1). Quizás ese use swap, debería comprobar que

De hecho, me siguió sucediendo después de desinstalar 1.9.1 e instalar 1.8.3. Sin embargo, parecía que la desinstalación no fue muy completa en Mac porque el inicio del shell fue sin demora en 1.8.3, a diferencia de una primera ejecución normal en la que configura las claves ssh y esas cosas.

_ ENCUESTA DE USUARIOS_

_La mejor forma de recibir notificaciones cuando haya cambios en esta discusión es haciendo clic en el botón Suscribirse en la parte superior derecha.

Las personas que se enumeran a continuación han apreciado su discusión significativa con un +1 aleatorio:

@mattes

31 participantes sobre este tema y contando.

@ bean5 por favor mantenga sus comentarios constructivos

@thaJeztah No deduje que

Puedo duplicar este problema en mi configuración (usando Docker Machine en Mac).

Estos son mis hallazgos hasta ahora.

Como se señaló en otros carteles, la forma más sencilla de duplicar esto ha sido utilizar el ISO boot2docker 1.9.1 con AUFS. Este Dockerfile debería reproducir mínimamente el problema con bastante rapidez:

FROM debian:jessie

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

Al mirar dmesg , veo algunos errores de AUFS después de intentar una compilación de este tipo, pero no estoy 100% seguro de que estén 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

Si creo una máquina Docker 1.9.1 que usa overlay como controlador de almacenamiento:

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

¡El proceso NO se bloquea y esta línea se ejecuta correctamente! Parece que AUFS y / o kernel es el problema.

boot2docker / boot2docker _did_ bump ambas versiones del kernel y el compromiso de AUFS para la versión 1.9.1, por lo que ambos son factores que deben descartarse o investigarse más a fondo:

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

Actualmente probando 1.9.0 ISO con un binario 1.9.1 para ver si el área de superficie del área de error potencial se puede reducir aún más.

El Dockerfile se compilará bien y no se bloqueará en un ISO boot2docker 1.9.0 con un binario Docker 1.9.1. El problema parece no estar en Docker 1.9.1, sino en el entorno en el que se ejecuta.

Estoy usando la versión 1.9.1 sin problemas en aufs, pero tengo significativamente más cpu / ram / storage que la configuración predeterminada de la máquina.

Intenté aumentar la memoria a 4 GB para mi máquina virtual, pero aún puedo reproducir

@ cpuguy83 AUFS en boot2docker 1.9.1?

Como se señaló anteriormente, b2d incluye una versión muy específica de AUFS.

Sí

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

También veo que algunos procesos de Java desaparecen en un contenedor. Puedo reproducir este problema con los siguientes pasos
ejecutar el contenedor:

docker run --rm -it myJavaContainerFromCentos7 bash

crea Foo.java con lo siguiente:

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

compilarlo y ejecutarlo da como resultado un proceso java inactivo, con 1 núcleo usando 100% cpu:
javac Foo.java && java Foo

sin embargo ... si se agrega System.exit(0); después de println todo está bien:

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

Información de la versión:
osx 10.10.3
Docker 1.9.1
boot2docker versión 1.9.1 uname -a es "linux ci 4.1.13-boot2docker"
numproc = 1

salida de strace con 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 +++

salida de 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)                           = ?

el proceso ahora está colgado pero puede ingresar al contenedor:

docker exec -it myContainer bash

y vea lo siguiente:

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

vistazo rápido a las estadí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

Todo funciona bien en 1.8.3.

+1, Docker versión 1.9.1, compilación a34a1d5, OS X

+1, Docker versión 1.9.1, compilación a34a1d5, OS X 10.10.5, Docker Machine Version: 0.5.1 (HEAD)

+1

Docker versión 1.9.1, compilación a34a1d5 , OS X 10.11.1 (15B42)

+1

Docker versión 1.9.1, compilación a34a1d5 en OS X 10.11.1

Este problema realmente es bastante extraño. Si strace el comando apt-get falla, el final de la salida es:

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)

Donde esos errores (descriptor de archivo incorrecto) continúan repitiéndose 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á fallando? esto podría corresponder a mi publicación anterior donde vi java "hola mundo" causando procesos zombies sin un "System.exit (0);" explícito; - O tal vez ese es un tema completamente diferente. si lo siento por el ruido.

¿Qué le sucede a su CPU mientras realiza un bucle indefinido?

@andrewgdavis Está al 100%

java "hola mundo" que provoca procesos zombies sin un "System.exit (0)" explícito;

Eso ciertamente suena similar al problema encontrado aquí.

Definitivamente puedo confirmar el problema de b2d (incluso hice la bisección para rastrearlo de manera más positiva hasta el golpe del kernel 4.1.13). También puedo reproducir en 4.2.6 con b2d.

Como problema adicional, mi host Gentoo está actualmente en parches 4.1.13 + AUFS también, y estoy viendo exactamente el mismo problema, así que definitivamente hemos descartado cualquier cosa específica de b2d.

Creo que podría valer la pena revisar las confirmaciones entre 4.1.12 y 4.1.13 para ver si algo que podría estar relacionado salta.

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

Sí, algo se rompe del kernel 4.1.12 => 4.1.13. Puedo confirmar que hornear un ISO boot2docker para el primero no dispara este error, pero el primero sí.

Entonces, no está relacionado específicamente con boot2docker, pero parece estar relacionado con la versión del kernel que interactúa con AUFS.

o quizás la forma específica en que el controlador AUFS en Docker interactúa con el
kernel más nuevo - TBD, probablemente con una bisección de git estable en Linux entre 4.1.12
y 4.1.13: llorar:

Tengo una teoría del cerebro ...

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

la confirmación anterior hace un cambio a filemap.c a generic_perform_write (struct file * file, struct iov_iter * i, loff_t pos)

A continuación se muestra el fragmento de código que personalmente quiero probar porque el comentario describe las condiciones de carrera de bloqueo y bloqueo en vivo y veo que la CPU está vinculada al 100%. pero eso es solo yo y mi tapete para sacar conclusiones.

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 ¡ uno podría usar ese compromiso durante git bisect como un punto de prueba específico!

Ver un bloqueo similar al cerrar mongodb . Definitivamente presente en 1.9.x. No presente en 1.8.x.

Pude resolver este problema por mí mismo aumentando la memoria de la VM de la máquina acoplable de 1024 a 2048 MB y asignando 2 CPU en lugar de 1.

Trabajos:

VM: Ubuntu 14.04 (2 GB de RAM)
Motor de Docker: 1.9.1
Imagen base de Docker: ubuntu: último

No funciona:

VM: Ubuntu 15.10 (2 GB de RAM)
Motor de Docker: 1.9.1,1.9.0,1.8.3
Imagen base de Docker: ubuntu: último , ubuntu: 14.04

@marsinvasion Si es posible, ¿puede imprimir la salida de uname -a en ambos sistemas probados?

VM: Ubuntu 14.04
Linux ubuntu 3.19.0-25-generic # 26 ~ 14.04.1-Ubuntu SMP Vie 24 de julio 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 Mié 11 de noviembre 11:39:30 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux

+1
Docker versión 1.9.1, compilación a34a1d5 en OS X 10.11.1

Encontrado en OS X 10.9.5 con Docker 1.9.1.

Inspirado por @marsinvasion , obtuve una solución exitosa al darle a mi máquina acoplable 2 CPU y 4096 Mb de RAM.

Vaya, hablé pronto. Dejó de funcionar al cambiar un Dockerfile en el que estoy trabajando y al volver a ejecutar la compilación.

También viendo este error espantoso (docker-machine boot2docker 1.9.1 en OS X), de una imagen de ubuntu: 15.04 compilada previamente. Parece que es necesario reiniciar mi servidor Docker para que esos contenedores zombies desaparezcan.

Pensé que https://github.com/docker-library/java/issues/19 estaba relacionado, pero tal vez no, aquí nos estamos agarrando, ahí tienen un error sobre no encontrar "java".

Cambié mi servidor a superposición como solución. Antes de eso, también creó un montón de contenedores zombies.

Docker versión 1.9.1, compilación a34a1d5 en OS X 10.11.1

Alguien sabe lo que implica migrar un sistema boot2docker.iso existente a https://docs.docker.com/engine/userguide/storagedriver/overlayfs-driver/ o ¿es más fácil hacer una reconstrucción completa? Esa página tiene advertencias ominosas sobre las compilaciones de imágenes de CentOS: ¿cuáles son las soluciones alternativas "yum", está relacionada con https://github.com/docker/docker/issues/10180?

Está arreglado en 1.9.1a - instálelo si está en OSX - https://github.com/docker/toolbox/releases/download/v1.9.1a/DockerToolbox-1.9.1a.pkg

Definitivamente no lo soluciona Docker Toolbox 1.9.1a. Sufriendo de este error con esa versión. Mirando hacia atrás a través de los comentarios, parece que no soy el único.

no, todavía no se está construyendo

Tuve que eliminar la máquina virtual en virtualbox y empezar de cero para que funcionara.

Además, intenté eliminar y crear una nueva máquina virtual varias veces sin éxito.

Instaló 1.9.1a, hizo docker-machine rm default y usó Docker Quickstart Terminal para regenerar la máquina predeterminada. Imágenes reconstruidas (que derivan de java:7-jre ) y ejecutadas, todavía no funcionan. Continúa funcionando bien con la máquina de superposición construida como se sugirió anteriormente:

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

^ gracias! Puedo confirmar que la máquina de superposición está funcionando.

El uso de overlay como controlador de almacenamiento del motor también funcionó para solucionar el bloqueo del cierre de MongoDB.

Puede solucionar el error de compilación de Dockerfile instalando Oracle java en lugar de 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

Pero estaba subestimando el alcance del problema, boot2docker 1.9.1 conduce a procesos java zombies, incluso en contenedores CentOS donde openjdk se instala bien.
root 322 11.1 0.0 0 0 ? Zsl 18:43 29:48 [java] <defunct>

No puedo configurar mi servidor Docker con --engine-storage-driver overlay porque creo imágenes basadas en CentOS, y overlayfs no es compatible con yum (https://github.com/ docker / docker / issues / 10180).

Estoy seguro de que la gente de Docker _no_ recomendaría esto, pero la forma en que superé este problema de bloqueo fue compilando un boot2docker.iso que usa docker 1.9.1 con un AUFS un poco más antiguo. Instrucciones en https://github.com/boot2docker/boot2docker/issues/1099#issuecomment -163052066.

probé oracle jdk1.7.0_75 y jdk1.8.0_65; ambos cuelgan y crean un proceso java difunto.

DE: https://github.com/docker/docker/issues/10589
@neverfox exactamente el mismo problema aquí, con la misma imagen +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"
            }
        }
    }
}
]

Simplemente ejecuté docker run -it cassandra:2.1.11 y su terminal se atascará, no hay forma de detener el contenedor. Tienes que detener toda la VM.

+1

Fue capaz de duplicar el problema hoy en Docker 1.9.1 con Mac OSX 10.11.1 (15B42)

Pude solucionarlo instalando Docker 1.9.0

_Las disculpas por la falta de información estaban en mi máquina de trabajo más temprano durante el día; proporcionaré información actualizada en un momento posterior _

: +1:

Lo mismo ocurre con Docker 1.9.1 y OS X 10.11.

Para las personas que tienen este problema

Hasta ahora hemos reducido esto a no ser un error de _docker_, sino un problema del kernel en combinación con AUFS en el kernel que se usa en la versión actual de boot2docker; ver https://github.com/docker/docker/issues/18180#issuecomment -161832035

• Si desea mantenerse informado sobre el progreso, use el botón de suscripción en esta página. no comente si no tiene nueva información que pueda ayudar a resolver este problema.
• si desea ayudar a resolver esto, realizar un git-bissect del kernel puede ayudar https://github.com/docker/docker/issues/18180#issuecomment -161834068
• recuerda que cada comentario enviará más de 2000 correos electrónicos a los suscriptores y morirán innumerables cachorros: sonríe:

Acabo de probar Storage Driver: devicemapper (con Server Version: 1.9.1 y kernel 4.2.6), y el error _no_ se reproduce, por lo que todavía estamos en una "extraña interacción entre algún cambio en el kernel más nuevo y los parches de AUFS "tierra. :decepcionado:

Probado, y el error todavía está presente en el nuevo kernel 4.1.14 , por lo que todavía estamos sentados en una confirmación que se retroportó a 4.1.13 interactuando de manera extraña con los parches AUFS (y no tuvimos suerte con que ya se haya solucionado en el ínterin).

Decidí probarlo en la vieja universidad y cloné el repositorio boot2docker; luego modificó la confirmación de aufs en el archivo docker a la versión anterior. Entonces, docker 1.9.1 kernel 4.1.13 + versión anterior de AUFS que se envió antes de 1.9.1. La compilación es lenta en mi máquina ... ¿hay una configuración de enjambre de docker que pueda ejecutar junto con un git bisect y agregar los resultados? eso sería dulce.

De todos modos, publicaré mis resultados en breve si funciona ...

actualizar:
4.1.13 + esta confirmación AUFS todavía presenta el problema.
ENV AUFS_COMMIT 1724fe65683d126a92c6baeea0b3c7d0306c63ef

No conozco ninguna configuración fácil para agregar los resultados, aunque posiblemente se podría construir una.

FWIW, https://sources.debian.net/src/ca-certificates-java/jessie/debian/postinst.in/ es el script exacto que se ejecuta en ese paquete, y https://sources.debian.net/src /ca-certificates-java/jessie/src/main/java/org/debian/security/UpdateCertificates.java/ es la fuente Java exacta que se está ejecutando cuando obtenemos la CPU hang + difunct + pegged.

Entré en un problema relacionado (el proceso de Java se bloquea) hoy.

Entorno de host: Linux lenovo 4.2.0-19-generic # 23-Ubuntu SMP Wed Nov 11 11:39:30 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux
Distribución: Ubuntu 15.10
Motor de Docker: 1.9.1
Máquina Docker: 0.5.0 (04cfa58)

Estoy siguiendo el tutorial de red multi-host . La única diferencia es que estoy jugando con la imagen de oracle / nosql . Esa imagen está basada en Oracle Linux y usa OpenJDK.

@brunoborges sí, ese podría ser el mismo problema, consulte https://github.com/docker/docker/issues/18500#issuecomment -163334612

@brunoborges simplemente verifique su versión boot2docker.iso - si es 1.9.1 puede intentar bajar a 1.9.0 y recrear su máquina y extraer imágenes una vez más.
Si va por este camino, ¿podría escribir un breve informe aquí?

Entonces me pregunté por qué esto solo sucede en Java y no en otros idiomas. En una de mis publicaciones anteriores pude detallar las reproducciones más básicas simplemente compilando y ejecutando

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

para el caso de falla que resultó en un proceso java inactivo
y entonces

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

para el caso esperado (no difunto).

Luego intenté reproducir algo similar usando Python. No tuve éxito, pero lo intenté. Para aquellos interesados, estaba tratando de exhibir la última salida de strace exit_group(0) = ? que se vio en el proceso zombie java. (Este enlace me proporcionó mucha información sobre Python Threading / seccomp / etc http://stackoverflow.com/questions/25678139/how-do-you-cleanly-exit-after-enabling-seccomp-in-python)

Así que vamos a la tierra del kernel: después de reconstruir la iso de boot2docker, jugando con las versiones aufs y las versiones del kernel (nada de lo cual realmente hizo una diferencia), me cansé de lo lento que era el proceso de compilación usando numproc = 1. Así que lo cambié a 6. ==> nota que ya no hay 1 cpu (¿quién solo tiene 1 cpu ahora al día?). De repente, el caso de fracaso

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

comenzó a trabajar.

Obviamente, lo siguiente que debe intentar fue reducirlo a 1 cpu. ==> FALLO. de nuevo a un proceso de Java extinto.

Entonces, quería explorar más sobre cómo se apaga Java. No está bien definido. pero con solo 1 cpu, este proceso de Java se pudo ejecutar con éxito: (por favor, no se burle de mi horrible Java).

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) {}

¿Alguien más puede confirmar este comportamiento? << la pregunta ahora es discutible

Actualización: incluso con más de un núcleo, puede ocurrir un proceso de Java inactivo. (Estaba ejecutando cassandra-cli y sucedió).

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

Tener el mismo problema de bloqueo al construir bitbucket-server - update-ca -ificates funciona bien, pero el posthook de jdk se bloquea para siempre. Solo un problema cuando se usa el 1.9.1 boot2docker. Cambié a la imagen de RancherOS y no tuve problemas. OSX 10.10.

Con El Capitan, Docker 1.9.1 y Ubuntu 14.04.1 obtengo: Configuración de ca -ificates-java que se cuelga infinitamente.

@stremlenye retrocedió a 1.9.0. Todavía cuelga.

@brunoborges docker 1.9.0 o boot2docker.iso 1.9.0?

@stremlenye Docker 1.9.0 ... ¿cuáles son las instrucciones para obtener boot2docker.iso 1.9.0 en mi sistema?

@brunoborges Mira este comentario arriba:

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

carsten-ulrich-saitow-ag explica cómo crear una nueva máquina acoplable con la iso 1.9.0 usando el indicador --virtualbox-boot2docker-url. ¡Ese consejo me salvó el tocino! Una vez que hice eso, pude volver a instalar mi JRE RPM en mis contenedores.

@ mobsy74 @stremlenye intentó con boot2docker 1.9.0 y a veces se cuelga.

@brunoborges Gracias por intentarlo. Así que me quedaré con 1.8.3 hasta que se solucione este error.

@stremlenye, ¿ te refieres a boot2docker 1.8.3?

@brunoborges si

Hola,
Tuve el mismo problema.
El problema se resolvió al degradar las herramientas de Docker de 1.9.1 a 1.9.0
https://github.com/docker/toolbox/releases/download/v1.9.0/DockerToolbox-1.9.0.pkg

Habilitar múltiples cpus (en la máquina acoplable) resolvió esto por mí.

--virtualbox-cpu-count=4

@heiths , ¿puedes compartir versiones de las herramientas de Docker?

En mi humilde opinión, boot2docker debería alejarse de aufs a uno de los otros controladores de almacenamiento disponibles. Hay una buena razón por la que aufs nunca llegó al kernel de Linux.

@robvanmieghem cada conductor tiene sus limitaciones. Aufs es bastante estable en general y overlayfs tiene algunos problemas de bloqueo (según el uso)

@brunoborges DockerToolbox-1.9.1c: esto me ha funcionado en windows y osx.

@thaJeztah nunca dijo que overlayfs es la solución perfecta. Sin embargo, creo que btrfs es una buena opción para boot2docker, boot2docker está dedicado a ejecutar contenedores docker y, además del hecho de que btrfs es totalmente compatible con el kernel de Linux, es realmente fácil ver el contenido.

Hay tantas opiniones sobre esto como combinaciones de distribución y sistema de archivos :) Ninguna solución será perfecta para todos los casos de uso, así que en el espíritu del código abierto y Linux, creo que la mejor decisión es proporcionar mejores soporte para múltiples opciones de distribución. Ya tenemos la opción de Boot2Docker o RancherOS y creo que se hizo algo de trabajo para reconstruir boot2docker en una distribución debian. docker-machine admitirá ubuntu en la nube y bare metal, por lo que estoy seguro de que una vm iso basada en ubuntu no sería difícil de combinar, así como otras como una construida en alpine o CoreOS, etc. Luego, para cada uno de ellos hay la elección del sistema de archivos: nuevamente, RancherOS ahora ofrece ZFS como una instalación opcional, mientras que CoreOS solía usar BTRFS de forma predeterminada y creo que sigue siendo una opción y, a partir del kernel 3.19, Ubuntu admite OverlayFS listo para usar, cualquiera que esté listo para un Snappy Core basado imagen b2d? ;)

Ahora, si tan solo pudiéramos estandarizar el nombre de los parámetros docker-machine y eliminar las referencias a 'boot2docker' para reducir la confusión, usar el parámetro boot2docker-url para instalar RancherOS es algo poco intuitivo;)

@ azul lejano +1

@heiths +1. Esto también me lo resolvió en OSX con 1.9.1c

Establecer CPU en> 1 evita el problema para mí. 1.9.1c no ayudó.

@heiths @fredriksvensson De hecho, este problema apareció aleatoriamente en el entorno de varios contenedores y también intenté aumentar la cantidad de CPU (memoria también, pero eso no es un punto). Un par de ciclos de stop <all> / start <all> mostraron que el problema no ha desaparecido. Le recomendaría que verifique su entorno de la misma manera para asegurarse de que la solución sea estable para usted.
/ cc @timechanter

Oh, definitivamente no se ha ido. Pero el 10% de probabilidad de colgarse frente al 100% de colgar es al menos manejable a corto plazo.

@heiths --virtualbox-cpu-count=4 también funcionó para mí.

@timechanter +1 Configurar las CPU en> 1 me ha evitado el problema al menos una vez; parece una solución eficaz en este momento.

OSX 10.10.5

Caja de herramientas de Docker desinstalada 1.9.1. La degradación a la caja de herramientas de Docker 1.9.0 funcionó para mí.

Mismo problema en El Capitan MacOSX

@heiths --virtualbox-cpu-count=4 también me funciona.

Me sucedió en Windows 7 con Docker Toolbox 1.9.1by 1.9.1e.

"Configurando ca-certificate-java (20130815ubuntu1) ..." - El Capitan MacOSX. ¡¡¡Por favor ayuden, chicos !!! No puedo arreglarlo

@ troian88 degrada a boot2docker.iso 1.9.0 o 1.8.3.

@ troian88 , use una máquina acoplable con múltiples cpu.

Puede confirmar que --virtualbox-cpu-count=2 es una solución temporal en un Setting up ca-certificates-java colgante con Docker 1.9.1

Para las personas que tienen este problema

Hasta ahora hemos reducido esto a no ser un error de _docker_, sino un problema del kernel en combinación con AUFS en el kernel que se usa en la versión actual de boot2docker; ver https://github.com/docker/docker/issues/18180#issuecomment -161832035

• Si desea mantenerse informado sobre el progreso, use el botón de suscripción en esta página. no comente si no tiene nueva información que pueda ayudar a resolver este problema.
• si desea ayudar a resolver esto, realizar un git-bissect del kernel puede ayudar https://github.com/docker/docker/issues/18180#issuecomment -161834068
• recuerda que cada comentario enviará más de 2000 correos electrónicos a los suscriptores y morirán innumerables cachorros: sonríe:

@externl @stremlenye Gracias.

Mirando las pilas de LWP, encontré que el error es causado por aufs_destroy_inode .

Buscaré más en esto.

Parece ser un punto muerto relacionado con 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

La gente dice que el error se puede evitar cuando se ejecuta en varias CPU.
Sin embargo, todavía puedo solucionar el error con mi caja física de 4 CPU. (aunque <1% de probabilidad).
Entonces --virtualbox-cpu-count=2 _NO_ garantiza que puede evitar el error.

Tenga en cuenta que la cantidad de CPU sigue siendo importante.
Puedo detectar el error de manera determinista cuando ejecuto taskset 0x1 java . ( taskset asigna CPU particulares al proceso).

@AkihiroSuda muchas gracias por investigar esto. ¡Que nos mantengais! :corazón:

Tenga en cuenta que este problema también ocurre en Windows 7 cuando se utiliza Docker 1.8.3.

Estamos viendo lo mismo (exactamente los mismos rastros de pila que en el comentario de AkihiroSuda anterior) en los núcleos más antiguos:
Linux 3.19.0-42-generic #48~14.04.1-Ubuntu SMP x86_64 con Docker version 1.9.1, build a34a1d5

Puedo confirmar la afirmación de @AkihiroSuda sobre múltiples CPU: también lo

Esa depuración de AUFS parece realmente interesante; quizás valga la pena presentar un problema con AUFS y ver si los encargados de mantenimiento de AUFS pueden ayudar a depurar. Probablemente sería útil para ellos si pudiéramos reproducir solo con AUFS (sin Docker), pero eso no es exactamente trivial. :sonreír:

@tianon Hice una publicación sobre aufs-users: http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/5335

@AkihiroSuda , he visto que esto se bloquea con un caso de uso que no es de Java. Es decir, intentar cerrar un demonio MongoDB bifurcado. Esto no ocurre en el inicio de MongoDB o en el uso regular, pero ocurre de manera confiable al apagar.

@jakirkham Gracias, parece que se necesita una configuración de hilo específica (tiende a aparecer en Java, MongoDB y tal vez en otras cosas) para activar el error.

Por cierto, pensándolo bien, tal vez el bloqueo de AUFS sea un "resultado" del error en lugar de "la causa" del error.
Estoy investigando este tema: http://www.serverphorums.com/read.php?12 , 673905
(No noté que zap_pid_ns_processes() también estaba colgado hace dos días, porque había usado bash como el proceso de inicio en ese momento. Https://github.com/docker/docker/issues/18180#issuecomment- 166186061)

https://github.com/docker/docker/issues/18180#issuecomment -161843456
@andrewgdavis , ¡tienes razón!

El error parece ser una regresión causada por la confirmación 296291cd al kernel de Linux ( mm/filemap.c ).

Hice un Boot2Docker ISO ( boot2docker-v1.9.1-fix1.iso ) que omite el compromiso 296291cd: https://github.com/AkihiroSuda/boot2docker/releases/tag/v1.9.1-fix1

Espero que funcione para todos. : smiley:

La confirmación 296291cd produce un bucle infinito -EINTR en mm/filemap.c:generic_perform_write , que fs/aufs/xino.c:do_xino_fwrite() no puede 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() repite infinitamente, zap_pid_ns_processes() (ejecutado en otro LWP) no puede regresar desde schedule() cuando se ejecuta en un solo procesador.
Por eso estamos atacando el error.

@ gilles-duboscq
Estás encontrando el error porque Canonical originalmente retroportó la confirmación 296291cd al árbol del kernel 3.19: http://kernel.ubuntu.com/git/ubuntu/ubuntu-vivid.git/commit/?id=6b08592b8acc677d5b9bb7986343fdd6e0ad3303

@AkihiroSuda wow, ¡gracias por encontrarlo! ¿Cuáles son los siguientes pasos? ¿Debería revertirse ese parche o hay alguna forma de mejorarlo? ¿Está pensando en enviar un parche al núcleo en sentido ascendente?

@AkihiroSuda , tu solución funciona de

@thaJeztah

Esa no es una pregunta fácil.
Sin la confirmación 296291cd, sendfile(2) puede ser imposible de matar.
Me temo que este sendfile imposible de matar puede causar un problema de seguridad (es decir, un ataque de agotamiento del proceso por parte de un usuario anónimo) en algunos entornos determinados.

Estoy tratando de mejorar el compromiso 296291cd, pero puede llevar un tiempo.

De todos modos, informé este error al kernel bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109971

También hice un contenedor Docker akihirosuda/test18180 para facilitar la depuración: 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, está bien, suena como un problema, sí. Muchas gracias por el repro-contenedor y la investigación; al menos hay una tarea muy específica en la que trabajar, es de esperar que otras personas se unan para ayudar a encontrar una solución. Muchas gracias por su excelente trabajo hasta ahora.

Me golpearon en OS X El Capitan Darwin Kernel Versión 15.2.0
Docker versión 1.9.1, compilación d12ea79c9de6d144ce6bc7ccfe41c507cca6fd35
boot2docker 1.9.1

La degradación a boot2docker 1.9.0 con los siguientes comandos funcionó para mí:

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 admitirá 296291cd.
http://article.gmane.org/gmane.linux.file-systems.aufs.user/5343

Entonces, el siguiente paso es esperar la actualización de AUFS.

¡Eres un héroe, @AkihiroSuda! ¡Gracias por trabajar con Upstream para resolver esto! :corazón:

Si alguien quiere aplicar la corrección de @AkihiroSuda , esto funciona como un encanto:

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 cualquier persona en Ubuntu 14.04, la degradación al kernel 3.13.0-71 o anterior debería resolver el problema. 296291cd se exportó después de eso .

@ebpitts gracias por la sugerencia, aquí están los pasos algo relativos para degradar el kernel de Ubuntu 14.04 a 3.13.0-71 con 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

En este punto, debería tener dos núcleos para elegir durante la carga de arranque. Sin embargo, estaba ejecutando en una caja Vagrant remota a través de SSH, así que no tengo el cargador de arranque GRUB ... así que eliminé el kernel predeterminado más nuevo (3.13.0-74 en mi caso) como una opción de arranque:

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

La salida del comando tenía algunas cosas sobre la actualización de Grub, por lo que puede inspeccionar /boot/grub/grub.cfg y ver cuál será la opción de arranque predeterminada al reiniciar. Parece que tuve que hacer esto para eliminar / volver a agregar los encabezados, pero una vez que el archivo grub.cfg veía bien ( 3.13.0-71-generic era la única y primera opción de inicio), continúe y reinicie:

sudo reboot

Y, luego, vuelva SSH a mi caja:

$ uname -r
3.13.0-71-generic

Pero ahora parecía que Docker no estaba funcionando. Entonces, la reinstalación completa requiere la eliminación primero:

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

Y, honestamente, en mi próximo intento de ejecutar un docker build en el mismo contenedor que estaba colgado en el título OP ("Configuración de ca -ificates-java"), _todavía_ murió y esta vez bloqueó mi máquina , pero ahora que no tengo acceso SSH, iré a casa y esperaré hasta 2016 para intentar ver si alguien más tiene una solución mejor para entonces = /

Entonces ... no puedo afirmar que incluso después de degradar el kernel a 3.13.0-71 después de encontrar este problema en Ubuntu 14.04 + Docker 1.9.1 sea efectivo. ¡Qué asco!

Sí, solo para confirmar dos veces, ejecuté $ docker run -it --rm akihirosuda/test18180 y todavía se cuelga.

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

Esto es después de degradar Ubuntu 14.04 a la versión del kernel 3.13.0-71 con 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 ¿estás seguro de que la degradación del kernel en Ubuntu es realmente la solución?

Interesante, incluso cuando configuro el controlador de almacenamiento explícitamente devicemapper en /var/default/docker :

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

y reinicie el servicio Docker, ejecutando 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

Todavía cuelgo en la imagen de prueba akihirosuda/test18180:latest .

Bajé a Docker 1.8.3 (no tan fácil sin apt-get ) en mi caja de Ubuntu 14 usando el binario sin procesar, aquí están los pasos ... para cualquier otra persona ... Estoy de vuelta en el negocio (por favor tenga en cuenta que también bajé el kernel a 3.13.0-71-generic anteriormente, ver más arriba)

Instalé el binario 1.8.3 desde https://get.docker.com/builds/Linux/x86_64/docker-1.8.3 , luego lo moví a /usr/bin/docker , le di sudo chmod +x /usr/bin/docker permisos ejecutables.

Luego, tomé el script sin procesar sysvinit-debian , comenté el cuerpo check_init() y lo reemplacé simplemente con echo '' y lo coloqué en /etc/init.d . Luego lo configuré para que se ejecutara en el arranque como root con ln -s /etc/init.d/docker /etc/rc2.d/S99docker , y ejecuté sudo reboot . Después de eso, vuelvo a ejecutar el servicio Docker 1.8.3 al arrancar desde una instalación binaria. No sé por qué estos pasos no están realmente documentados en la página de instalación binaria en el sitio web de Docker. De todos modos.

$ 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

Todo se ve bien aquí: puedo ejecutar $ docker run -it hello-world correctamente. Ejecutar akihirosuda/test18180 todavía se cuelga en realidad (???) pero puedo construir y ejecutar mi contenedor original sin quedarme atascado en Setting up ca-certificates-java , lo que me trajo aquí en primer lugar.

Como referencia, estoy en Ubuntu 15.04 vivid, Linux 3.19.0-42-generic. También afectado.

Como no puedo usar la superposición (necesito invitados RHEL), creé una partición btrfs en una unidad de repuesto y la @akihirosuda todavía se cuelga en la segunda verificación (extraño).

@mikeatlas
Gracias por probar mi imagen test18180 .

El resultado no es extraño.
El segundo cheque ( Checking whether sendfile(2) is killable. ) cuelga en kernels antiguos.
Necesita un kernel más nuevo con 296291cd para pasar la segunda verificación.

| AUFS? | Kernel incluye 296291cd? | Resultado esperado |
| --- | --- | --- |
| Y | Y | Cuelga (1er cheque: Checking whether hitting docker#18180. ) |
| Y | N | Cuelga (2do cheque: Checking whether sendfile(2) is killable. ) |
| N | Y | Pase |
| N | N | Cuelga (2do cheque: Checking whether sendfile(2) is killable. ) |

@cfstras Gracias, lo investigaré.

@cfstras , es reproducible y abrí # 19073.

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

EDITAR:
Anteriormente, estaba equivocado acerca de por qué Docker no funcionaba después de cambiar las versiones del kernel, pero puedo confirmar que la instalación del paquete adicional para mi kernel y luego volver a instalar Docker resolvió este problema para mí:

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 interesante, linux-image-extra-3.13.0-71-generic no es un paquete que pensé instalar (pero instalé los paquetes adicionales genéricos después, como se señaló) ... pero aún así, tenía la impresión de que el módulo AUFS es mucho más antiguo que solo el relativamente reciente 3.13.0-71 kernel. Independientemente, degradar a Docker 1.8.3 tampoco fue demasiado doloroso, y si tuviera que pasar por el proceso nuevamente, preferiría degradar Docker en lugar de degradar el kernel de Linux cualquier día de la semana.

@dschep Tenga en cuenta para otros que cambiar a OverlayFS requiere la versión del kernel 3.18 + en Linux, y como se cita en la página de Docker, _Por muy prometedor que sea OverlayFS, todavía es relativamente joven.

@mikeatlas Supongo que esta es la mayor limitación hasta ahora en OverlayFS: "_Por lo tanto, es poco probable que el uso de yum dentro de un contenedor en un host de Docker con el controlador de almacenamiento de superposición funcione sin implementar soluciones alternativas".

@brunoborges yum está siendo parcheado para trabajar en overlayfs, por lo que, pronto, las versiones más nuevas de yum deberían poder funcionar en overlayfs (sin embargo, todavía habrá algunos problemas, por lo que depende de su caso de uso / situación en la que se encuentre ellos). El uso excesivo de inodo puede ser otro problema.

Creo que también estoy experimentando este problema. El seguimiento de llamadas menciona apparmor, pero desactivarlo no hace ninguna diferencia. El uso de devicemapper hizo que el problema desapareciera.

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>

Esto se solucionó en AUFS upstream: boot2docker se ha actualizado para incluir la solución (que saldrá con la próxima versión), y cualquier usuario que no sea boot2docker y que se vea afectado debe aplicar la versión actualizada de AUFS. : +1:

@tianon , ¿tiene alguna referencia a los errores ascendentes?

http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/5345 es el anuncio de lanzamiento ascendente, no estoy seguro de si hay más discusión que esa

http://comments.gmane.org/gmane.linux.file-systems.aufs.user/5337 tiene más información sobre el tema.

¡gracias!

Esto se solucionó en AUFS upstream: boot2docker se ha actualizado para incluir la solución (que saldrá con la próxima versión), y cualquier usuario que no sea boot2docker y que se vea afectado debe aplicar la versión actualizada de AUFS. : +1:

Agradable.

¿Se utilizó la versión con errores de AUFS en Docker Hub?

@tianon "Aplicar la versión actualizada de AUFS" significa para los usuarios que no son boot2docker (todos los que ejecutan el motor de Docker _no_ en desarrollo en Mac OS X, para el cual está construido b2d, principalmente) que tendrán que esperar una actualización del kernel de Linux con este parche AUFS ... O ... considerando cuántas instalaciones / personas parecen verse afectadas, ¿alguien podría proporcionar instrucciones simplificadas / mínimas sobre cómo parchear AUFS a 4.1.13+? La guía para 4.1.13+ definitivamente no es trivial de leer; parchear el kernel de Linux uno mismo para esta solución específica no es exactamente para los débiles de corazón.

Solo para que entiendo que si construyo este boot2docker.iso y lo coloco en ~/.docker/machine/cache y creo una nueva VM con docker-machine esa VM usará esta nueva copia de boot2docker .

Solo para que entiendo que si construyo este boot2docker.iso y lo pongo en ~ / .docker / machine / cache y creo una nueva VM con docker-machine, esa VM usará esta nueva copia de boot2docker.

Técnicamente sí, eso funcionaría, pero una mejor opción podría ser usar --virtualbox-boot2docker-url , por ejemplo:

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

Ah, está bien, gracias por aclarar. Bueno, esto parece estar funcionando entonces.

Envió una solicitud para actualizar AUFS a Canonical: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043

¿Va a haber una nueva versión de boot2docker, ya que 1.9.1 no parece tener la solución?

editar. con la imagen de @AkihiroSuda boot2docker, pude continuar. ¡Gracias a todos!

Sí, esta solución es posterior a 1.9.1. @tianon dijo que se planea un lanzamiento. Normalmente, sale al mismo tiempo que docker sale para su lanzamiento. Como tienden a seguir un ciclo de 2 semanas en los lanzamientos, espero que el lanzamiento sea inminente. Mientras tanto, @AkihiroSuda creó una solución que puede usar o puede crear la suya propia, lo cual es realmente sencillo y solo lleva tiempo.

Gracias @AkihiroSuda por la imagen, ¡funciona! :)

+1 Debian Wheezy y Ubuntu 15.04

El lanzamiento de

Oh, lo siento, debe haberlo mezclado. Gracias por aclararme, @tiborvass. ¿Entendiste eso, @shusso?

@jakirkham Lo hice, gracias: +1:

Pude crear una caja virtual de host de máquina acoplable usando esta solución:

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

Actualmente, los hosts de docker-machine que creo en el motor de cálculo de Google, con la opción --driver google, parecen tener este problema. No hay ninguna opción con el controlador de Google para especificar un .iso diferente, por lo que no puedo usar la solución anterior en Google Compute.

¿Alguien sabe de alguna solución? o de hecho si Google está al tanto del problema, o dónde debería presentar un informe de error para ellos.

¿El controlador de la máquina acoplable de Google lo mantiene Docker o Google?

El controlador se puede encontrar aquí; https://github.com/docker/machine/tree/master/drivers/google

Creo que la imagen de VM que se está ejecutando en Google Compute debe ser esta aquí:

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

Es decir:

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

Al examinar lo anterior, parece que una posible solución alternativa podría ser la sugerida por @nathanleclaire

$ docker-machine create -d google: superposición de superposición de controlador de almacenamiento de motor

También parece haber una opción "--google-machine-image" disponible para el controlador de Google para docker-machine. El comando:

Lista de imágenes de $ gcloud compute

Muestra las imágenes públicas disponibles. Noto que recientemente se ha puesto un nuevo ubuntu wily.

Solo para confirmar:

$ docker-machine create -d google: superposición de superposición de controlador de almacenamiento de motor

Trabajó. También investigaré la creación de una imagen de máquina personalizada usando el boot2docker fijo, y trataré de conectarlo con docker-machine.

A cualquiera que haga clic en esto en boot2docker, entregue el RC a
https://github.com/tianon/boot2docker-legacy/releases/tag/v1.10.0-rc1 a
Disparo. : +1:

@tianon lo pruebo con la siguiente imagen trecloux / docker-java-zombie
Y se ve bien ... pero todavía se cuelga con la imagen akihirosuda / test18180

Un trabajo realmente impresionante cazador de errores persistente !!

@trecloux, ¿estás usando btrfs y te cuelgas para sendfile?
Si es así, es un problema conocido: https://github.com/docker/docker/issues/19073

@AkihiroSuda Estoy usando la imagen boot2docker v1.10.0-rc1 con 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

Aquí está el resultado de su imagen de prueba:

$ 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 Es el comportamiento esperado. Nada está colgando.

@AkihiroSuda Ok, lo siento. Y gracias por tu esfuerzo :-)
Entonces @tianon : 1.10.0-rc1 se ve bien.

el mismo problema aqui. Cuelga la configuración de certificados CA, la CPU se vuelve loca ...

$ 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

ejecutando MacOSX 10.11.2

@sgoendoer intenta usar la imagen de @AkihiroSuda con docker-machine create --driver virtualbox --virtualbox-boot2docker-url="file:/path_to_the_image" nameofmachine

para usuarios que no son de boot2docker, ¿alguna idea con qué versión del kernel se solucionará? 3.13.0-71 parece funcionar, 3.13.0-74 y 3.13.0-76 parecen estar rotos ...

El mismo problema aquí; ¿Entonces no hay una solución fácil para esto?
¿Está esto arreglado en la versión RC? Probando ese ahora. Aunque probablemente cause otros problemas.

ÚLTIMAS SOLUCIONES RÁPIDAS (Actualización: 21 de enero a las 15:33 UTC)

| Distro | Solución alternativa |
| --- | --- |
| General | Utilice devicemapper / overlay / btrfs (pero puede causar otro problema ..) |
| Boot2Docker | : white_check_mark: Actualice a v1.10.0-rc1 |
| Ubuntu 14.04LTS | : arrow_down: degrada el kernel a 3.13.0-71 o anterior |
| Ubuntu 15.04 | : arrow_down: degrada el kernel a 3.19.0-39 o anterior (: advertencia: no probado) |
| Ubuntu 15.10 | : arrow_down: degrada el kernel a 4.2.0-18 o anterior |
| Debian 7/8 | : arrow_down: degrada el kernel a la versión 3.16.7-ckt11 de la versión 3.16.0 ( apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 ) o anterior |
| Debian 9 | : white_check_mark: (no es compatible con AUFS desde el kernel 3.18-1 ~ exp1) |
| Gentoo | : white_check_mark: Actualice a los más recientes (: advertencia: no probado) |
| RHEL / CentOS | : white_check_mark: (no es compatible con AUFS) |
| openSUSE | : white_check_mark: (no es compatible con AUFS) |

Distribuidores emiten tickets

| Distro | Estado | Emitir URL |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: Cerrado | https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | : white_medium_square: En curso | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | Aún no confirmado | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

@AkihiroSuda v1.10.0-rc1 no solucionó los zombies por mí, ¿alguien que también tenga el 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)   

Después de iniciar strace en el proceso difunto después de un tiempo, esto apareció, pero después de esto, el zombi todavía 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>

Esta vez ya no se puede acceder a través de strace, supongo que todavía está adjunto, incluso si no lo está.
: ~ # strace -p 23810

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

@wzrdtales
¿Podría obtener pilas LWP como en https://github.com/docker/docker/issues/18180#issuecomment -166186061?
Además, ¿cuál es su cmdline y versión de phantomjs?

Seguro, versión de phantomjs: 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

Y también la pila de tareas:

:~# 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

También para agregar información del 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 ¿Está usando Docker (no Boot2Docker) v1.10.0-rc1 en Debian?
No funciona porque el problema es un error del kernel en lugar de Docker.

Estoy investigando los núcleos de Debian y actualizaré la lista https://github.com/docker/docker/issues/18180#issuecomment -173436661.

@AkihiroSuda y, está directamente en debian. He supervisado el punto debian en su lista, gracias por señalarlo :)

Para debian, no deberíamos usar kernels basados ​​en 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 Actualicé la lista, use el kernel ckt11.

@AkihiroSuda : FWIW, creo que la recomendación de degradar a v3.16.7-ckt11 pone en riesgo de CVE-2016-0728, que tiene una escalada de raíz pública conocida. Acabo de hacer ping a https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 , pero para tu información, antes de degradar.

@zmerlynn ¡ Gracias por señalar eso!

ÚLTIMAS SOLUCIONES RÁPIDAS (Actualización: 26 de enero a las 1:49 UTC)

| Distro | Solución alternativa |
| --- | --- |
| General | Utilice devicemapper / overlay / btrfs (pero puede causar otro problema ..).
Si puede actualizar AUFS y compilar el kernel manualmente, también puede usar AUFS v20160111 o posterior. |
| Boot2Docker | : white_check_mark: Actualice a v1.10.0-rc1 |
| Ubuntu 14.04LTS | : arrow_down: degrada el kernel a 3.13.0-71 o anterior |
| Ubuntu 15.04 | : arrow_down: degrada el kernel a 3.19.0-39 o anterior (: advertencia: no probado) |
| Ubuntu 15.10 | : arrow_down: degrada el kernel a 4.2.0-18 o anterior |
| Debian 7/8 | : arrow_down: degrada el kernel a la versión 3.16.7-ckt11 de la versión 3.16.0 ( apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 ) o anterior |
| Debian 9 | : white_check_mark: (no es compatible con AUFS desde el kernel 3.18-1 ~ exp1) |
| Gentoo | : white_check_mark: Actualice a los más recientes (: advertencia: no probado) |
| RHEL / CentOS | : white_check_mark: (no es compatible con AUFS) |
| openSUSE | : white_check_mark: (no es compatible con AUFS) |

: advertencia: la degradación del kernel puede ser un riesgo de seguridad (p. ej., CVE-2016-0728)

Distribuidores emiten tickets

| Distro | Estado | Emitir URL |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: Cerrado | https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | : white_medium_square: En curso | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | : white_medium_square: En curso | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

También encontramos este problema, mongod está atascado en el estado R ejecutándose con un 100% de CPU.

Aquí está el verdadero truco para obtener el seguimiento de pila correcto que me lleva aquí:

echo "l"> / proc / sysrq-trigger

desde allí, puede ver que la CPU 2 está atascada en un bucle infinito por 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

buscar por do_xino_fwrite me lleva aquí!

Parece que también me encuentro con este problema en Debian Stretch, donde se cuelga de la configuración de certificados.

Aquí está el mensaje de error: https://gist.github.com/clball/738feb46094802a1bcf7
Aquí está la información de la versión: https://gist.github.com/clball/494fe8598dd0cdfd6d10
Aquí está el dockerfile: https://gist.github.com/8778f8db143478d6c8ab

Entonces, ¿cuál es la solución para OSX aquí? ¿Ya hay una actualización de Docker?

Todavía no, pero hay un candidato de lanzamiento. (https://github.com/tianon/boot2docker-legacy/releases/tag/v1.10.0-rc2)

La solución para mí fue cambiar el backend de almacenamiento.

Agregue una línea a / etc / default / docker
¡¡CUIDADO perderás los datos de tu contenedor !!

DOCKER_OPTS="--storage-driver=devicemapper"

Recomiendo detener el servicio de Docker, borrar la carpeta de Docker en / var / lib y luego agregar la línea y reiniciar el servicio de Docker.

@ referup-tarantegui solo como aviso, el controlador devicemapper se considera terriblemente deficiente para el rendimiento a menos que se monte directamente en discos físicos reales. Ver
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-no-tan-profundo-en-docker-storage-drivers.html # 44
y
https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/ "Device Mapper and Docker performance"

Existe una versión B para la versión candidata2

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

Se actualizó la tabla sobre Ubuntu.

ÚLTIMAS SOLUCIONES RÁPIDAS (Actualización: 3 de febrero a las 6:30 UTC)

| Distro | Solución alternativa |
| --- | --- |
| General | Utilice devicemapper / overlay / btrfs (pero puede causar otro problema ..).
Si puede actualizar AUFS y compilar el kernel manualmente, también puede usar AUFS v20160111 o posterior. |
| Boot2Docker | : white_check_mark: Actualice a v1.10.0-rc3 |
| Ubuntu 14.04LTS | : white_check_mark: Actualice el kernel a 3.13.0-77.121hf1533043v20160201b1 (PPA) |
| Ubuntu 15.04 | : white_check_mark: Actualice el kernel a 3.19.0-49.55hf1533043v20160201b1 (PPA) |
| Ubuntu 15.10 | : white_check_mark: Actualice el kernel a 4.2.0-27.32hf1533043v20160201b1 (PPA) |
| Debian 7/8 | : arrow_down: degrada el kernel a la versión 3.16.7-ckt11 de la versión 3.16.0 ( apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 ) o anterior |
| Debian 9 | : white_check_mark: (no es compatible con AUFS desde el kernel 3.18-1 ~ exp1) |
| Gentoo | : white_check_mark: Actualice a los más recientes (: advertencia: no probado) |
| RHEL / CentOS | : white_check_mark: (no es compatible con AUFS) |
| openSUSE | : white_check_mark: (no es compatible con AUFS) |

Distribuidores emiten tickets

| Distro | Estado | Emitir URL |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: Cerrado | https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | : white_medium_square: En proceso (ETA: 20 de febrero) | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | : white_medium_square: En curso | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

@AkihiroSuda , creo que te referías a v1.10.0-rc2 para boot2docker o quizás se suponía que el enlace iba aquí (https://github.com/boot2docker/boot2docker/releases/tag/v1.10.0-rc3).

@jakirkham Gracias, arregló el enlace.

rc3 está en el repositorio oficial en lugar de mi bifurcación:
https://github.com/boot2docker/boot2docker/releases/tag/v1.10.0-rc3

Investigamos la deuda tecnológica que nos obligó a usar mi tenedor y descubrimos que
se ha solucionado desde la máquina acoplable 0.5, por lo que estamos avanzando y
hacia arriba. :sonreír:

Por cierto, para aquellos que buscan cambiar los núcleos a las versiones parcheadas de chiluk enumeradas anteriormente para los PPA de Ubuntu. Por ejemplo, para Ubuntu 14.04, linux-image-3.13.0-77-generic , sus pasos serían:

$ 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

Luego, deberá actualizar su configuración /etc/default/grub , luego ejecutar sudo update-grub , luego reiniciar en la nueva compilación del kernel parcheada. Si no ha hecho esto antes, aquí hay una guía sobre cómo configurar un kernel predeterminado diferente en grub .

Puedo confirmar que este problema no existe en Docker 1.10.0, que también solucionó mi situación en OS X 10.11. De lo contrario, iba a degradar a 1.9.0.

Sigo recibiendo el problema de proceso / contenedor colgado java en la ventana acoplable 1.10:

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

@AkihiroSuda Estoy probando sus soluciones rápidas (¡gracias!) Pero no puedo instalar el kernel anterior en mi servidor Debian 8 (jessie), obtengo:

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

Cuando pruebo las sugerencias de sudo apt-get install software-properties-common para que sudo add-apt-repository ppa:chiluk/1533043 funcionen) obtengo un error de actualización, y supongo que es por eso que la instalación no 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'

Mi información de 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 gracias por el consejo sobre la necesidad de software-properties-common , actualicé mi publicación anterior.

@jamshid : Después de agregar el PPA y hacer apt-get update , verifique y vea qué kernels están disponibles para su máquina ... Parece que hay una compilación más nueva ( 3.13.0-78 ) pero no veo está disponible después de ejecutar una actualización aquí. Sin embargo, así es como _puedes_ averiguar qué kernels están disponibles para instalar:

$ 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

Si no ve algo como linux-image-3.13.0-77-generic o más, algo más no debe estar bien.

Oh, @jamshid , ¿estás ejecutando Debian 8? Nota arriba: 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 en Debian 8 da

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

Una hora de búsqueda activa en Google para encontrar el paquete ckt11 no ayudó.
Por favor, ¿alguna sugerencia sobre cómo degradar el kernel de Debian 8 reciente?

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 Puedes encontrar los paquetes instalados previamente en /var/cache/apt/archives . Debería poder bajar de categoría con dpkg -i <old_package>.deb .

Confirmado que la instalación del nuevo kernel desde el PPA solucionó el problema para mí (Ubuntu 14.04.3 / Kernel 3.13.0-78-generic / Docker 1.9.1)
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043

¿Alguien ha recibido las instrucciones de degradación para trabajar con Debian (no Ubuntu)? Me pregunto si la razón por la que mi apt-get update falla con el siguiente error (después de agregar el repositorio ppa):

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

¿Es que solo los paquetes de ubuntu están disponibles en https://launchpad.net/~chiluk/+archive/ubuntu/1533043? Hmm, estoy confundido, pensé que Ubuntu estaba basado en Debian.

@jamshid Ubuntu ppa no es compatible con Debian.

Si lamentablemente 3.16.7-ckt11-1 + deb8u3 ya no está disponible, puede parchear el último kernel: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207#47

(Puedo cargar el paquete deb, si alguien lo necesita)

Si alguien necesita el kernel, lo he subido aquí, es un poco más nuevo que deb8u3, pero no parece que tenga el error, al menos no lo encontré ejecutando esto durante bastante tiempo, pero parcheando el El último kernel es probablemente la mejor solución. Sin embargo, si lo necesita:
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 aquellos como yo que todavía luchan por solucionar esto, me gustaría señalarles a TINI como una buena solución:
https://github.com/krallin/tini

con pocas líneas en el dockerfile, obtuve un proceso de inicio decente capaz de eliminar zombies.
Esto permitirá evitar la transición a devicemapper.

Salud,
Francesco

Entonces, uso tini. Sin embargo, eso no me ayudó aquí, ya que el problema que encontré fue mientras se construía la imagen.

Además, cuando ejecuto un contenedor, uso tini, pero esto aún me afecta.

@fflatorre
Gracias por la información, pero el problema de los zombies que tini puede resolver parece diferente de este problema.
https://github.com/docker/docker/issues/18180#issuecomment -167042078

De hecho, incluso con tini, podemos conseguir un zombi:

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 Me olvido de mencionar que no estamos experimentando este problema al construir la imagen. Creamos una imagen muy básica y luego la lógica de aprovisionamiento se delega a un montón de scripts ansible. Durante el aprovisionamiento, uno de los procesos (kafka) solía colgarse. TINI hasta ahora parece haber mitigado ese problema.
Reconozco que podría no ser una solución para usted, de hecho, sugeriría degradarlo de una solución alternativa a un placebo :)
Espero que podamos conseguirlo pronto.

Tuve el mismo problema al ejecutar Docker 1.9.1 en OSX 10.11.3:

$ docker -v
Docker version 1.9.1, build a34a1d5

Se corrigió la actualización a la última versión de Docker Toolbox:

$ docker -v
Docker version 1.10.1, build 9e83765

Para obtener información, enumeré algunos problemas y soluciones relacionadas con los controladores de almacenamiento AUFS / Overlay / BtrFS / ZFS / devicemapper: https://github.com/AkihiroSuda/docker-issues/

Espero que esto pueda ayudar a aquellos que estén interesados ​​en # 18180 y otros ..

@AkihiroSuda Traté de seguir el enlace https://launchpad.net/%7Echiluk/+archive/ubuntu/1533043/+packages pero no puedo ver la página.

Véase también: https://github.com/docker/toolbox/issues/318#issuecomment -184143546

@ schmunk42
Tampoco pude acceder a la página.
Creo que chiluk está rehaciendo paquetes. Puedes preguntarle en https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043

Para las personas que tienen problemas con esto, aquí se explica cómo resolver el problema en Ubuntu 14.04 utilizando el kernel propuesto . Por supuesto, esto no será relevante una vez que el núcleo se gradúe en la rama principal.

Antes de comenzar, podemos confirmar que estamos ejecutando en un kernel afectado ejecutando (es decir, <3.19.0-50 en Ubuntu 14.04):

$ uname -r
3.19.0-49-generic

Como sabemos esto, primero debemos habilitar los paquetes

$ 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

Una vez hecho esto, instalemos el kernel actualizado:

$ 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

Y reiniciemos

$ sudo shutdown -r now

Después del reinicio, podemos confirmar que las últimas se están ejecutando en el último kernel:

$ uname -r
3.19.0-50-generic

Gracias @vpetersson. Estoy tratando de averiguar qué pasará cuando se publique esta versión del kernel, ¿se sobrescribirá la instalación propuesta o tendrá que hacer algo para volver a la normalidad, por favor?

@IainColledge Sí, me imagino que ese sería el caso, pero no estoy del todo seguro.

Se actualizó la tabla sobre Ubuntu y Debian.

ÚLTIMAS SOLUCIONES RÁPIDAS

| Distro | Solución alternativa |
| --- | --- |
| General | Utilice devicemapper / overlay / btrfs (pero puede causar otro problema ..).
Si puede actualizar AUFS y compilar el kernel manualmente, también puede usar AUFS v20160111 o posterior. |
| Boot2Docker | : white_check_mark: Actualice a v1.10.0 o posterior |
| Ubuntu 14.04LTS | : white_check_mark: Actualice el kernel a 3.13.0-79.123 o posterior |
| Ubuntu 15.04 | : white_check_mark: Actualice el kernel a 3.19.0-51.57 o posterior |
| Ubuntu 15.10 | : white_check_mark: Actualice el kernel a 4.2.0-30.35 o posterior |
| Debian 7/8 | : arrow_down: degrada el kernel a la versión 3.16.7-ckt11 de la versión 3.16.0 o anterior ( archivo dpkg de @wzrdtales) |
| Debian 9 | : white_check_mark: (no es compatible con AUFS desde el kernel 3.18-1 ~ exp1) |
| Gentoo | : white_check_mark: Actualice a los más recientes (: advertencia: no probado) |
| RHEL / CentOS | : white_check_mark: (no es compatible con AUFS) |
| openSUSE | : white_check_mark: (no es compatible con AUFS) |

Distribuidores emiten tickets

| Distro | Estado | Emitir URL |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: Cerrado | https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | : white_check_mark: Cerrado | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | : white_medium_square: En curso | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

Una cosa más; Enumeré algunos errores conocidos sobre los controladores de almacenamiento: https://github.com/AkihiroSuda/docker-issues

En caso de que alguien quiera tener el último kernel de Debian "linux_3.16.7-ckt20-1 + deb8u3" con parches, mencionado anteriormente, lo construí manualmente y está en https://fxposter.org/linux-image-3.16 .0-4-amd64_3.16.7-ckt20-1 + deb8u3a ~ test_amd64.deb.

¡asombroso! He tenido este problema durante algunas semanas, y creo que la solución para Ubuntu se lanzó ayer: P

Confirmando que la última actualización del kernel 14.04LTS a 3.19.0-51 pone fin a mis zombies java. ¡Gracias!

Debian apoyó este problema.

ÚLTIMAS SOLUCIONES RÁPIDAS

| Distro | Solución alternativa |
| --- | --- |
| General | Utilice devicemapper / overlay / btrfs (pero puede causar otro problema ..).
Si puede actualizar AUFS y compilar el kernel manualmente, también puede usar AUFS v20160111 o posterior. |
| Boot2Docker | : white_check_mark: Actualice a v1.10.0 o posterior |
| Ubuntu 14.04LTS | : white_check_mark: Actualice el kernel a 3.13.0-79.123 o posterior |
| Ubuntu 15.04 | : white_check_mark: Actualice el kernel a 3.19.0-51.57 o posterior |
| Ubuntu 15.10 | : white_check_mark: Actualice el kernel a 4.2.0-30.35 o posterior |
| Debian 7 | : white_check_mark: Actualice el kernel a 3.2.73-2 + deb7u3 (del paquete linux-image-3.2.0-4-amd64) o posterior |
| Debian 8 | : white_check_mark: Actualice el kernel a 3.16.7-ckt20-1 + deb8u4 (del paquete linux-image-3.16.0-4-amd64) o posterior |
| Debian 9 | : white_check_mark: (no es compatible con AUFS desde el kernel 3.18-1 ~ exp1) |
| Gentoo | : white_check_mark: Actualice a los más recientes (: advertencia: no probado) |
| RHEL / CentOS | : white_check_mark: (no es compatible con AUFS) |
| openSUSE | : white_check_mark: (no es compatible con AUFS) |

Distribuidores emiten tickets

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

la actualización del kernel de 14.04LTS funcionó para mí: +1:

Estoy en OSX en Boot2Docker versión 1.10.2, build master: 611be10, Docker versión 1.10.2, build c3959b1 y primero obtuve esto de 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).

Luego intenté docker kill 38e1e2590dfa pero el proceso se bloquea para siempre. 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"

Solo como una nota (sé que esto está cerrado, pero no estoy seguro de si tiene sentido abrirlo como una nueva edición). Tenía el mismo problema en una versión posterior hasta que cambié a 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 El problema se solucionó en el kernel 3.13.0-79.123 (el suyo parece ser 3.13.0-77)

¿Se puede realmente resolver este problema con una actualización del Kernel? Estamos encontrando el mismo problema con Docker 1.9.1 en Ubuntu 14.04 con 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 sí, este problema era un problema del kernel. Es posible que algo más pueda resultar en un comportamiento similar, o si hay una regresión en el kernel. Sin embargo, abra un nuevo problema si tiene problemas con la versión actual; Tenga en cuenta que Docker 1.9.1 es EOL, por lo que ya no recibirá actualizaciones.

Estoy bloqueando la discusión sobre este problema, porque el problema original aquí se resolvió y quiero evitar que este problema recopile problemas posiblemente no relacionados. Vea este comentario; https://github.com/docker/docker/issues/18180#issuecomment -193708192 para las versiones del kernel necesarias para solucionar este problema