Je suis confronté au même problème. J'enquête.

Nous sommes également confrontés au même problème.

Oui, c'est un problème em docker 1.9. J'avais rétrogradé à 1.8.3 et tous les problèmes résolus. J'étudie maintenant une solution de contournement. publiera ici! Tks

J'ai le même problème avec docker 1.9.1a

J'ai docker 1.8.3, donc peut-être que le processus d'installation d'une version différente de docker remédie à la situation. @bsao.

ayant ce même problème avec docker version 1.9.1, build a34a1d5

Ne voyez-vous cela que sur boot2docker?

Je ne peux pas repo sur un ubuntu stock avec aufs ou sur ma machine. laissez-moi essayer avec boot2docker pour voir si je peux y repo.

+1 dans Docker 1.9.1 pour ubuntu: 14.10 sous OSX

C'est un problème qui a commencé à apparaître après avoir activé le VPN pour le travail. Même après avoir désactivé le VPN et redémarré la machine docker sous OSX, ce problème a continué. J'ai réinstallé Docker 1.9.1 puis 1.8.3, toujours en voyant le problème. M'empêche d'utiliser la plupart sinon la totalité de mes dockers sur Mac.

+1 dans Docker 1.9.1 pour ubuntu 12.04 sous OS X 10.11

Les développeurs de mon bureau ont également découvert cela par accident.

Cette version / build a fonctionné : Docker version 1.9.0, build 76d6bc9

Cette version / build est bloquée : Docker version 1.9.1, build a34a1d5

@crosbymichael Je

Quelqu'un avec le savoir-faire de git-bisecting et docker pourrait utiliser les ID de build fournis par @ chico1198!

J'ai rencontré le même problème avec la version 1.9.1 sur OSX El Capitan, le passage à la version 1.9.0 n'a pas aidé.

Même problème ici sur OSX 10.9.3 avec:
Docker version 1.9.1, build a34a1d5
Docker version 1.9.0, build 76d6bc9

@crosbymichael Je ps auxf , voici ce que j'ai vu:

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 avec docker 1.9.1 sur OSX 10.11 avec tentative de création d'image à partir d'ubuntu 14.04

+1
utilisez 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 mise à niveau vers Docker 1.8.3 est ma solution temporaire. Voici le target que j'utilise dans mon 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) 

Je n'ai pas pu reproduire cela. Cela se bloque-t-il toujours lors de la «configuration des certificats»? Avez-vous essayé d'envoyer un ^D pour fermer un canal? Pouvez-vous également essayer d'envoyer un SIGUSR1 au démon et coller la trace de la pile ici quand elle est bloquée?

+1 avec docker 1.9.1 sur OS X 10.10

J'ai essayé de passer à la version 1.8.3 en utilisant le Makefile de @osterman et

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

Je l'ai testé en effectuant différentes installations openjdk dans Debian: Jessie et Ubuntu
OSX 10.11.1, boot2docker 1.9.1: se bloque
OSX 10.11.1, boot2docker 1.9.0: fonctionne
Ubuntu 14.04 avec docker 1.9.1: fonctionne

Les vms boot2docker ont été créés avec:
docker-machine créer -d virtualbox --virtualbox-boot2docker-url = https://github.com/boot2docker/boot2docker/releases/download/v1.9.0/boot2docker.iso
et
docker-machine créer -d virtualbox --virtualbox-boot2docker-url = https://github.com/boot2docker/boot2docker/releases/download/v1.9.1/boot2docker.iso

Sur Ubuntu 14.04, docker a été installé en suivant la documentation sur https://docs.docker.com/engine/installation/ubuntulinux/

+1, exécutant docker 1.9.1 build a34a1d5 sur OSX Yosemite 10.10.5.

Je ne peux pas reproduire cela.

Même problème ici.
Existe-t-il un moyen de revenir à une version antérieure sous Windows?

Je l'ai trouvé moi-même.
https://github.com/docker/docker/releases

+1, docker 1.9.1 @ El Capitan

+1, Docker 1.9.1 sur OS X 10.11.1

+1, Docker 1.9.1a, OS X 10.10.5

+1, Docker 1.9.1 build a34a1d5, Windows 10

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

+1

Idem sur Docker-machine sous OSX 10.11.1
Docker version 1.9.1, build a34a1d5
docker-machine version 0.5.1 (HEAD)

Je suis capable de reproduire ceci sur docker-machine, OS X 10.10.5, donc cela peut être quelque chose lié à boot2docker. docker top me donne aussi <defunct> pour un processus 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 peut-être que l'un de vous a une idée où chercher, ou quoi déboguer, je n'ai pas vraiment trouvé quelque chose

De combien de RAM dispose votre VM? Cela pourrait être un MOO étant donné qu'il ressemble au
le processus meurt de manière inattendue. :désappointé:

Il semble que la mémoire ne soit pas le problème, mais le processus <defunct> consomme 100% du processeur;

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

Le conteneur semble également être bloqué, et j'ai dû redémarrer le vm pour le tuer

+1 Docker version 1.9.1, build a34a1d5, Win 7.

J'ai rencontré des problèmes similaires qui se sont avérés être des MOO, même si la commande stats affiche la mémoire disponible pour le conteneur. Le problème est survenu peu de temps après que le gestionnaire de tâches ait montré 0 mémoire physique libre, tandis que les statistiques continuaient à afficher <100%.

La chose étrange est que le processus a continué à fonctionner, donc il n'a pas été tué. Je peux réessayer avec -m, cependant, il est étrange que cela se produise sur 1.9.x, mais (après cette discussion) pas sur 1.8. En outre, l'exécution de la même chose sur une gouttelette DigitalOcean de 1 Go (également 1.9.1) a réussi. Peut-être que l'on utilise swap, devrait vérifier que

Cela n'arrêtait pas de m'arriver après avoir désinstallé 1.9.1 et installé 1.8.3. On aurait dit que la désinstallation n'était pas très complète sur Mac car le démarrage du shell était sans délai sur 1.8.3, contrairement à une première exécution normale où il configure les clés ssh et d'autres choses.

_USER POLL_

_La meilleure façon d'être averti en cas de modifications dans cette discussion est de cliquer sur le bouton S'abonner en haut à droite._

Les personnes énumérées ci-dessous ont apprécié votre discussion significative avec un +1 aléatoire:

@mattes

31 participants sur cette question et plus.

@ bean5 veuillez garder vos commentaires constructifs

@thaJeztah Je ne voulais pas offenser ni être déconstructif. Je veux attirer l'attention sur le fait que github montre le nombre de personnes participant ... et j'ai compris que

Je suis en mesure de dupliquer ce problème sur ma configuration (en utilisant Docker Machine sur Mac).

Voici mes conclusions à ce jour.

Comme indiqué par d'autres affiches, le moyen le plus simple de dupliquer cela a été d'utiliser l'ISO boot2docker 1.9.1 avec AUFS. Ce Dockerfile devrait reproduire au minimum le problème assez rapidement:

FROM debian:jessie

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

En regardant dmesg , je vois des erreurs AUFS après avoir tenté une telle compilation, mais je ne suis pas sûr à 100% qu'elles soient liées:

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 je crée une machine Docker 1.9.1 qui utilise overlay comme pilote de stockage:

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

Le processus ne se bloque PAS et cette ligne s'exécute avec succès! On dirait que AUFS et / ou le noyau est le problème.

boot2docker / boot2docker _did_ bump les deux versions du noyau et la validation AUFS pour la version 1.9.1, donc ce sont deux facteurs qui doivent être exclus ou étudiés plus en détail:

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

J'essaye actuellement la version 1.9.0 ISO avec un binaire 1.9.1 pour voir si la surface de la zone de bogue potentiel peut être réduite davantage.

Le Dockerfile se construira correctement et ne se bloquera pas sur un ISO boot2docker 1.9.0 avec un binaire Docker 1.9.1. Le problème ne semble pas résider dans Docker 1.9.1, mais plutôt avec l'environnement dans lequel il est exécuté.

J'utilise la version 1.9.1 sans problème sur aufs, mais j'ai beaucoup plus de cpu / ram / stockage que la configuration de la machine par défaut.

J'ai juste essayé d'augmenter la mémoire à 4 Go pour ma VM, mais je suis toujours capable de reproduire

@ cpuguy83 AUFS sur boot2docker 1.9.1?

Comme indiqué ci-dessus, b2d regroupe une version très spécifique d'AUFS.

Oui

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

Je vois également certains processus Java devenir obsolètes dans un conteneur. Je suis en mesure de reproduire ce problème avec les étapes suivantes
exécutez le conteneur:

docker run --rm -it myJavaContainerFromCentos7 bash

créez Foo.java avec ce qui suit:

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

compilez et exécutez-le entraîne un processus java obsolète, avec 1 cœur utilisant 100% du processeur:
javac Foo.java && java Foo

cependant ... si un System.exit(0); est ajouté après l'impression, tout va bien:

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

informations de version:
osx 10.10.3
docker 1.9.1
boot2docker version 1.9.1 uname -a est "linux ci 4.1.13-boot2docker"
numproc = 1

sortie strace avec 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 +++

sortie 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)                           = ?

le processus est maintenant bloqué mais vous pouvez entrer dans le conteneur:

docker exec -it myContainer bash

et voyez ce qui suit:

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

aperçu rapide des statistiques:

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

Tout fonctionne bien dans la version 1.8.3.

+1, Docker version 1.9.1, build a34a1d5, OS X

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

+1

Docker version 1.9.1, build a34a1d5 , OS X 10.11.1 (15B42)

+1

Docker version 1.9.1, build a34a1d5 sur OS X 10.11.1

Ce problème est vraiment assez bizarre. Si je strace la commande apt-get échouée, la fin de la sortie est:

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)

Où ces erreurs (Mauvais descripteur de fichier) continuent à boucler indéfiniment.

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 échoue? cela pourrait correspondre à mon précédent post où j'ai vu java "hello world" provoquer des processus zombies sans "System.exit (0);" explicite. - ou peut-être que c'est un problème complètement différent. si c'est désolé pour le bruit.

qu'arrive-t-il à votre processeur en boucle indéfiniment?

@andrewgdavis C'est à 100%

java "hello world" provoquant des processus zombies sans "System.exit (0);" explicite

Cela ressemble certainement au problème rencontré ici.

Je peux certainement confirmer le problème b2d (même fait la bissectrice pour le suivre le plus positivement jusqu'à la bosse du noyau 4.1.13). Je peux aussi reproduire sur 4.2.6 avec b2d.

En plus, mon hôte Gentoo est actuellement sur 4.1.13 + les correctifs AUFS également, et je vois exactement le même problème, donc nous avons définitivement exclu tout ce qui est spécifique à b2d.

Je pense qu'il vaudrait peut-être la peine de parcourir les commits entre 4.1.12 et 4.1.13 pour voir si quelque chose qui pourrait être lié saute.

(c'est-à-dire https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.1.13)

Ouais, quelque chose rompt avec le noyau 4.1.12 => 4.1.13. Je peux confirmer que la création d'un ISO boot2docker pour le premier ne déclenche pas ce bogue, contrairement au premier.

Donc, ce n'est pas spécifiquement lié à boot2docker, mais semble être lié à la version du noyau interagissant avec AUFS.

ou peut-être la manière spécifique dont le pilote AUFS dans Docker interagit avec le
noyau plus récent - à déterminer, probablement avec une bissectrice git stable sous Linux entre 4.1.12
et 4.1.13: pleurer:

J'ai une théorie sur les cheveux ...

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

le commit ci-dessus modifie filemap.c en generic_perform_write (struct file * file, struct iov_iter * i, loff_t pos)

Ci-dessous se trouve le morceau de code que je veux personnellement tester car le commentaire décrit à la fois les conditions de course de blocage et de blocage en direct et je vois le processeur indexé à 100%. mais c'est juste moi et mon tapis de saut aux conclusions.

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 on pourrait utiliser ce commit pendant git bisect comme point de test spécifique!

Voir un blocage similaire lors de l'arrêt de mongodb . Certainement présent dans 1.9.x. Non présent dans 1.8.x.

J'ai pu résoudre ce problème moi-même en augmentant la mémoire de la machine virtuelle docker-machine de 1024 à 2048 Mo et en attribuant 2 processeurs au lieu de 1.

Travaux:

VM: Ubuntu 14.04 (2 Go de RAM)
Moteur Docker: 1.9.1
Image de base Docker: ubuntu: dernière

Ne marche pas:

VM: Ubuntu 15.10 (2 Go de RAM)
Moteur Docker: 1.9.1,1.9.0,1.8.3
Image de base Docker: ubuntu: dernier , ubuntu: 14.04

@marsinvasion Si possible, pouvez-vous imprimer la sortie de uname -a sur les deux systèmes testés?

Machine virtuelle: Ubuntu 14.04
Linux ubuntu 3.19.0-25-generic # 26 ~ 14.04.1-Ubuntu SMP ven 24 juillet 21:16:20 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux

Machine virtuelle: Ubuntu 15.10
Linux ubuntu 4.2.0-19-generic # 23-Ubuntu SMP mer.11 novembre 11:39:30 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux

+1
Docker version 1.9.1, build a34a1d5 sur OS X 10.11.1

Rencontré sur OS X 10.9.5 avec docker 1.9.1.

Inspiré par @marsinvasion , j'ai obtenu une solution de contournement réussie en donnant à ma docker-machine 2 processeurs et 4096 Mo de RAM.

Oups, a parlé bientôt. Il a cessé de fonctionner lors de la modification d'un Dockerfile sur lequel je travaille et de la réexécution de la compilation.

Voir également ce bogue infernal (docker-machine boot2docker 1.9.1 sous OS X), à partir d'une image ubuntu: 15.04 précédemment construite. Cela semble nécessiter le redémarrage de mon serveur docker pour que ces conteneurs zombies disparaissent.

Je pensais que https://github.com/docker-library/java/issues/19 était lié mais peut-être pas, ici on se bloque, là ils ont eu une erreur de ne pas trouver "java".

J'ai basculé mon serveur en superposition comme solution de contournement. Avant cela, il créait également un tas de conteneurs zombies.

Docker version 1.9.1, build a34a1d5 sur OS X 10.11.1

Quelqu'un sait ce qu'implique la migration d'un système boot2docker.iso existant vers https://docs.docker.com/engine/userguide/storagedriver/overlayfs-driver/ ou est-il plus facile de faire une reconstruction complète? Cette page contient des avertissements inquiétants sur les constructions d'images CentOS - quelles sont les solutions de contournement "miam", est-ce lié à https://github.com/docker/docker/issues/10180?

C'est corrigé dans 1.9.1a - installez ceci si vous êtes sur OSX - https://github.com/docker/toolbox/releases/download/v1.9.1a/DockerToolbox-1.9.1a.pkg

Certainement pas corrigé par Docker Toolbox 1.9.1a. Souffrant de ce bug avec cette version. En regardant en arrière à travers les commentaires, il semble que je ne suis pas le seul.

non toujours pas de construction

J'ai dû supprimer la VM dans virtualbox et recommencer à zéro pour que cela fonctionne.

En outre, j'ai essayé de supprimer et de créer une nouvelle machine virtuelle plusieurs fois en vain.

Installé 1.9.1a, fait docker-machine rm default et utilisé Docker Quickstart Terminal pour régénérer la machine par défaut. Les images reconstruites (qui dérivent de java:7-jre ) et exécutées ne fonctionnent toujours pas. Continue de fonctionner correctement avec la machine de superposition construite comme suggéré ci-dessus:

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

^ merci! Je peux confirmer que la machine de superposition fonctionne.

L'utilisation de overlay comme pilote de stockage du moteur a également fonctionné pour corriger le blocage de l'arrêt MongoDB.

Vous pouvez contourner l'échec de construction de Dockerfile en installant Oracle java au lieu d'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

Mais je sous-estimais la portée du problème, boot2docker 1.9.1 conduit à des processus java zombie, même sur des conteneurs CentOS où openjdk s'installe correctement.
root 322 11.1 0.0 0 0 ? Zsl 18:43 29:48 [java] <defunct>

Je ne parviens pas à configurer mon serveur docker avec --engine-storage-driver overlay car je construis des images basées sur CentOS et overlayfs n'est pas compatible avec yum (https://github.com/ docker / docker / issues / 10180).

Je suis sûr que les gens de Docker ne le recommanderaient pas, mais la façon dont j'ai dépassé ce problème de blocage consiste à créer un boot2docker.iso qui utilise docker 1.9.1 avec un AUFS légèrement plus ancien. Instructions sur https://github.com/boot2docker/boot2docker/issues/1099#issuecomment -163052066.

essayé oracle jdk1.7.0_75 et jdk1.8.0_65; les deux se bloquent et créent un processus java obsolète.

DE: https://github.com/docker/docker/issues/10589
@neverfox exactement le même problème ici, avec la même image +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"
            }
        }
    }
}
]

J'ai simplement lancé docker run -it cassandra:2.1.11 et votre terminal sera bloqué, aucun moyen d'arrêter le conteneur. Vous devez arrêter toute la VM.

+1

A pu dupliquer le problème plus tôt dans la journée sur Docker 1.9.1 exécutant Mac OSX 10.11.1 (15B42)

A pu le contourner en installant Docker 1.9.0

_Des excuses pour le manque d'informations sur ma machine de travail plus tôt dans la journée - fourniront des informations mises à jour ultérieurement _

: +1:

Même chose ici avec Docker 1.9.1 et OS X 10.11.

Pour les personnes ayant ce problème

Nous avons jusqu'ici réduit cela à ne pas être un bogue _docker_ mais un problème de noyau en combinaison avec AUFS dans le noyau qui est utilisé par la version actuelle de boot2docker; voir https://github.com/docker/docker/issues/18180#issuecomment -161832035

• Si vous souhaitez rester informé des progrès, utilisez le bouton d'inscription sur cette page. ne commentez pas si vous ne disposez pas de nouvelles informations susceptibles de vous aider à résoudre ce problème.
• si vous voulez aider à résoudre ce problème, effectuer un git-bissect du noyau peut aider https://github.com/docker/docker/issues/18180#issuecomment -161834068
• rappelez-vous que chaque commentaire enverra plus de 2000 e-mails aux abonnés, et d'innombrables chiots mourront: sourire:

Je viens de tester Storage Driver: devicemapper (avec Server Version: 1.9.1 et le noyau 4.2.6), et le bogue ne se reproduit _pas_, donc nous sommes toujours dans une "interaction étrange entre un changement dans le nouveau noyau et les correctifs AUFS " terre. :désappointé:

Testé, et le bogue est toujours présent sur le nouveau noyau 4.1.14 , nous sommes donc toujours assis sur un commit qui a été rétroporté vers la 4.1.13 interagissant bizarrement avec les correctifs AUFS (et nous n'avons pas eu de chance avec le fait qu'il soit déjà corrigé dans l'intérim).

J'ai décidé de lui donner le vieil essai universitaire et de cloner le repo boot2docker; puis modifié le commit aufs dans le dockerfile à la version précédente. Donc docker 1.9.1 noyau 4.1.13 + version AUFS précédente qui a été livrée avant 1.9.1. La compilation est lente sur ma machine ... y a-t-il une configuration de docker swarm que je peux exécuter en conjonction avec un git bisect et agréger les résultats? ce serait doux.

de toute façon, je publierai mes résultats sous peu si cela fonctionne ...

mettre à jour:
4.1.13 + ce commit AUFS présente toujours le problème.
ENV AUFS_COMMIT 1724fe65683d126a92c6baeea0b3c7d0306c63ef

Je ne connais aucune configuration facile pour agréger les résultats, bien que l'on puisse en concevoir une.

FWIW, https://sources.debian.net/src/ca-certificates-java/jessie/debian/postinst.in/ est le script exact qui s'exécute dans ce package, et https://sources.debian.net/src /ca-certificates-java/jessie/src/main/java/org/debian/security/UpdateCertificates.java/ est la source Java exacte qui est exécutée lorsque nous obtenons le processeur suspendu + défunt + lié.

J'ai eu un problème connexe (le processus java se bloque) aujourd'hui.

Environnement hôte: Linux lenovo 4.2.0-19-generic # 23-Ubuntu SMP mer.11 novembre 11:39:30 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux
Distribution: Ubuntu 15.10
Moteur Docker: 1.9.1
Machine Docker: 0.5.0 (04cfa58)

Je suis le tutoriel réseau multi-hôte . La seule différence est que je joue avec l'image oracle / nosql . Cette image est basée sur Oracle Linux et utilise OpenJDK.

@brunoborges oui, cela pourrait être le même problème, voir https://github.com/docker/docker/issues/18500#issuecomment -163334612

@brunoborges vérifie simplement votre version de boot2docker.iso - si c'est 1.9.1 vous pouvez essayer de revenir à la version 1.9.0 et recréer votre machine et extraire à nouveau les images.
Si vous choisissez cette voie, pourriez-vous rédiger un bref rapport ici?

Je me suis donc demandé pourquoi cela ne se produit que sur java, et pas sur d'autres langues. Dans l'un de mes articles précédents, j'ai pu détailler les reproductions les plus élémentaires en compilant et en exécutant simplement

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

pour le cas d'échec qui a entraîné un processus Java obsolète
et alors

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

pour le cas attendu (non caduc).

J'ai ensuite essayé de reproduire quelque chose de similaire en utilisant python. J'ai échoué - mais j'ai essayé. Pour ceux qui sont intéressés, j'essayais de montrer la dernière sortie strace exit_group(0) = ? qui a été vue à partir du processus java zombie. (Ce lien m'a fourni beaucoup d'informations sur les threads python / seccomp / etc http://stackoverflow.com/questions/25678139/how-do-you-cleanly-exit-after-enabling-seccomp-in-python)

Alors, au kernel land: après avoir reconstruit l'iso boot2docker, avoir joué avec les versions aufs et les versions du noyau (rien de cela ne faisait vraiment de différence), j'en ai eu marre de la lenteur du processus de compilation en utilisant numproc = 1. Je l'ai donc changé en 6. ==> ne notez plus 1 processeur (qui n'a plus qu'un processeur par jour?). Soudain le cas de l'échec

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

a commencé à travailler.

De toute évidence, la prochaine chose à essayer était de le ramener à 1 processeur. ==> ÉCHEC. retour à un ancien processus java.

Alors j'ai voulu en savoir plus sur la façon dont java s'arrête. Ce n'est pas bien défini. mais avec seulement 1 processeur, ce processus java a pu être exécuté avec succès: (ne vous moquez pas de mon 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) {}

Quelqu'un d'autre peut-il confirmer ce comportement? << la question est désormais sans objet

Mise à jour: même avec plus d'un cœur, un processus Java obsolète peut se produire. (J'utilisais cassandra-cli et c'est arrivé.)

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

Avoir le même problème de blocage lors de la construction de bitbucket-server - update-ca-certificates fonctionne bien mais le jdk posthook se bloque pour toujours. Seul un problème lors de l'utilisation du 1.9.1 boot2docker. Passé à l'image RancherOS et n'a eu aucun problème. OSX 10.10.

Avec El Capitan, Docker 1.9.1 et Ubuntu 14.04.1 j'obtiens: Configurer ca-certificate-java qui se bloque indéfiniment.

@stremlenye est revenu à 1.9.0. Accroche toujours.

@brunoborges docker 1.9.0 ou boot2docker.iso 1.9.0?

@stremlenye Docker 1.9.0 ... quelles sont les instructions pour obtenir boot2docker.iso 1.9.0 dans mon système?

@brunoborges Consultez ce commentaire ci-dessus:

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

carsten-ulrich-saitow-ag explique comment créer une nouvelle docker-machine avec l'iso 1.9.0 en utilisant l'indicateur --virtualbox-boot2docker-url. Ce conseil a sauvé mon bacon! Une fois que j'ai fait cela, je pourrais à nouveau installer mon JRE RPM dans mes conteneurs.

@ mobsy74 @stremlenye a essayé avec boot2docker 1.9.0 et il se bloque parfois.

@brunoborges Merci d'avoir essayé. Je vais donc m'en tenir à la 1.8.3 jusqu'à ce que ce bogue soit corrigé.

@stremlenye vous voulez dire boot2docker 1.8.3?

@brunoborges oui

salut,
J'ai eu le même problème.
problème a été résolu lors de la rétrogradation des outils docker de 1.9.1 à 1.9.0
https://github.com/docker/toolbox/releases/download/v1.9.0/DockerToolbox-1.9.0.pkg

L'activation de plusieurs processeurs (dans la machine docker) a résolu cela pour moi.

--virtualbox-cpu-count=4

@heiths pouvez-vous s'il vous plaît partager des versions des outils

à mon humble avis, boot2docker devrait s'éloigner des aufs pour l'un des autres pilotes de stockage disponibles. Il y a une bonne raison pour laquelle aufs ne l'a jamais fait dans le noyau Linux.

@robvanmieghem chaque pilote a ses limites. Aufs est globalement assez stable, et overlayfs a quelques problèmes de blocage (selon l'utilisation)

@brunoborges DockerToolbox-1.9.1c - cela a fonctionné pour moi sur Windows et osx.

@thaJeztah n'a jamais dit que overlayfs était la solution parfaite. Je pense que btrfs est une bonne option pour boot2docker cependant, boot2docker est dédié à l'exécution de conteneurs docker et outre le fait que btrfs est entièrement pris en charge dans le noyau linux, il est vraiment facile de regarder le contenu.

Il y a autant d'opinions à ce sujet qu'il y a de combinaisons de distribution et de système de fichiers :) Aucune solution ne sera parfaite pour tous les cas d'utilisation, donc dans l'esprit de l'open source et de Linux, je pense que la meilleure décision à prendre est de fournir mieux prise en charge de plusieurs choix de distribution. Nous avons déjà le choix entre Boot2Docker ou RancherOS et je pense que du travail a été fait pour reconstruire boot2docker sur une base de distribution Debian. docker-machine supportera ubuntu sur le cloud et le bare metal, donc je suis sûr qu'un iso vm basé sur ubuntu ne serait pas difficile à assembler ainsi que d'autres tels que celui construit sur alpine ou CoreOS, etc. le choix du système de fichiers - encore une fois, RancherOS propose désormais ZFS en tant qu'installation facultative tandis que CoreOS utilisait BTRFS par défaut et je pense que c'est toujours une option et à partir du noyau 3.19, Ubuntu prend en charge OverlayFS dès la sortie de la boîte - tout le monde est prêt pour un Snappy Core basé image b2d? ;)

Maintenant, si seulement nous pouvions normaliser la dénomination des paramètres docker-machine et supprimer les références à 'boot2docker' pour réduire la confusion - l'utilisation du paramètre boot2docker-url pour installer RancherOS est quelque peu peu intuitive;)

@ bleu lointain +1

@heiths +1. Cela l'a résolu pour moi aussi sur OSX avec 1.9.1c

Régler le CPU sur> 1 évite le problème pour moi. 1.9.1c n'a pas aidé.

@heiths @fredriksvensson J'ai fait apparaître ce problème au hasard sur plusieurs conteneurs et j'ai également essayé d'augmenter la quantité de processeurs (mémoire aussi, mais ce n'est pas un point). Quelques cycles de stop <all> / start <all> ont montré que le problème n'a pas disparu. Je vous recommande de vérifier votre environnement de la même manière pour vous assurer que la solution est stable pour vous.
/ cc @timechanter

Oh, ce n'est certainement pas parti. Mais 10% de chances de blocage contre 100% de blocage sont au moins gérables à court terme.

@heiths --virtualbox-cpu-count=4 également fonctionné pour moi.

@timechanter +1 Définir les processeurs sur> 1 a évité le problème pour moi au moins une fois; ressemble à une solution de contournement efficace pour le moment.

OSX 10.10.5

Boîte à outils Docker désinstallée 1.9.1. La mise à niveau vers Docker toolbox 1.9.0 a fonctionné pour moi.

Même problème sur El Capitan MacOSX

@heiths --virtualbox-cpu-count=4 fonctionne aussi pour moi.

Cela m'est arrivé dans Windows 7 avec Docker Toolbox 1.9.1b et 1.9.1e.

"Configuration de ca-certificates-java (20130815ubuntu1) ..." - El Capitan MacOSX. Veuillez aider, les gars !!! Je ne peux pas le réparer

@ troian88 rétrograder vers boot2docker.iso 1.9.0 ou 1.8.3.

@ troian88 , utilisez une machine docker avec plusieurs processeurs.

Peut confirmer que --virtualbox-cpu-count=2 est une solution de contournement temporaire sur un Setting up ca-certificates-java suspendu avec Docker 1.9.1

Pour les personnes ayant ce problème

Nous avons jusqu'ici réduit cela à ne pas être un bogue _docker_ mais un problème de noyau en combinaison avec AUFS dans le noyau qui est utilisé par la version actuelle de boot2docker; voir https://github.com/docker/docker/issues/18180#issuecomment -161832035

• Si vous souhaitez rester informé des progrès, utilisez le bouton d'inscription sur cette page. ne commentez pas si vous ne disposez pas de nouvelles informations susceptibles de vous aider à résoudre ce problème.
• si vous voulez aider à résoudre ce problème, effectuer un git-bissect du noyau peut aider https://github.com/docker/docker/issues/18180#issuecomment -161834068
• rappelez-vous que chaque commentaire enverra plus de 2000 e-mails aux abonnés, et d'innombrables chiots mourront: sourire:

@externl @stremlenye Merci.

En regardant les piles LWP, j'ai trouvé que le bogue était causé par aufs_destroy_inode .

Je vais approfondir cela.

Cela semble être un blocage lié à 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).

Remarque

Les gens disent que le bogue peut être évité lors de l'exécution sur plusieurs processeurs.
Cependant, je peux toujours frapper le bogue avec ma boîte physique à 4 processeurs. (bien que <1% de probabilité.)
Donc --virtualbox-cpu-count=2 ne garantit pas que vous pouvez éviter le bogue.

Notez que le nombre de processeurs compte toujours.
Je peux atteindre le bogue de manière déterministe lorsque j'exécute taskset 0x1 java . ( taskset attribue des processeurs particuliers au processus).

@AkihiroSuda merci beaucoup d'avoir examiné cela. Tenez-nous au courant! :cœur:

Notez que ce problème se produit également sous Windows 7 lors de l'utilisation de Docker 1.8.3.

Nous voyons la même chose (exactement les mêmes traces de pile que dans le commentaire d'AkihiroSuda ci-dessus) sur les noyaux plus anciens:
Linux 3.19.0-42-generic #48~14.04.1-Ubuntu SMP x86_64 avec Docker version 1.9.1, build a34a1d5

Je peux confirmer l' affirmation de

Ce débogage AUFS semble vraiment intéressant - peut-être vaut-il la peine de signaler un problème avec AUFS et de voir si les responsables AUFS peuvent aider au débogage? Ce serait probablement utile pour eux si nous pouvions reproduire avec seulement AUFS (pas de Docker), mais ce n'est pas vraiment trivial. :sourire:

@tianon J'ai http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/5335

@AkihiroSuda , j'ai vu cela se bloquer avec un cas d'utilisation non Java. À savoir essayer d'arrêter un démon MongoDB forké. Cela ne se produit pas au démarrage de MongoDB ou lors d'une utilisation régulière, mais se produit de manière fiable à l'arrêt.

@jakirkham Merci, il semble qu'une configuration de thread spécifique (a tendance à apparaître dans Java, MongoDB, et peut-être d'autres choses) est nécessaire pour déclencher le bogue.

BTW, après réflexion, peut-être AUFS suspendu est un "résultat" du bogue plutôt que "la cause" du bogue.
Je regarde ce sujet: http://www.serverphorums.com/read.php?12 , 673905
(Je n'ai pas remarqué que zap_pid_ns_processes() était également suspendu il y a deux jours, car j'avais utilisé bash comme processus d'initialisation à ce moment-là. Https://github.com/docker/docker/issues/18180#issuecomment- 166186061)

https://github.com/docker/docker/issues/18180#issuecomment -161843456
@andrewgdavis , vous avez tout à fait raison!

Le bogue semble être une régression causée par le commit 296291cd sur le noyau Linux ( mm/filemap.c ).

J'ai créé un ISO Boot2Docker ( boot2docker-v1.9.1-fix1.iso ) qui omet le commit 296291cd: https://github.com/AkihiroSuda/boot2docker/releases/tag/v1.9.1-fix1

J'espère que cela fonctionne pour tout le monde. : smiley:

Le commit 296291cd produit une boucle -EINTR infinie dans mm/filemap.c:generic_perform_write , que fs/aufs/xino.c:do_xino_fwrite() ne peut pas tolérer:

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);
..
}

Comme do_xino_fwrite() boucle indéfiniment, zap_pid_ns_processes() (exécuté dans un autre LWP) ne peut pas retourner à partir de schedule() lorsqu'il est exécuté sur un seul processeur.
C'est pourquoi nous nous attaquons au bogue.

@ gilles-duboscq
Vous rencontrez le bogue parce que Canonical a initialement rétroporté le commit 296291cd dans l'arborescence du noyau 3.19: http://kernel.ubuntu.com/git/ubuntu/ubuntu-vivid.git/commit/?id=6b08592b8acc677d5b9bb7986343fdd6e0ad3303

@AkihiroSuda wow, merci d'avoir trouvé! Quelles sont les prochaines étapes? Ce correctif devrait-il être annulé ou existe-t-il un moyen d'améliorer le correctif? Envisagez-vous d'envoyer un correctif au noyau en amont?

@AkihiroSuda , votre solution fonctionne comme un charme. Merci!

@thaJeztah

Ce n'est pas une question facile.
Sans commit 296291cd, sendfile(2) peut être impossible à tuer.
Je crains que ce sendfile impossible

J'essaie d'améliorer le commit 296291cd, mais cela peut prendre un certain temps.

Quoi qu'il en soit, j'ai signalé ce bogue au bugzilla du noyau: https://bugzilla.kernel.org/show_bug.cgi?id=109971

J'ai également créé un conteneur Docker akihirosuda/test18180 pour faciliter le débogage: 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, d'accord, ça sonne comme un problème, oui. Merci beaucoup pour le repro-conteneur et la recherche; au moins, il y a une tâche très spécifique sur laquelle travailler, j'espère que d'autres personnes se joindront à nous, essayant d'aider à trouver une solution. Merci beaucoup pour votre excellent travail jusqu'à présent.

J'ai été frappé sur OS X El Capitan Darwin Kernel Version 15.2.0
Docker version 1.9.1, build d12ea79c9de6d144ce6bc7ccfe41c507cca6fd35
boot2docker 1.9.1

La rétrogradation vers boot2docker 1.9.0 avec les commandes ci-dessous a fonctionné pour moi:

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 va prendre en charge 296291cd.
http://article.gmane.org/gmane.linux.file-systems.aufs.user/5343

La prochaine étape consiste donc à attendre la mise à jour de AUFS.

Vous êtes un héros, @AkihiroSuda! Merci de travailler avec en amont pour comprendre cela! :cœur:

Si quelqu'un veut appliquer le correctif @AkihiroSuda , cela fonctionne comme un charme:

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

Pour quiconque utilise Ubuntu 14.04, la mise à niveau vers le noyau 3.13.0-71 ou version antérieure devrait résoudre le problème. 296291cd a été rétroporté par la suite .

@ebpitts merci pour le conseil, voici les étapes quelque peu relatives pour rétrograder le noyau Ubuntu 14.04 à 3.13.0-71 avec Docker 1.9.1 installé.

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

À ce stade, vous devriez avoir deux noyaux parmi lesquels choisir pendant le démarrage. Cependant, je courais dans une boîte Vagrant distante sur SSH, donc pas de chargeur de démarrage GRUB pour moi ... j'ai donc supprimé le noyau par défaut le plus récent (3.13.0-74 dans mon cas) comme option de démarrage:

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

La sortie de la commande contenait des informations sur la mise à jour de Grub, vous pouvez donc inspecter /boot/grub/grub.cfg et voir quelle sera l'option de démarrage par défaut au redémarrage. Il semble que j'ai dû faire cette suppression / réajout des en-têtes, mais une fois que le fichier grub.cfg semblé bon ( 3.13.0-71-generic était la seule et première option de démarrage), continuez et redémarrez:

sudo reboot

Et puis, remettez SSH dans ma boîte:

$ uname -r
3.13.0-71-generic

Mais maintenant, il semblait que docker ne fonctionnait pas. Ainsi, la réinstallation complète nécessite d'abord la suppression:

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

Et, honnêtement, lors de ma prochaine tentative d'exécuter un docker build sur le même conteneur qui était accroché au titre de l'OP ("Configurer ca-certificates-java"), il _ encore_ est mort et a verrouillé ma machine cette fois , mais maintenant que je n'ai pas d'accès SSH, je vais rentrer chez moi et attendre 2016 pour essayer de voir si quelqu'un d'autre a une meilleure solution d'ici là = /

Donc ... je ne peux pas affirmer que même après avoir rétrogradé le noyau à 3.13.0-71 après avoir rencontré ce problème sur Ubuntu 14.04 + Docker 1.9.1 est même efficace. Beurk.

Ouais, juste pour double confirmer, j'ai couru $ docker run -it --rm akihirosuda/test18180 et ça se bloque toujours.

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

C'est après la rétrogradation d'Ubuntu 14.04 vers la version 3.13.0-71 du noyau avec 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 êtes-vous sûr que la rétrogradation du noyau sur Ubuntu est vraiment la solution?

Intéressant, même lorsque je règle le pilote de stockage sur explicitement devicemapper in /var/default/docker :

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

et redémarrez le service docker en exécutant 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

Je me bloque toujours dans l'image de test akihirosuda/test18180:latest .

J'ai rétrogradé à Docker 1.8.3 (pas aussi facile sans apt-get ) sur ma boîte Ubuntu 14 en utilisant le binaire brut, voici les étapes ... pour n'importe qui d'autre ... je suis de retour dans les affaires (s'il vous plaît notez que j'ai également rétrogradé le noyau à 3.13.0-71-generic auparavant également, voir ci-dessus)

J'ai installé le binaire 1.8.3 à partir de https://get.docker.com/builds/Linux/x86_64/docker-1.8.3 , puis je l'ai déplacé vers /usr/bin/docker , je lui ai donné les autorisations exécutables sudo chmod +x /usr/bin/docker .

Ensuite, j'ai attrapé le script brut sysvinit-debian , commenté le corps check_init() et l'ai remplacé par simplement echo '' et l'ai déposé dans /etc/init.d . Ensuite, je l'ai configuré pour qu'il s'exécute au démarrage en tant que root avec ln -s /etc/init.d/docker /etc/rc2.d/S99docker , et j'ai exécuté sudo reboot . Après cela, je suis de retour en train d'exécuter le service docker 1.8.3 au démarrage à partir d'une installation binaire. Je ne sais pas pourquoi ces étapes ne sont pas vraiment documentées sur la page d'installation binaire du site Web de docker. Bref.

$ 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

Ça a l'air bien ici - je peux exécuter correctement $ docker run -it hello-world . L'exécution de akihirosuda/test18180 se bloque toujours (???) mais je suis capable de construire et d'exécuter mon conteneur d'origine sans rester coincé sur Setting up ca-certificates-java , ce qui m'a amené ici en premier lieu.

Pour référence, je suis sur Ubuntu 15.04 vivid, Linux 3.19.0-42-generic. Également affecté.

Comme je ne peux pas utiliser de superposition (j'ai besoin d'invités RHEL), j'ai créé une partition btrfs sur un lecteur de rechange et l'ai montée sur / var / lib / docker (arrêtez le démon docker avant). Docker utilise maintenant btrfs avec bonheur, mais l'image de @akihirosuda est toujours suspendue au deuxième contrôle (bizarre).

@mikeatlas
Merci d'avoir testé mon image test18180 .

Le résultat n'est pas bizarre.
Le deuxième chèque ( Checking whether sendfile(2) is killable. ) se bloque dans les anciens noyaux.
Vous avez besoin d'un noyau plus récent avec 296291cd pour réussir la deuxième vérification.

| AUFS? | Le noyau comprend 296291cd? | Résultat attendu |
| --- | --- | --- |
| Y | Y | Accroche (1er chèque: Checking whether hitting docker#18180. ) |
| Y | N | Hangs (2e chèque: Checking whether sendfile(2) is killable. ) |
| N | Y | Passer |
| N | N | Hangs (2e chèque: Checking whether sendfile(2) is killable. ) |

@cfstras Merci, je vais examiner cela.

@cfstras , il est reproductible, et j'ai ouvert # 19073.

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

ÉDITER:
Auparavant, je me suis trompé sur la raison pour laquelle docker ne fonctionnait pas après avoir changé les versions du noyau, mais je peux confirmer l'installation du package supplémentaire pour mon noyau, puis la réinstallation de docker a résolu ce problème pour moi:

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 intéressant, linux-image-extra-3.13.0-71-generic n'est pas un package que je pensais installer (mais j'ai installé les packages supplémentaires génériques par la suite, comme indiqué) .... mais j'avais quand même l'impression que le module AUFS est beaucoup plus ancien que juste le noyau relativement récent 3.13.0-71 . Quoi qu'il en soit, la rétrogradation vers Docker 1.8.3 n'était pas trop douloureuse non plus, et si je devais recommencer le processus, je préférerais rétrograder Docker plutôt que rétrograder le noyau Linux n'importe quel jour de la semaine.

@dschep Notez pour d'autres que le passage à OverlayFS nécessite la version du noyau 3.18 + sous Linux, et comme cité sur la page de Docker, _Aussi prometteur que soit OverlayFS, il est encore relativement jeune.

@mikeatlas Je suppose que c'est la plus grande limitation jusqu'à présent sur OverlayFS: "_Par conséquent, il est peu probable que l'utilisation de yum à l'intérieur d'un conteneur sur un hôte Docker en utilisant le pilote de stockage overlay sans implémenter des solutions de contournement ._".

@brunoborges yum est actuellement en cours de patch pour fonctionner sur overlayfs, donc, bientôt, les nouvelles versions de yum devraient pouvoir fonctionner sur overlayfs (il y aura toujours des problèmes, donc cela dépend de votre cas d'utilisation / situation où vous rencontrez leur). Une utilisation excessive des inodes peut être un autre problème.

Je crois que je rencontre également ce problème. La trace des appels mentionne apparmor, mais la désactivation d'apparmor ne fait aucune différence. L'utilisation de devicemapper a permis de résoudre le problème.

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>

Cela a été corrigé dans AUFS en amont - boot2docker a été mis à jour pour inclure le correctif (qui sortira avec la prochaine version), et tous les utilisateurs non-boot2docker qui sont affectés doivent appliquer la version AUFS mise à jour. : +1:

@tianon avez-vous des références aux bogues en amont?

http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/5345 est l'annonce de la version en amont - je ne sais pas s'il y a plus de discussions que cela

http://comments.gmane.org/gmane.linux.file-systems.aufs.user/5337 a plus de discussion de fond pour le problème

Je vous remercie!

Cela a été corrigé dans AUFS en amont - boot2docker a été mis à jour pour inclure le correctif (qui sortira avec la prochaine version), et tous les utilisateurs non-boot2docker qui sont affectés doivent appliquer la version AUFS mise à jour. : +1:

Agréable.

La version boguée d'AUFS a-t-elle été utilisée sur Docker Hub?

@tianon «Appliquer la version AUFS mise à jour» signifie que pour les utilisateurs non-boot2docker (tout le monde exécutant le moteur docker _pas_ en développement sur Mac OS X, pour lequel b2d est construit, principalement) qu'ils devront attendre une mise à jour du noyau Linux avec ce correctif AUFS ... Ou ... compte tenu du nombre d'installations / personnes qui semblent être affectées, des instructions simplifiées / minimales pourraient-elles être fournies par quiconque sur la façon de patcher AUFS vers 4.1.13+? Le guide pour la version 4.1.13+ n'est certainement pas

Juste pour que je comprenne que si je construis ce boot2docker.iso et le mets dans ~/.docker/machine/cache et crée une nouvelle VM avec docker-machine cette VM utilisera cette nouvelle copie de boot2docker .

Juste pour que je comprenne si je construis ce boot2docker.iso et le mets dans ~ / .docker / machine / cache et crée une nouvelle VM avec docker-machine que VM utilisera cette nouvelle copie de boot2docker.

Techniquement oui, cela fonctionnerait, mais une meilleure option pourrait être d'utiliser --virtualbox-boot2docker-url , par exemple:

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

Ah, ok, merci d'avoir clarifié. Eh bien, cela semble fonctionner alors.

Envoi d'une demande de mise à jour d'AUFS vers Canonical: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043

Y aura-t-il une nouvelle version de boot2docker, car la version 1.9.1 ne semble pas contenir le correctif?

Éditer. avec l' image boot2docker @AkihiroSuda, j'ai pu continuer. Merci à tous!

Ouais, ce correctif est après 1.9.1. @tianon a déclaré qu'une sortie était prévue. Normalement, il sort au même moment où docker sort pour la libération. Comme ils ont tendance à suivre un cycle de 2 semaines sur les versions, je prévois qu'une sortie est imminente. Dans l'intervalle, @AkihiroSuda a créé un correctif que vous pouvez utiliser ou vous pouvez créer le vôtre, ce qui est vraiment simple prend du temps.

Merci @AkihiroSuda pour l'image, ça marche! :)

+1 Debian Wheezy et Ubuntu 15.04

La sortie de

Oh, désolé, ça doit avoir mélangé ça. Merci de m'avoir mis au clair, @tiborvass. Avez-vous compris ça, @shusso?

@jakirkham je l'ai fait, merci: +1:

J'ai pu créer une virtualbox hôte de la machine docker en utilisant ce correctif:

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

Actuellement, les hôtes docker-machine que je crée sur le moteur de calcul Google, avec l'option --driver google, semblent avoir ce problème. Il n'y a pas d'option avec le pilote google pour spécifier un .iso différent, donc je ne peux pas utiliser le correctif ci-dessus sur google compute.

Quelqu'un connaît-il une solution de rechange? ou en effet si Google est au courant du problème, ou où je dois déposer un rapport de bogue pour eux.

Le pilote de la machine google docker est-il géré par docker ou par google?

Le pilote peut être trouvé ici; https://github.com/docker/machine/tree/master/drivers/google

Je pense que l'image de VM exécutée sur Google Compute doit être celle-ci ici:

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

C'est:

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

En parcourant ce qui précède, une solution de contournement potentielle semble être celle suggérée par @nathanleclaire

$ docker-machine create -d google - overlay du pilote de stockage du moteur

Il semble également y avoir une option "--google-machine-image" disponible pour le pilote google pour docker-machine. La commande:

$ gcloud compute liste d'images

Répertorie les images publiques disponibles. Je remarque qu'un nouvel ubuntu rusé a récemment été mis en place.

Juste pour confirmer:

$ docker-machine create -d google - superposition du pilote de stockage du moteur

Travaillé. Je vais également étudier la création d'une image de machine personnalisée en utilisant le boot2docker fixe, et essayer de le connecter avec docker-machine.

À quiconque frappe ceci sur boot2docker, veuillez donner le RC à
https://github.com/tianon/boot2docker-legacy/releases/tag/v1.10.0-rc1 a
coup. : +1:

@tianon je le teste avec l'image suivante trecloux / docker-java-zombie
Et ça a l'air bien ... mais ça se bloque toujours avec l'image akihirosuda / test18180

Travail vraiment impressionnant

@trecloux utilisez-vous btrfs et vous vous
Si tel est le cas, il s'agit d'un problème connu: https://github.com/docker/docker/issues/19073

@AkihiroSuda J'utilise l'image boot2docker v1.10.0-rc1 avec 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

Voici la sortie de votre image de test:

$ 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 C'est un comportement attendu. Rien ne raccroche.

@AkihiroSuda Ok, désolé. Et merci pour vos efforts :-)
Donc @tianon : 1.10.0-rc1 a l'air bien.

Même problème ici. S'accroche à la mise en place de certificats CA, le CPU devient fou ...

$ 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

exécutant MacOSX 10.11.2

@sgoendoer essaie d'utiliser l' image de docker-machine create --driver virtualbox --virtualbox-boot2docker-url="file:/path_to_the_image" nameofmachine

pour les utilisateurs non boot2docker, une idée de la version du noyau avec laquelle cela sera corrigé? 3.13.0-71 semble fonctionner, 3.13.0-74 et 3.13.0-76 semblent être cassés ...

Même problème ici; Il n'y a donc pas de solution facile à cela?
Est-ce corrigé dans la version RC? J'essaye celui-là maintenant. Bien que cela cause probablement d'autres problèmes.

DERNIERS RÉSULTATS DE TRAVAIL RAPIDES (Mise à jour: 21 janvier 15:33 UTC)

| Distro | Solution de contournement |
| --- | --- |
| Général | Utilisez devicemapper / overlay / btrfs (mais cela peut causer un autre problème ..) |
| Boot2Docker | : white_check_mark: mise à niveau vers v1.10.0-rc1 |
| Ubuntu 14.04LTS | : arrow_down: Rétrograder le noyau vers la version 3.13.0-71 ou antérieure |
| Ubuntu 15.04 | : arrow_down: Rétrograder le noyau vers la version 3.19.0-39 ou antérieure (: avertissement: non testé) |
| Ubuntu 15.10 | : arrow_down: Rétrograder le noyau vers la version 4.2.0-18 ou antérieure |
| Debian 7/8 | : arrow_down: Rétrograder le noyau à la version 3.16.7-ckt11 de la version 3.16.0 ( apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 ) ou plus ancienne |
| Debian 9 | : white_check_mark: (ne prend pas en charge AUFS depuis le noyau 3.18-1 ~ exp1) |
| Gentoo | : white_check_mark: mise à niveau vers les plus récentes (: avertissement: non testé) |
| RHEL / CentOS | : white_check_mark: (ne prend pas en charge AUFS) |
| openSUSE | : white_check_mark: (ne prend pas en charge AUFS) |

Les distributeurs émettent des tickets

| Distro | Statut | URL du problème |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: Fermé | https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | : white_medium_square: En cours | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | Pas encore confirmé | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

@AkihiroSuda v1.10.0-rc1 ne corrige pas les zombies pour moi, quelqu'un qui a également eu le problème?

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)   

Après avoir démarré strace sur le processus défunt après un certain temps, cela est apparu, mais après cela, le zombie existe toujours:

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>

Cette fois, il n'est plus accessible via strace, je suppose qu'il est toujours attaché même si ce n'est pas le cas.
: ~ # strace -p 23810

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

@wzrdtales
Pourriez-vous s'il vous plaît obtenir des piles LWP comme dans https://github.com/docker/docker/issues/18180#issuecomment -166186061?
aussi, quelle est votre cmdline et votre version de phantomjs?

Bien sûr, version 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

Et aussi la pile de tâches:

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

Aussi pour ajouter des informations système:

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 Utilisez -vous Docker (et non Boot2Docker) v1.10.0-rc1 sur Debian?
Cela ne fonctionne pas car le problème est un bogue du noyau plutôt que celui de Docker.

Je cherche dans les noyaux Debian et je vais mettre à jour la liste https://github.com/docker/docker/issues/18180#issuecomment -173436661.

@AkihiroSuda y, c'est directement sur debian. J'ai supervisé le point Debian sur votre liste, merci de l'avoir signalé :)

Pour Debian, nous ne devrions pas utiliser de noyaux basés sur 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 J'ai mis à jour la liste, veuillez utiliser le noyau ckt11.

@AkihiroSuda : FWIW, je pense que la recommandation de rétrograder à v3.16.7-ckt11 vous expose à un risque pour CVE-2016-0728, qui a une escalade de racine publique connue. Je viens de cingler https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 , mais pour info avant de rétrograder.

@zmerlynn Merci d'avoir signalé cela!

DERNIERS RÉSULTATS DE TRAVAIL RAPIDES (Mise à jour: 26 janvier 1:49 UTC)

| Distro | Solution de contournement |
| --- | --- |
| Général | Utilisez devicemapper / overlay / btrfs (mais cela peut causer un autre problème ..).
Si vous pouvez mettre à niveau AUFS et construire le noyau manuellement, vous pouvez également utiliser AUFS v20160111 ou version ultérieure. |
| Boot2Docker | : white_check_mark: mise à niveau vers v1.10.0-rc1 |
| Ubuntu 14.04LTS | : arrow_down: Rétrograder le noyau vers la version 3.13.0-71 ou antérieure |
| Ubuntu 15.04 | : arrow_down: Rétrograder le noyau vers la version 3.19.0-39 ou antérieure (: avertissement: non testé) |
| Ubuntu 15.10 | : arrow_down: Rétrograder le noyau vers la version 4.2.0-18 ou antérieure |
| Debian 7/8 | : arrow_down: Rétrograder le noyau à la version 3.16.7-ckt11 de la version 3.16.0 ( apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 ) ou plus ancienne |
| Debian 9 | : white_check_mark: (ne prend pas en charge AUFS depuis le noyau 3.18-1 ~ exp1) |
| Gentoo | : white_check_mark: mise à niveau vers les plus récentes (: avertissement: non testé) |
| RHEL / CentOS | : white_check_mark: (ne prend pas en charge AUFS) |
| openSUSE | : white_check_mark: (ne prend pas en charge AUFS) |

: avertissement: la mise à niveau du noyau peut être un risque pour la sécurité (par exemple, CVE-2016-0728)

Les distributeurs émettent des tickets

| Distro | Statut | URL du problème |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: Fermé | https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | : white_medium_square: En cours | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | : white_medium_square: En cours | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

Nous avons également rencontré ce problème, mongod est bloqué dans l'état R fonctionnant avec 100% de CPU.

Voici la vraie astuce pour obtenir une trace de pile correcte qui m'amène ici:

echo "l"> / proc / sysrq-trigger

à partir de là, vous pouvez voir que le CPU 2 est bloqué dans une boucle d'inifinity par 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

la recherche par do_xino_fwrite me conduit ici!

Il semble que je rencontre ce problème aussi sur Debian Stretch où il se bloque lors de la configuration des certificats.

Voici le message d'erreur: https://gist.github.com/clball/738feb46094802a1bcf7
Voici les informations de version: https://gist.github.com/clball/494fe8598dd0cdfd6d10
Voici le fichier docker: https://gist.github.com/8778f8db143478d6c8ab

Alors, quelle est la solution pour OSX ici, existe-t-il déjà une mise à jour de docker?

Pas encore, mais il y a une version candidate. (https://github.com/tianon/boot2docker-legacy/releases/tag/v1.10.0-rc2)

La solution pour moi était de changer le backend de stockage.

Ajouter une ligne à / etc / default / docker
¡¡ATTENTION, vous perdrez les données de votre conteneur !!

DOCKER_OPTS="--storage-driver=devicemapper"

Je recommande d'arrêter le service docker, d'effacer le dossier docker sur / var / lib, puis d'ajouter la ligne et de redémarrer le service docker.

@ referup-tarantegui, en guise d'avertissement, le pilote devicemapper est considéré comme terriblement mauvais pour les performances à moins d'être monté directement sur de vrais disques physiques. Voir
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-pas-si-approfondi-dans-les-pilotes-de-stockage-docker.html # 44
et
https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/ "Performances de Device Mapper et Docker"

Il existe une version B pour la release candidate2

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

Mise à jour du tableau sur Ubuntu.

DERNIERS RÉSULTATS DE TRAVAIL RAPIDES (Mise à jour: 3 février 6:30 UTC)

| Distro | Solution de contournement |
| --- | --- |
| Général | Utilisez devicemapper / overlay / btrfs (mais cela peut causer un autre problème ..).
Si vous pouvez mettre à niveau AUFS et construire le noyau manuellement, vous pouvez également utiliser AUFS v20160111 ou version ultérieure. |
| Boot2Docker | : white_check_mark: mise à niveau vers v1.10.0-rc3 |
| Ubuntu 14.04LTS | : white_check_mark: mise à niveau du noyau vers la version 3.13.0-77.121hf1533043v20160201b1 (PPA) |
| Ubuntu 15.04 | : white_check_mark: Mettre à niveau le noyau vers 3.19.0-49.55hf1533043v20160201b1 (PPA) |
| Ubuntu 15.10 | : white_check_mark: mise à niveau du noyau vers 4.2.0-27.32hf1533043v20160201b1 (PPA) |
| Debian 7/8 | : arrow_down: Rétrograder le noyau à la version 3.16.7-ckt11 de la version 3.16.0 ( apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 ) ou plus ancienne |
| Debian 9 | : white_check_mark: (ne prend pas en charge AUFS depuis le noyau 3.18-1 ~ exp1) |
| Gentoo | : white_check_mark: mise à niveau vers les plus récentes (: avertissement: non testé) |
| RHEL / CentOS | : white_check_mark: (ne prend pas en charge AUFS) |
| openSUSE | : white_check_mark: (ne prend pas en charge AUFS) |

Les distributeurs émettent des tickets

| Distro | Statut | URL du problème |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: Fermé | https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | : white_medium_square: En cours (ETA: 20 février) | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | : white_medium_square: En cours | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

@AkihiroSuda , je pense que vous vouliez dire

@jakirkham Merci,

rc3 est sur le repo officiel au lieu de mon fork:
https://github.com/boot2docker/boot2docker/releases/tag/v1.10.0-rc3

Nous avons enquêté sur la dette technologique qui nous a obligés à utiliser ma fourchette et avons constaté que
il avait été corrigé depuis docker-machine 0.5, donc nous avançons et
vers le haut. :sourire:

btw, pour ceux qui cherchent à basculer les noyaux vers les versions avec patch chiluk répertoriées ci-dessus pour les PPA Ubuntu. Par exemple, pour Ubuntu 14.04, linux-image-3.13.0-77-generic , vos étapes seraient:

$ 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

Ensuite, vous devrez mettre à jour votre configuration /etc/default/grub , puis exécuter sudo update-grub , puis redémarrer dans la nouvelle version corrigée du noyau. Si vous ne l'avez pas fait auparavant, voici un guide sur la façon de définir un noyau par défaut différent dans grub .

Je peux confirmer que ce problème n'existe pas sur Docker 1.10.0, qui a également corrigé ma situation sur OS X 10.11. Sinon, j'allais revenir à la version 1.9.0.

Je reçois toujours le problème de conteneur / processus suspendu java sur docker 1.10:

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

@AkihiroSuda J'essaie vos solutions de contournement rapides (merci!) Mais je ne peux pas installer l'ancien noyau sur mon serveur Debian 8 (jessie), j'obtiens:

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

Quand j'essaie les suggestions @mikeatlas (btw devait sudo apt-get install software-properties-common pour que sudo add-apt-repository ppa:chiluk/1533043 fonctionne), j'obtiens un échec de mise à jour, ce qui explique pourquoi l'installation ne fonctionne pas

$ 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'

Mes infos 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 merci pour le conseil sur le besoin de software-properties-common , j'ai mis à jour mon message ci-dessus.

@jamshid : Après avoir ajouté le PPA et fait apt-get update , vérifiez et voyez quels noyaux sont disponibles sur votre machine ... Il semble qu'il y ait une version plus récente ( 3.13.0-78 ) mais je ne vois pas il est disponible après avoir exécuté une mise à jour moi-même ici. Cependant, voici comment vous _pouvez_ déterminer quels noyaux sont disponibles pour l'installation:

$ 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 vous ne voyez pas quelque chose comme linux-image-3.13.0-77-generic ou plus, quelque chose d'autre ne doit pas être correct.

Oh, @jamshid, vous utilisez Debian 8? Remarque ci-dessus: 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 sur Debian 8 donne

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

Une heure de recherche sur Google active pour trouver le package ckt11 n'a pas aidé.
S'il vous plaît, avez-vous des suggestions pour rétrograder le noyau Debian 8 récent?

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 Vous pouvez trouver les packages installés précédemment dans /var/cache/apt/archives . Vous devriez pouvoir rétrograder avec dpkg -i <old_package>.deb .

Confirmé que l'installation du nouveau noyau à partir du PPA a résolu le problème pour moi (Ubuntu 14.04.3 / Kernel 3.13.0-78-generic / Docker 1.9.1)
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043

Quelqu'un a-t-il reçu les instructions de rétrogradation pour travailler avec Debian (pas Ubuntu)? Je me demande si la raison pour laquelle mon apt-get update échoue avec l'erreur ci-dessous (après l'ajout du repo ppa):

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

est-ce que seuls les packages ubuntu sont disponibles sur https://launchpad.net/~chiluk/+archive/ubuntu/1533043? Hmm je suis confus, je pensais qu'Ubuntu était basé sur Debian.

@jamshid Ubuntu ppa ne prend pas en charge Debian.

Si 3.16.7-ckt11-1 + deb8u3 n'est malheureusement plus disponible, vous pouvez patcher le dernier noyau: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207#47

(Je peux télécharger le package deb, si quelqu'un en a besoin)

Si quelqu'un a besoin du noyau, je l'ai téléchargé ici, il est un peu plus récent que deb8u3, mais il ne semble pas qu'il y aurait le bogue, au moins je ne l'ai pas rencontré pendant un bon moment, mais en corrigeant le le dernier noyau est probablement la meilleure solution. Cependant si vous en avez besoin:
https://wizardtales.com/linux-image-3.16.0-0.bpo.4-amd64_3.16.7-ckt11-1+deb8u6~bpo70+1_amd64.deb

@wzrdtales : +1:

Pour ceux comme moi qui ont encore du mal à faire ce tri, j'aimerais vous signaler TINI comme une belle solution de contournement:
https://github.com/krallin/tini

avec quelques lignes dans le fichier docker, j'ai eu un processus d'initialisation décent capable de supprimer les zombies.
Cela permettra d'éviter la transition vers devicemapper.

À votre santé,
Francesco

Donc, j'utilise tini. Cependant, cela ne m'a pas aidé ici car le problème que j'ai rencontré était lors de la construction de l'image.

Aussi, lorsque j'exécute un conteneur, j'utilise tini, mais cela m'a toujours affecté.

@fflatorre
Merci pour l'information, mais le problème des zombies que tini peut résoudre semble différent de ce problème.
https://github.com/docker/docker/issues/18180#issuecomment -167042078

En fait, même avec tini, on peut avoir un zombie:

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 J'oublie de mentionner que nous ne rencontrons pas ce problème lors de la création de l'image. Nous construisons une image très basique, puis la logique de provisionnement est déléguée à un tas de scripts ansibles. Pendant l'approvisionnement, l'un des processus (kafka) se bloquait. Jusqu'à présent, TINI semble avoir atténué ce problème.
Je reconnais que ce n'est peut-être pas une solution pour vous, en effet, je suggérerais de le passer de la solution de contournement au placebo :)
J'espère que nous pouvons obtenir est trié bientôt.

J'ai eu le même problème en exécutant Docker 1.9.1 sur OSX 10.11.3:

$ docker -v
Docker version 1.9.1, build a34a1d5

Mise à niveau vers la dernière version de Docker Toolbox corrigée:

$ docker -v
Docker version 1.10.1, build 9e83765

Pour plus d'informations, j'ai répertorié certains problèmes et solutions de contournement liés aux pilotes de stockage AUFS / Overlay / BtrFS / ZFS / devicemapper: https://github.com/AkihiroSuda/docker-issues/

J'espère que cela peut aider ceux qui sont intéressés par # 18180 et d'autres.

@AkihiroSuda J'ai essayé de suivre le lien https://launchpad.net/%7Echiluk/+archive/ubuntu/1533043/+packages mais je ne suis pas autorisé à afficher la page.

Voir aussi: https://github.com/docker/toolbox/issues/318#issuecomment -184143546

@ schmunk42
Je n'ai pas non plus pu accéder à la page.
Je pense que chiluk refait des paquets. Vous pouvez lui demander à https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043

Pour les personnes qui rencontrent des problèmes avec cela, voici comment résoudre le problème sur Ubuntu 14.04 à l'aide du noyau proposé . Cela ne sera bien sûr pas pertinent une fois que le noyau aura obtenu son diplôme dans la branche principale.

Avant de commencer, nous pouvons confirmer que nous fonctionnons sur un noyau affecté en exécutant (c'est-à-dire <3.19.0-50 sur Ubuntu 14.04):

$ uname -r
3.19.0-49-generic

Comme nous le savons, nous devons d'abord activer les packages

$ 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

Une fois cela fait, installons le noyau mis à jour:

$ 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

Et le redémarrons

$ sudo shutdown -r now

Après le redémarrage, nous pouvons confirmer que les derniers fonctionnent maintenant sur le dernier noyau:

$ uname -r
3.19.0-50-generic

Merci @vpetersson , j'essaie de savoir ce qui se passera lorsque cette version du noyau sera publiée, va-t-elle simplement écraser l'installation proposée ou devez-vous faire quelque chose pour revenir à la normale s'il vous plaît?

@IainColledge Oui, j'imagine que ce serait le cas, mais je ne suis pas entièrement sûr.

Mise à jour du tableau sur Ubuntu et Debian.

DERNIERS RÉSULTATS DE TRAVAIL RAPIDES

| Distro | Solution de contournement |
| --- | --- |
| Général | Utilisez devicemapper / overlay / btrfs (mais cela peut causer un autre problème ..).
Si vous pouvez mettre à niveau AUFS et construire le noyau manuellement, vous pouvez également utiliser AUFS v20160111 ou version ultérieure. |
| Boot2Docker | : white_check_mark: mise à niveau vers v1.10.0 ou version ultérieure |
| Ubuntu 14.04LTS | : white_check_mark: Mettre à niveau le noyau vers 3.13.0-79.123 ou version ultérieure |
| Ubuntu 15.04 | : white_check_mark: mise à niveau du noyau vers la version 3.19.0-51.57 ou ultérieure |
| Ubuntu 15.10 | : white_check_mark: mise à niveau du noyau vers 4.2.0-30.35 ou version ultérieure |
| Debian 7/8 | : arrow_down: Rétrograder le noyau à la version 3.16.7-ckt11 de la version 3.16.0 ou antérieure ( archive dpkg par @wzrdtales) |
| Debian 9 | : white_check_mark: (ne prend pas en charge AUFS depuis le noyau 3.18-1 ~ exp1) |
| Gentoo | : white_check_mark: mise à niveau vers les plus récentes (: avertissement: non testé) |
| RHEL / CentOS | : white_check_mark: (ne prend pas en charge AUFS) |
| openSUSE | : white_check_mark: (ne prend pas en charge AUFS) |

Les distributeurs émettent des tickets

| Distro | Statut | URL du problème |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: Fermé | https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | : white_check_mark: Fermé | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | : white_medium_square: En cours | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

Encore une chose; J'ai répertorié quelques bogues connus concernant les pilotes de stockage: https://github.com/AkihiroSuda/docker-issues

Juste au cas où quelqu'un voudrait avoir le dernier noyau debian "linux_3.16.7-ckt20-1 + deb8u3" avec les correctifs, mentionné plus tôt - je l'ai construit manuellement, et c'est sur https://fxposter.org/linux-image-3.16 .0-4-amd64_3.16.7-ckt20-1 + deb8u3a ~ test_amd64.deb.

incroyable! J'ai ce problème depuis quelques semaines maintenant, et je suppose que le correctif pour Ubuntu vient de sortir hier: P

Confirmer que la dernière mise à jour du noyau 14.04LTS vers 3.19.0-51 met fin à mes zombies java. Merci!

Debian a pris en charge ce problème.

DERNIERS RÉSULTATS DE TRAVAIL RAPIDES

| Distro | Solution de contournement |
| --- | --- |
| Général | Utilisez devicemapper / overlay / btrfs (mais cela peut causer un autre problème ..).
Si vous pouvez mettre à niveau AUFS et construire le noyau manuellement, vous pouvez également utiliser AUFS v20160111 ou version ultérieure. |
| Boot2Docker | : white_check_mark: mise à niveau vers v1.10.0 ou version ultérieure |
| Ubuntu 14.04LTS | : white_check_mark: Mettre à niveau le noyau vers 3.13.0-79.123 ou version ultérieure |
| Ubuntu 15.04 | : white_check_mark: mise à niveau du noyau vers la version 3.19.0-51.57 ou ultérieure |
| Ubuntu 15.10 | : white_check_mark: mise à niveau du noyau vers 4.2.0-30.35 ou version ultérieure |
| Debian 7 | : white_check_mark: Mettre à niveau le noyau vers 3.2.73-2 + deb7u3 (du paquet linux-image-3.2.0-4-amd64) ou version ultérieure |
| Debian 8 | : white_check_mark: mise à niveau du noyau vers 3.16.7-ckt20-1 + deb8u4 (du paquet linux-image-3.16.0-4-amd64) ou version ultérieure |
| Debian 9 | : white_check_mark: (ne prend pas en charge AUFS depuis le noyau 3.18-1 ~ exp1) |
| Gentoo | : white_check_mark: mise à niveau vers les plus récentes (: avertissement: non testé) |
| RHEL / CentOS | : white_check_mark: (ne prend pas en charge AUFS) |
| openSUSE | : white_check_mark: (ne prend pas en charge AUFS) |

Les distributeurs émettent des tickets

| Distro | Statut | URL du problème |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: Fermé | https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | : white_check_mark: Fermé | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | : white_check_mark: Fermé | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

la mise à niveau du noyau de 14.04LTS a fonctionné pour moi: +1:

Je suis sur OSX sur Boot2Docker version 1.10.2, build master: 611be10, Docker version 1.10.2, build c3959b1 et j'ai d'abord obtenu ceci 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).

Ensuite, j'ai essayé docker kill 38e1e2590dfa mais le processus se bloque pour toujours. 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"

Juste comme une note (je sais que c'est fermé mais je ne sais pas si cela a du sens de l'ouvrir en tant que nouveau problème). J'avais le même problème sur une version ultérieure jusqu'à ce que je passe à 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 Le problème est résolu dans le noyau 3.13.0-79.123 (le vôtre semble être 3.13.0-77)

Ce problème peut-il vraiment être résolu avec une mise à niveau du noyau? Nous rencontrons le même problème avec Docker 1.9.1 sur Ubuntu 14.04 avec 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 oui, ce problème était un problème de noyau. Il est possible que quelque chose d'autre puisse entraîner un comportement similaire ou s'il y a une régression dans le noyau. Cependant, veuillez ouvrir un nouveau problème si vous rencontrez des problèmes avec la version actuelle; gardez à l'esprit que docker 1.9.1 est EOL, donc ne recevra plus de mises à jour.

Je verrouille la discussion sur ce problème, car le problème d'origine ici a été résolu, et je veux empêcher ce problème de collecter des problèmes éventuellement sans rapport. Voir ce commentaire; https://github.com/docker/docker/issues/18180#issuecomment -193708192 pour les versions de noyau nécessaires pour résoudre ce problème