Ich stehe vor dem gleichen Problem. Ich untersuche.

Wir stehen auch vor dem gleichen Problem.

Ja, es ist ein Problem em Docker 1.9. Ich hatte auf 1.8.3 heruntergestuft und alle Probleme gelöst. Jetzt untersuche ich einen Workarround. werde hier posten! Tks

Ich habe das gleiche Problem mit Docker 1.9.1a

Ich habe Docker 1.8.3, daher kann die Situation durch die Installation einer anderen Version von Docker behoben werden. @bsao.

Wenn Sie dasselbe Problem mit Docker Version 1.9.1 haben, erstellen Sie a34a1d5

Sehen Sie das nur auf boot2docker?

Ich kann nicht auf einem Aktien-Ubuntu mit aufs oder auf meiner Maschine repo. Lassen Sie mich mit boot2docker versuchen, um zu sehen, ob ich dort repo kann.

+1 in Docker 1.9.1 für Ubuntu: 14.10 unter OSX

Dies ist ein Problem, das auftrat, nachdem ich VPN für die Arbeit aktiviert hatte. Selbst nachdem ich VPN ausgeschaltet und den Docker-Computer unter OSX neu gestartet hatte, trat dieses Problem weiterhin auf. Ich habe Docker 1.9.1 und dann 1.8.3 neu installiert und sehe immer noch das Problem. Verhindert, dass ich die meisten, wenn nicht alle meiner Docker auf dem Mac verwenden kann.

+1 in Docker 1.9.1 für Ubuntu 12.04 unter OS X 10.11

Auch Entwickler in meinem Büro sind zufällig darauf gestoßen.

Diese Version / Build hat funktioniert : Docker Version 1.9.0, Build 76d6bc9

Diese Version / Build hing : Docker Version 1.9.1, Build a34a1d5

@crosbymichael Ich habe es leider nicht in einer anderen Umgebung als Boot2Docker versucht.

Jemand mit dem Know-how von Git-Bisecting und Docker könnte die von @ chico1198 bereitgestellten Build-IDs verwenden!

Ich hatte das gleiche Problem mit 1.9.1 unter OSX El Capitan. Ein Downgrade auf 1.9.0 hat nicht geholfen.

Gleiches Problem hier unter OSX 10.9.3 mit:
Docker Version 1.9.1, Build a34a1d5
Docker Version 1.9.0, Build 76d6bc9

@crosbymichael Ich ps auxf Folgendes habe ich gesehen:

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 mit Docker 1.9.1 unter OSX 10.11 mit dem Versuch, ein Image aus Ubuntu 14.04 zu erstellen

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

Ein Downgrade auf Docker 1.8.3 ist meine vorübergehende Problemumgehung. Hier ist das target ich in meinem 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) 

Ich konnte das nicht reproduzieren. Hängt es immer am "Einrichten von Zertifikaten"? Haben Sie versucht, ein ^D zu senden, um eine Pipe zu schließen? Können Sie auch versuchen, ein SIGUSR1 an den Daemon zu senden und den Stack-Trace hier einzufügen, wenn er nicht mehr funktioniert?

+1 mit Docker 1.9.1 unter OS X 10.10

Ich habe versucht, mit @ostermans Makefile auf 1.8.3

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

Getestet durch verschiedene openjdk-Installationen in debian: jessie und ubuntu
OSX 10.11.1, boot2docker 1.9.1: hängt
OSX 10.11.1, boot2docker 1.9.0: funktioniert
Ubuntu 14.04 mit Docker 1.9.1: funktioniert

Die boot2docker vms wurden erstellt mit:
Docker-Maschine erstellen -d Virtualbox --virtualbox-boot2docker-url = https://github.com/boot2docker/boot2docker/releases/download/v1.9.0/boot2docker.iso
und
Docker-Maschine erstellen -d Virtualbox --virtualbox-boot2docker-url = https://github.com/boot2docker/boot2docker/releases/download/v1.9.1/boot2docker.iso

Unter Ubuntu 14.04 wurde Docker gemäß der Dokumentation unter https://docs.docker.com/engine/installation/ubuntulinux/ installiert.

+1, Docker 1.9.1 ausführen Build a34a1d5 unter OSX Yosemite 10.10.5.

Ich kann das nicht reproduzieren.

Gleiches Problem hier.
Gibt es eine Möglichkeit, unter Windows ein Downgrade auf eine frühere Version durchzuführen?

Hab es selbst gefunden.
https://github.com/docker/docker/releases

+1, Docker 1.9.1 @ El Capitan

+1, Docker 1.9.1 unter 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

Gleiches gilt für Docker-Computer unter OSX 10.11.1
Docker Version 1.9.1, Build a34a1d5
Docker-Maschine Version 0.5.1 (HEAD)

Ich kann dies auf dem Docker-Computer OS X 10.10.5 reproduzieren, daher kann dies etwas mit boot2docker zu tun haben. docker top gibt mir auch <defunct> für einen Java-Prozess;

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 Vielleicht hat einer von euch eine Idee, wo er suchen oder was er debuggen soll. Ich konnte nicht wirklich etwas finden

Wie viel RAM hat Ihre VM? Könnte OOM sein, da es so aussieht wie das
Prozess stirbt unerwartet. :enttäuscht:

Es sieht so aus, als wäre Speicher nicht das Problem, aber der <defunct> -Prozess verbraucht 100% CPU.

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

Der Container scheint ebenfalls hängen zu bleiben, und ich musste die VM neu starten, um sie zu töten

+1 Docker Version 1.9.1, Build a34a1d5, Win 7.

Ich bin auf ähnliche Probleme gestoßen, die sich als OOM herausstellten, obwohl der Befehl stats den für den Container verfügbaren Speicher anzeigt. Das Problem trat auf, kurz nachdem der Task-Manager 0 freien physischen Speicher angezeigt hatte, während die Statistiken weiterhin <100% zeigten.

Das Seltsame ist, dass der Prozess weiter lief und nicht getötet wurde. Ich kann es mit -m erneut versuchen, es ist jedoch seltsam, dass dies unter 1.9.x geschieht, aber (nach dieser Diskussion) nicht unter 1.8. Das gleiche auf einem 1 GB DigitalOcean-Droplet (ebenfalls 1.9.1) auszuführen, war ebenfalls erfolgreich. Vielleicht sollte man das tauschen, sollte das überprüfen

Es passierte mir tatsächlich immer wieder, nachdem ich 1.9.1 deinstalliert und 1.8.3 installiert hatte. Es sah so aus, als ob die Deinstallation auf dem Mac nicht sehr gründlich war, da das Starten der Shell unter 1.8.3 ohne Verzögerung erfolgte, im Gegensatz zu einem normalen ersten Lauf, bei dem SSH-Schlüssel und ähnliches eingerichtet wurden.

_USER POLL_

_Der beste Weg, um benachrichtigt zu werden, wenn sich Änderungen in dieser Diskussion ergeben, ist das Klicken auf die Schaltfläche Abonnieren oben rechts._

Die unten aufgeführten Personen haben Ihre aussagekräftige Diskussion mit einer zufälligen +1 gewürdigt:

@mattes

31 Teilnehmer zu diesem Thema und Zählen.

@ bean5 bitte halte deine Kommentare konstruktiv

@thaJeztah Ich wollte weder beleidigen noch dekonstruktiv sein. Ich möchte auf die Tatsache aufmerksam machen, dass Github die Anzahl der teilnehmenden Personen anzeigt ... und ich habe festgestellt , dass erstellen wollte, die +1 gemacht haben. Vielleicht war ich verwirrt von dem, was er meinte. Auf jeden Fall schaue ich mir dieses Thema mit großer Vorfreude an, da es mich in den letzten Wochen mehr als einmal betroffen hat. Ich bin froh, dass wir Informationen von verschiedenen Benutzern haben.

Ich kann dieses Problem in meinem Setup duplizieren (mit Docker Machine auf dem Mac).

Hier sind meine bisherigen Erkenntnisse.

Wie bereits auf anderen Postern erwähnt, war die Verwendung des boot2docker 1.9.1 ISO mit AUFS der einfachste Weg, dies zu duplizieren. Dieses Dockerfile sollte das Problem ziemlich schnell minimal reproduzieren:

FROM debian:jessie

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

Wenn ich mir dmesg ansehe, sehe ich einige AUFS-Fehler, nachdem ich versucht habe, einen solchen Build zu erstellen, aber ich bin nicht 100% sicher, dass sie zusammenhängen:

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

Wenn ich einen Docker 1.9.1-Computer erstelle, der overlay als Speichertreiber verwendet:

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

Der Prozess hängt NICHT und diese Zeile läuft erfolgreich! Es sieht so aus, als ob AUFS und / oder Kernel das Problem sind.

boot2docker / boot2docker _did_ stoßen beide Kernelversionen und AUFS-Commit für die Version 1.9.1 an. Dies sind also beide Faktoren, die ausgeschlossen oder weiter untersucht werden müssen:

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

Derzeit wird versucht, 1.9.0 ISO mit einer 1.9.1-Binärdatei zu verwenden, um festzustellen, ob die Oberfläche des potenziellen Fehlerbereichs weiter reduziert werden kann.

Die Docker-Datei funktioniert einwandfrei und hängt nicht an einer boot2docker 1.9.0-ISO mit einer Docker 1.9.1-Binärdatei. Das Problem scheint nicht bei Docker 1.9.1 zu liegen, sondern bei der Umgebung, in der es ausgeführt wird.

Ich verwende die Version 1.9.1 ohne Probleme auf aufs, habe aber deutlich mehr CPU / RAM / Speicher als die Standard-Computerkonfiguration.

Ich habe gerade versucht, den Speicher für meine VM auf 4 GB zu erhöhen, konnte aber trotzdem reproduzieren

@cpuguy83 AUFS on boot2docker 1.9.1?

Wie oben erwähnt, bündelt b2d eine sehr spezifische Version von AUFS.

Ja

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

Ich sehe auch, dass einige Java-Prozesse in einem Container nicht mehr funktionieren. Ich kann dieses Problem mit den folgenden Schritten reproduzieren
Führen Sie den Container aus:

docker run --rm -it myJavaContainerFromCentos7 bash

Erstellen Sie Foo.java mit folgendem:

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

Kompilieren und Ausführen führt zu einem nicht mehr funktionierenden Java-Prozess mit 1 Kern, der 100% CPU verwendet:
javac Foo.java && java Foo

jedoch ... wenn nach dem Druck ein System.exit(0); hinzugefügt wird, ist alles in Ordnung:

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

Versions Information:
osx 10.10.3
Docker 1.9.1
boot2docker version 1.9.1 uname -a ist "linux ci 4.1.13-boot2docker"
numproc = 1

Strace-Ausgabe mit 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 +++

strace output _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)                           = ?

Der Prozess ist jetzt hängen, aber Sie können den Container eingeben:

docker exec -it myContainer bash

und siehe folgendes:

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

Kurzer Blick auf die Statistiken:

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

In 1.8.3 funktioniert alles einwandfrei.

+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 unter OS X 10.11.1

Dieses Problem ist wirklich ziemlich bizarr. Wenn ich strace den fehlgeschlagenen Befehl apt-get , ist das Ende der Ausgabe:

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)

Wo diese Fehler (fehlerhafter Dateideskriptor) unbegrenzt wiederholt werden.

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 schlägt fehl? Dies könnte meinem vorherigen Beitrag entsprechen, in dem ich sah, dass Java "Hallo Welt" Zombie-Prozesse ohne explizite "System.exit (0)" verursacht. - oder vielleicht ist das ein ganz anderes Thema. Wenn ja, entschuldigen Sie den Lärm.

Was passiert mit Ihrer CPU, wenn Sie eine unbegrenzte Schleife durchlaufen?

@andrewgdavis Es ist bei 100%

Java "Hallo Welt" verursacht Zombie-Prozesse ohne explizite "System.exit (0);"

Das klingt sicherlich ähnlich wie das hier aufgetretene Problem.

Ich kann das b2d-Problem definitiv bestätigen (habe sogar die Halbierung vorgenommen, um es am positivsten für den 4.1.13-Kernel-Bump zu verfolgen). Ich kann auch auf 4.2.6 mit b2d reproduzieren.

Als zusätzlichen Knick befindet sich mein Gentoo-Host derzeit auch auf 4.1.13 + AUFS-Patches, und ich sehe genau das gleiche Problem, sodass wir definitiv alles ausgeschlossen haben, was b2d-spezifisch ist.

Ich denke, es könnte sich lohnen, Commits zwischen 4.1.12 und 4.1.13 zu durchsuchen, um zu sehen, ob irgendetwas, das damit zusammenhängen könnte, herausspringt.

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

Ja, etwas bricht vom Kernel ab 4.1.12 => 4.1.13. Ich kann bestätigen, dass das Backen einer boot2docker-ISO für die erstere diesen Fehler nicht auslöst, die erstere jedoch.

Es ist also nicht speziell auf boot2docker bezogen, sondern scheint auf die Kernel-Version bezogen zu sein, die mit AUFS interagiert.

oder vielleicht die spezifische Art und Weise, wie der AUFS-Treiber in Docker mit dem interagiert
neuerer Kernel - TBD, wahrscheinlich mit einer Linux-stabilen Git-Halbierung zwischen 4.1.12
und 4.1.13: weinen:

Ich habe eine haarsträubende Theorie ...

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

Das obige Commit ändert die Datei filemap.c in generic_perform_write (Strukturdatei * Datei, Struktur iov_iter * i, loff_t pos).

Unten ist der Teil des Codes, den ich persönlich testen möchte, da der Kommentar sowohl Deadlock- als auch Livelock-Rennbedingungen beschreibt und ich sehe, dass die CPU zu 100% gebunden ist. Aber das sind nur ich und meine Schlussfolgerungen.

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 man könnte dieses Commit während der Git-Halbierung als spezifischen

Beim Herunterfahren von mongodb ein ähnlicher Hang angezeigt. Auf jeden Fall in 1.9.x vorhanden. Nicht vorhanden in 1.8.x.

Ich konnte dieses Problem für mich selbst lösen, indem ich den Speicher der Docker-VM von 1024 auf 2048 MB erhöhte und 2 CPUs anstelle von 1 zuwies.

Werke:

VM: Ubuntu 14.04 (2 GB RAM)
Docker Engine: 1.9.1
Docker-Basis-Image: Ubuntu: Neueste

Funktioniert nicht:

VM: Ubuntu 15.10 (2 GB RAM)
Docker Engine: 1.9.1,1.9.0,1.8.3
Docker-Basis-Image: Ubuntu: Neueste , Ubuntu: 14.04

@marsinvasion Wenn möglich, können Sie die Ausgabe von uname -a auf beiden getesteten Systemen drucken?

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

VM: Ubuntu 15.10
Linux Ubuntu 4.2.0-19-generic # 23-Ubuntu SMP Mi 11.11. 11:39:30 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux

+1
Docker Version 1.9.1, Build a34a1d5 unter OS X 10.11.1

Unter OS X 10.9.5 mit Docker 1.9.1 begegnet.

Inspiriert von @marsinvasion , habe ich eine erfolgreiche

Ups, sprach bald. Beim Ändern einer Docker-Datei, an der ich arbeite, und beim erneuten Ausführen des Builds funktioniert es nicht mehr.

Sehen Sie auch diesen höllischen Fehler (Docker-Maschine boot2docker 1.9.1 unter OS X) aus einem zuvor erstellten Ubuntu: 15.04- Image. Es scheint erforderlich zu sein, meinen Docker-Server neu zu starten, damit diese Zombie-Container verschwinden.

Ich dachte, https://github.com/docker-library/java/issues/19 sei verwandt, aber vielleicht auch nicht. Hier bekommen wir einen Hang, da haben sie einen Fehler bekommen, weil sie "Java" nicht gefunden haben.

Als Problemumgehung wurde mein Server auf Overlay umgestellt. Davor wurden auch einige Zombie-Container erstellt.

Docker Version 1.9.1, Build a34a1d5 unter OS X 10.11.1

Weiß jemand, worum es bei der Migration eines vorhandenen boot2docker.iso-Systems auf https://docs.docker.com/engine/userguide/storagedriver/overlayfs-driver/ geht, oder ist es einfacher, eine vollständige Neuerstellung durchzuführen? Diese Seite enthält bedrohliche Warnungen zu CentOS-Image-Builds. Was sind die "yum" -Umgehungen, hängt sie mit https://github.com/docker/docker/issues/10180 zusammen?

Es ist in 1.9.1a behoben - installieren Sie dies, wenn Sie unter OSX arbeiten - https://github.com/docker/toolbox/releases/download/v1.9.1a/DockerToolbox-1.9.1a.pkg

Definitiv nicht durch Docker Toolbox 1.9.1a behoben. Leiden unter diesem Fehler mit dieser Version. Wenn ich auf die Kommentare zurückblicke, sehe ich so aus, als wäre ich nicht der einzige.

Nein, immer noch nicht bauen

Ich musste die VM in der Virtualbox löschen und von vorne beginnen, damit sie funktioniert.

Außerdem wurde mehrmals versucht, eine neue VM zu löschen und zu erstellen, ohne Erfolg.

1.9.1a installiert, docker-machine rm default und Docker Quickstart Terminal verwendet, um den Standardcomputer neu zu generieren. Neu erstellte Bilder (die von java:7-jre ) und ausgeführt, funktionieren immer noch nicht. Funktioniert weiterhin einwandfrei mit der oben vorgeschlagenen Overlay-Maschine:

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

^ danke! Ich kann bestätigen, dass das Overlay-Gerät funktioniert.

Die Verwendung von overlay als Engine-Speichertreiber funktionierte auch zur Behebung des Absturzes beim Herunterfahren von MongoDB.

Sie können den Dockerfile-Build-Fehler umgehen, indem Sie Oracle Java anstelle von OpenJDK installieren:

# 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

Aber ich habe den Umfang des Problems unterschätzt. Boot2docker 1.9.1 führt zu Zombie-Java-Prozessen, selbst auf CentOS-Containern, in denen openjdk einwandfrei installiert wird.
root 322 11.1 0.0 0 0 ? Zsl 18:43 29:48 [java] <defunct>

Ich kann meinen Docker-Server nicht mit --engine-storage-driver overlay konfigurieren, da ich CentOS-basierte Images erstelle und overlayfs nicht mit yum kompatibel ist (https://github.com/ Docker / Docker / Issues / 10180).

Ich bin sicher, dass Docker-Leute dies nicht empfehlen würden, aber die Art und Weise, wie ich dieses Blockierungsproblem überwunden habe, besteht darin, eine boot2docker.iso zu erstellen, die Docker 1.9.1 mit einem etwas älteren AUFS verwendet. Anweisungen unter https://github.com/boot2docker/boot2docker/issues/1099#issuecomment -163052066.

versuchte Orakel jdk1.7.0_75 und jdk1.8.0_65; beide hängen und erstellen einen nicht mehr existierenden Java-Prozess.

VON: https://github.com/docker/docker/issues/10589
@neverfox genau das gleiche Problem hier, mit dem gleichen Bild +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"
            }
        }
    }
}
]

Ich habe einfach docker run -it cassandra:2.1.11 und Ihr Terminal bleibt hängen, keine Möglichkeit, den Container anzuhalten. Sie müssen die gesamte VM stoppen.

+1

Konnte das Problem heute auf Docker 1.9.1 unter Mac OSX 10.11.1 (15B42) duplizieren.

Konnte es umgehen, indem Docker 1.9.0 installiert wurde

_Apologien für fehlende Informationen waren früher am Tag auf meiner Arbeitsmaschine - werden zu einem späteren Zeitpunkt aktualisierte Informationen bereitstellen _

: +1:

Gleiches gilt hier für Docker 1.9.1 und OS X 10.11.

Für Leute mit diesem Problem

Wir haben so verengen weit dies auf keine _docker_ Bug , sondern ein Kernel - https://github.com/docker/docker/issues/18180#issuecomment -161832035

• Wenn Sie über den Fortschritt informiert bleiben möchten, klicken Sie auf die Schaltfläche Abonnieren auf dieser Seite. Kommentieren Sie
• Wenn Sie bei der Lösung dieses Problems helfen möchten, kann das Ausführen eines Git-Bissect des Kernels https://github.com/docker/docker/issues/18180#issuecomment -161834068 helfen
• Denken Sie daran, dass jeder Kommentar mehr als 2000 E-Mails an Abonnenten verschickt und unzählige Welpen sterben werden: smile:

Gerade getestet Storage Driver: devicemapper (mit Server Version: 1.9.1 und Kernel 4.2.6), und der Fehler wird nicht reproduziert, so dass wir uns immer noch in einer "seltsamen Interaktion zwischen einigen Änderungen im neueren Kernel und den AUFS-Patches befinden "Land. :enttäuscht:

Getestet, und der Fehler im neuen 4.1.14-Kernel ist immer noch vorhanden. Wir sitzen also immer noch auf einem Commit, das auf 4.1.13 zurückportiert wurde und seltsam mit den AUFS-Patches interagiert (und hatten kein Glück, dass es bereits behoben wurde die Zwischenzeit).

Ich beschloss, es mit dem alten College zu versuchen und klonte das boot2docker-Repo. Anschließend wurde das aufs-Commit in der Docker-Datei auf die vorherige Version geändert. Also Docker 1.9.1 Kernel 4.1.13 + frühere AUFS-Version, die vor 1.9.1 ausgeliefert wurde. Die Kompilierung auf meinem Computer ist langsam ... gibt es ein Docker-Schwarm-Setup, das ich in Verbindung mit einer Git-Halbierung ausführen und die Ergebnisse aggregieren kann? das wäre süß

Auf jeden Fall werde ich meine Ergebnisse in Kürze veröffentlichen, wenn es funktioniert ...

aktualisieren:
4.1.13 + Dieses AUFS-Commit weist weiterhin das Problem auf.
ENV AUFS_COMMIT 1724fe65683d126a92c6baeea0b3c7d0306c63ef

Mir ist keine einfache Einrichtung zum Aggregieren der Ergebnisse bekannt, obwohl möglicherweise eine erstellt werden könnte.

FWIW, https://sources.debian.net/src/ca-certificates-java/jessie/debian/postinst.in/ ist das genaue Skript, das in diesem Paket ausgeführt wird, und https://sources.debian.net/src /ca-certificates-java/jessie/src/main/java/org/debian/security/UpdateCertificates.java/ ist die genaue Java-Quelle, die ausgeführt wird, wenn wir die hängende + defekte + gebundene CPU erhalten.

Bin heute in ein verwandtes Problem geraten (Java-Prozess hängt).

Host-Umgebung: Linux lenovo 4.2.0-19-generic # 23-Ubuntu SMP Mi 11.11. 11:39:30 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux
Distribution: Ubuntu 15.10
Docker Engine: 1.9.1
Docker-Maschine: 0,5,0 (04cfa58)

Ich folge dem Netzwerk-Multi-Host- Tutorial. Der einzige Unterschied ist, dass ich mit dem Orakel / NOSQL- Bild

@brunoborges ja, das könnte das gleiche Problem sein, siehe https://github.com/docker/docker/issues/18500#issuecomment -163334612

@brunoborges überprüfen Sie einfach Ihre boot2docker.iso-Version - wenn es 1.9.1 Sie versuchen, ein Downgrade auf 1.9.0 durchzuführen und Ihren Computer neu zu abzurufen .
Wenn Sie diesen Weg gehen, können Sie hier einen kurzen Bericht schreiben?

Also habe ich mich gefragt, warum dies nur auf Java passiert und nicht auf anderen Sprachen. In einem meiner vorherigen Beiträge konnte ich die grundlegendsten Reproduktionen durch einfaches Kompilieren und Ausführen detaillieren

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

für den Fehlerfall, der zu einem nicht mehr existierenden Java-Prozess führte
und dann

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

für den erwarteten (nicht verstorbenen) Fall.

Ich habe dann versucht, etwas Ähnliches mit Python zu reproduzieren. Ich war erfolglos - aber ich habe es versucht. Für Interessierte habe ich versucht, die letzte Strace-Ausgabe exit_group(0) = ? , die aus dem Zombie-Java-Prozess hervorgeht. (Dieser Link lieferte mir viele Informationen über Python-Threading / seccomp / etc http://stackoverflow.com/questions/25678139/how-do-you-cleanly-exit-after-enabling-seccomp-in-python)

Also ab ins Kernel-Land: Nachdem ich die boot2docker-ISO neu erstellt und mit den aufs-Versionen und Kernel-Versionen herumgespielt hatte (von denen nichts wirklich einen Unterschied machte), hatte ich die Nase voll davon, wie langsam der Kompilierungsprozess mit numproc = 1 war. Also habe ich es auf 6 geändert. ==> notiere nicht mehr 1 CPU (wer hat jetzt nur 1 CPU pro Tag?). Plötzlich der Fehlerfall

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

Angefangen zu arbeiten.

Das nächste, was Sie versuchen sollten, war natürlich, es wieder auf 1 CPU zu bringen. ==> FAIL. zurück zu einem nicht mehr existierenden Java-Prozess.

Also wollte ich mehr darüber erfahren, wie Java heruntergefahren wird. Es ist nicht gut definiert. aber mit nur 1 CPU konnte dieser Java-Prozess erfolgreich ausgeführt werden: (Bitte mach dich nicht über mein schreckliches Java lustig.)

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

Kann jemand anderes dieses Verhalten bitte bestätigen? << Frage ist jetzt strittig

Update: Selbst mit mehr als einem Kern kann ein nicht mehr funktionierender Java-Prozess auftreten. (Ich habe Cassandra-Cli ausgeführt und es ist passiert.)

Docker-Maschine 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

Das gleiche Problem beim Erstellen von Bitbucket-Servern zu haben - Update-Ca-Zertifikate funktionieren einwandfrei, aber der JDK-Posthook bleibt für immer hängen. Nur ein Problem bei Verwendung des 1.9.1 boot2docker. Zu RancherOS Image gewechselt und hatte keine Probleme. OSX 10.10.

Mit El Capitan, Docker 1.9.1 und Ubuntu 14.04.1 bekomme ich: Ca-Zertifikate-Java einrichten, die unendlich hängen.

@stremlenye rollte zurück auf 1.9.0. Hängt immer noch.

@brunoborges Docker 1.9.0oder boot2docker.iso 1.9.0?

@stremlenye Docker 1.9.0 ... Was sind die Anweisungen, um boot2docker.iso 1.9.0 in mein System zu bekommen?

@brunoborges Schauen Sie sich diesen Kommentar oben an:

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

carsten-ulrich-saitow-ag erklärt, wie man mit dem iso --virtualbox-boot2docker-url eine neue Docker-Maschine mit der ISO 1.9.0 erstellt. Dieser Rat hat meinen Speck gerettet! Sobald ich das getan habe, konnte ich mein JRE-RPM wieder in meinen Containern installieren.

@ mobsy74 @stremlenye hat es mit boot2docker 1.9.0 versucht und es hängt manchmal.

@brunoborges Danke, dass hast . Also bleibe ich bei 1.8.3, bis dieser Fehler behoben ist.

@stremlenye meinst du boot2docker 1.8.3?

@ Brunoborges ja

Hallo,
Ich hatte das gleiche Problem.
Das Problem wurde beim Downgrade der Docker-Tools von 1.9.1 auf 1.9.0 behoben
https://github.com/docker/toolbox/releases/download/v1.9.0/DockerToolbox-1.9.0.pkg

Das Aktivieren mehrerer CPUs (im Docker-Computer) hat dieses Problem für mich gelöst.

--virtualbox-cpu-count=4

@heiths können Sie bitte Versionen von Docker-Tools teilen?

imho, boot2docker sollte sich von aufs zu einem der anderen verfügbaren speichertreiber entfernen. Es gibt einen guten Grund, warum aufs nie in den Linux-Kernel gekommen ist.

@robvanmieghem Jeder Fahrer hat seine Grenzen. Aufs ist insgesamt recht stabil und Overlays haben einige Blockierungsprobleme (abhängig von der Verwendung).

@brunoborges DockerToolbox-1.9.1c - das hat bei mir unter Windows und OSX funktioniert.

@thaJeztah hat nie gesagt, dass Overlays die perfekte Lösung sind. Ich denke jedoch, dass btrfs eine gute Option für boot2docker ist. Boot2docker ist für das Ausführen von Docker-Containern vorgesehen. Abgesehen von der Tatsache, dass btrfs im Linux-Kernel vollständig unterstützt wird, ist es wirklich einfach, den Inhalt anzuzeigen.

Es gibt so viele Meinungen dazu wie es Kombinationen von Distribution und Dateisystem gibt :) Keine Lösung wird für alle Anwendungsfälle perfekt sein. Im Sinne von Open Source und Linux denke ich, dass die beste Entscheidung darin besteht, bessere Ergebnisse zu erzielen Unterstützung für mehrere Auswahlmöglichkeiten der Distribution. Wir haben bereits die Wahl zwischen Boot2Docker oder RancherOS und ich glaube, es wurde einige Arbeit geleistet, um boot2docker auf einer Debian-Distributionsbasis neu zu erstellen. Docker-Maschine wird Ubuntu auf Cloud und Bare Metal unterstützen, daher bin ich sicher, dass eine Ubuntu-basierte VM-ISO nicht schwer zusammen zu werfen ist, ebenso wie andere, wie eine auf Alpine oder CoreOS usw. Dann gibt es für jeden von ihnen Die Wahl des Dateisystems - wieder bietet RancherOS jetzt ZFS als optionale Installation an, während CoreOS standardmäßig BTRFS verwendete, und ich glaube, dass dies immer noch eine Option ist. Ab Kernel 3.19 unterstützt Ubuntu OverlayFS sofort - jeder, der auf einen Snappy Core basiert b2d Bild? ;)

Wenn wir nur die Benennung der Docker-Maschinenparameter standardisieren und die Verweise auf 'boot2docker' entfernen könnten, um Verwirrung zu vermeiden - die Verwendung des Parameters boot2docker-url zur Installation von RancherOS ist etwas unintuitiv;)

@ far-blue +1

@heiths +1. Dies löste es auch für mich unter OSX mit 1.9.1c

Wenn Sie die CPU auf> 1 setzen, wird das Problem für mich vermieden. 1.9.1c hat nicht geholfen.

@heiths @fredriksvensson Ich stop <all> / start <all> zeigten, dass das Problem nicht behoben ist. Ich würde Ihnen empfehlen, Ihre Umgebung auf die gleiche Weise zu überprüfen, um sicherzustellen, dass die Lösung für Sie stabil ist.
/ cc @timechanter

Oh, es ist definitiv nicht weg. Die 10% ige Chance auf einen Hang im Vergleich zu 100% Hang ist zumindest kurzfristig beherrschbar.

@heiths --virtualbox-cpu-count=4 auch für mich funktioniert.

@timechanter +1 Das Setzen von CPUs auf> 1 hat das Problem für mich mindestens einmal vermieden. sieht im Moment nach einer effektiven Problemumgehung aus.

OSX 10.10.5

Deinstallierte Docker-Toolbox 1.9.1. Ein Downgrade auf Docker Toolbox 1.9.0 hat bei mir funktioniert.

Gleiches Problem unter El Capitan MacOSX

@heiths --virtualbox-cpu-count=4 funktioniert auch für mich.

Ist mir in Windows 7 mit Docker Toolbox 1.9.1b und 1.9.1e passiert.

"Einrichten von ca-certificates-java (20130815ubuntu1) ..." - El Capitan MacOSX. Bitte helfen Sie, Jungs !!! Ich kann es nicht reparieren

@ troian88 Downgrade auf boot2docker.iso 1.9.0 oder 1.8.3.

@ troian88 , benutze eine Docker-Maschine mit mehreren CPUs.

Kann bestätigen, dass --virtualbox-cpu-count=2 eine vorübergehende Problemumgehung für ein hängendes Setting up ca-certificates-java mit Docker 1.9.1 ist

Für Leute mit diesem Problem

Wir haben so verengen weit dies auf keine _docker_ Bug , sondern ein Kernel - https://github.com/docker/docker/issues/18180#issuecomment -161832035

• Wenn Sie über den Fortschritt informiert bleiben möchten, klicken Sie auf die Schaltfläche Abonnieren auf dieser Seite. Kommentieren Sie
• Wenn Sie bei der Lösung dieses Problems helfen möchten, kann das Ausführen eines Git-Bissect des Kernels https://github.com/docker/docker/issues/18180#issuecomment -161834068 helfen
• Denken Sie daran, dass jeder Kommentar mehr als 2000 E-Mails an Abonnenten verschickt und unzählige Welpen sterben werden: smile:

@externl @stremlenye Danke.

Beim Betrachten der LWP-Stapel stellte ich fest, dass der Fehler durch aufs_destroy_inode .

Ich werde weiter darauf eingehen.

Es scheint ein Deadlock im Zusammenhang mit inode-> i_mutex zu sein .

# 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).

Hinweis

Die Leute sagen, dass der Fehler vermieden werden kann, wenn er auf mehreren CPUs ausgeführt wird.
Ich kann den Fehler jedoch immer noch mit meiner physischen 4-CPU-Box beheben. (obwohl <1% Wahrscheinlichkeit.)
--virtualbox-cpu-count=2 garantiert also NICHT, dass Sie den Fehler vermeiden können.

Beachten Sie, dass die Anzahl der CPUs immer noch wichtig ist.
Ich kann den Fehler deterministisch treffen, wenn ich taskset 0x1 java ausführe ( taskset weist dem Prozess bestimmte CPUs zu).

@AkihiroSuda, vielen Dank, dass Sie sich damit befasst haben. Halten uns auf dem Laufenden! :Herz:

Beachten Sie, dass dieses Problem auch unter Windows 7 auftritt, wenn Docker 1.8.3 verwendet wird.

Wir sehen die gleichen (genau die gleichen Stapelspuren wie in AkihiroSudas Kommentar oben) auf älteren Kerneln:
Linux 3.19.0-42-generic #48~14.04.1-Ubuntu SMP x86_64 mit Docker version 1.9.1, build a34a1d5

Ich kann die Behauptung von @AkihiroSuda über mehrere CPUs bestätigen - ich habe dies auch auf meinem Host mit 8 Kernen getroffen.

Das AUFS-Debugging sieht wirklich interessant aus - vielleicht lohnt es sich, ein Problem bei AUFS einzureichen und zu prüfen, ob die AUFS-Betreuer beim Debuggen helfen können? Es wäre wahrscheinlich hilfreich für sie, wenn wir nur mit AUFS (kein Docker) reproduzieren könnten, aber das ist nicht gerade trivial. :Lächeln:

@tianon Ich habe einen Beitrag über aufs-users verfasst: http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/5335

@AkihiroSuda , ich habe gesehen, dass dies mit einem Nicht-Java-Anwendungsfall zusammenhängt. Es wird nämlich versucht, einen gegabelten MongoDB-Daemon herunterzufahren. Dies tritt nicht beim Start von MongoDB oder bei normaler Verwendung auf, sondern zuverlässig beim Herunterfahren.

@jakirkham Danke, es scheint, dass eine bestimmte Thread-Konfiguration (die

Übrigens, beim zweiten Gedanken ist das Hängen von AUFS vielleicht eher ein "Ergebnis" des Fehlers als eine "Ursache" des Fehlers.
Ich beschäftige mich mit diesem Thema: http://www.serverphorums.com/read.php?12 , 673905
(Ich habe nicht bemerkt, dass zap_pid_ns_processes() vor zwei Tagen ebenfalls hängen blieb, da ich zu diesem Zeitpunkt Bash als Init-Prozess verwendet hatte. Https://github.com/docker/docker/issues/18180#issuecomment- 166186061)

https://github.com/docker/docker/issues/18180#issuecomment -161843456
@andrewgdavis , du hast ganz recht!

Der Fehler scheint eine Regression zu sein, die durch das Festschreiben von mm/filemap.c ) verursacht wird.

Ich habe eine Boot2Docker-ISO ( boot2docker-v1.9.1-fix1.iso ) erstellt, bei der das Commit 296291cd weggelassen wird: https://github.com/AkihiroSuda/boot2docker/releases/tag/v1.9.1-fix1

Hoffe es funktioniert für alle. : smiley:

Das Commit 296291cd erzeugt eine Endlosschleife von -EINTR in mm/filemap.c:generic_perform_write , die fs/aufs/xino.c:do_xino_fwrite() nicht tolerieren kann:

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

Da do_xino_fwrite() unendlich zap_pid_ns_processes() (ausgeführt in einem anderen LWP) nicht von schedule() wenn es auf einem einzelnen Prozessor ausgeführt wird.
Deshalb treffen wir den Fehler.

@ Gilles-Duboscq
Sie haben den Fehler festgestellt, weil Canonical das Commit 296291cd ursprünglich in den Kernel 3.19-Baum zurückportiert hat: http://kernel.ubuntu.com/git/ubuntu/ubuntu-vivid.git/commit/?id=6b08592b8acc677d5b9bb7986343fdd6e0ad3303

@ AkihiroSuda wow, danke für das Finden! Was sind die nächsten Schritte? Sollte dieser Patch zurückgesetzt werden oder gibt es eine Möglichkeit, den Patch zu verbessern? Denken Sie darüber nach, einen Patch an den Kernel Upstream zu senden?

@AkihiroSuda , dein Fix funktioniert wie ein Zauber. Vielen Dank!

@ thaJeztah

Das ist keine einfache Frage.
Ohne Commit 296291cd kann sendfile(2) nicht getötet werden.
Ich befürchte, dass dieses nicht tötbare sendfile in bestimmten Umgebungen ein Sicherheitsproblem verursachen kann (dh einen Erschöpfungsangriff eines anonymen Benutzers).

Ich versuche, Commit 296291cd zu verbessern, aber es kann eine Weile dauern.

Wie auch immer, ich habe diesen Fehler dem Kernel Bugzilla gemeldet: https://bugzilla.kernel.org/show_bug.cgi?id=109971

Ich habe auch einen Docker-Container akihirosuda/test18180 um das Debuggen zu vereinfachen: 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, in Ordnung, klingt nach einem Problem, ja. Vielen Dank für den Repro-Container und die Recherche; Zumindest gibt es eine ganz bestimmte Aufgabe zu bearbeiten, hoffentlich werden andere Leute mitmachen und versuchen, eine Lösung zu finden. Vielen Dank für Ihre bisher hervorragende Arbeit.

Ich wurde auf OS X El Capitan Darwin Kernel Version 15.2.0 getroffen
Docker Version 1.9.1, Build d12ea79c9de6d144ce6bc7ccfe41c507cca6fd35
boot2docker 1.9.1

Das Downgrade auf boot2docker 1.9.0 mit den folgenden Befehlen hat bei mir funktioniert:

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 wird 296291cd unterstützen.
http://article.gmane.org/gmane.linux.file-systems.aufs.user/5343

Der nächste Schritt besteht also darin, auf das Update von AUFS zu warten.

Du bist ein Held, @AkihiroSuda! Vielen Dank, dass Sie mit Upstream zusammengearbeitet haben, um dies herauszufinden! :Herz:

Wenn jemand @AkihiroSuda Fix anwenden

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

Für alle unter Ubuntu 14.04 sollte ein Downgrade auf Kernel 3.13.0-71 oder älter das Problem lösen. 296291cd wurde danach zurückportiert.

@ebpitts danke für den Tipp, hier sind die etwas relativen Schritte zum Downgrade des Ubuntu 14.04-Kernels auf 3.13.0-71 mit installiertem Docker 1.9.1.

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

Zu diesem Zeitpunkt sollten Sie beim Booten zwei Kernel zur Auswahl haben. Ich habe jedoch in einer Remote-Vagrant-Box über SSH ausgeführt, daher kein GRUB-Bootloader für mich. Daher habe ich den neueren Standardkernel (in meinem Fall 3.13.0-74) als Startoption entfernt:

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

Die Ausgabe des Befehls hatte einige Probleme mit der Aktualisierung von Grub, sodass Sie /boot/grub/grub.cfg überprüfen und feststellen können, welche Standardstartoption beim Neustart verwendet wird. Ich musste anscheinend diese Header entfernen / neu hinzufügen, aber sobald die grub.cfg -Datei gut aussah ( 3.13.0-71-generic war die einzige und erste Startoption), fahren Sie fort und starten Sie neu:

sudo reboot

Und dann zurück SSH in meine Box:

$ uname -r
3.13.0-71-generic

Aber jetzt schien Docker nicht zu funktionieren. Für eine vollständige Neuinstallation muss also zuerst Folgendes entfernt werden:

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

Und ehrlich gesagt, mein nächster Versuch, ein docker build auf demselben Container auszuführen, der am OP-Titel hing ("Einrichten von ca-certificates-java"), ist dieses Mal immer noch gestorben und hat meinen Computer gesperrt , aber jetzt, da ich keinen SSH-Zugang habe, werde ich nach Hause gehen und bis 2016 warten, um zu sehen, ob jemand anderes bis dahin eine bessere Lösung hat = /

Also ... ich kann nicht behaupten, dass selbst nach dem Downgrade des Kernels auf 3.13.0-71, nachdem dieses Problem unter Ubuntu 14.04 + Docker 1.9.1 aufgetreten ist, sogar effektiv ist. Yuck.

Ja, nur um es doppelt zu bestätigen, ich habe $ docker run -it --rm akihirosuda/test18180 und es hängt immer noch.

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

Dies erfolgt nach dem Downgrade von Ubuntu 14.04 auf die Kernel-Version 3.13.0-71 mit 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 Bist du sicher, dass das Kernel-Downgrade unter Ubuntu wirklich die Lösung ist?

Interessant, auch wenn ich den Speichertreiber explizit auf devicemapper in /var/default/docker :

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

und starten Sie den Docker-Dienst neu, indem Sie 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

Ich hänge immer noch im akihirosuda/test18180:latest Testbild.

Ich habe auf meiner Ubuntu 14-Box mit der rohen Binärdatei ein Downgrade auf Docker 1.8.3 (ohne apt-get nicht so einfach) durchgeführt. Hier sind die Schritte ... für alle anderen ... Ich bin wieder im Geschäft (bitte Hinweis: Ich habe den Kernel auch zuvor auf 3.13.0-71-generic herabgestuft (siehe oben).

Ich habe die 1.8.3-Binärdatei von https://get.docker.com/builds/Linux/x86_64/docker-1.8.3 installiert, sie dann auf /usr/bin/docker verschoben und ihr sudo chmod +x /usr/bin/docker ausführbare Berechtigungen erteilt.

Dann griff ich nach dem rohen sysvinit-debian -Skript, kommentierte den check_init() -Körper aus und ersetzte ihn durch einfach echo '' und ließ ihn in /etc/init.d . Dann habe ich es so eingestellt, dass es beim Start als root mit ln -s /etc/init.d/docker /etc/rc2.d/S99docker , und sudo reboot . Danach starte ich den Docker 1.8.3-Dienst beim Booten von einer Binärinstallation zurück. Ich weiß nicht, warum diese Schritte auf der Binärinstallationsseite auf der Docker-Website nicht wirklich dokumentiert sind. Sowieso.

$ 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

Sieht hier alles gut aus - ich kann $ docker run -it hello-world korrekt ausführen. Das Ausführen von akihirosuda/test18180 hängt tatsächlich noch (???), aber ich kann meinen ursprünglichen Container erstellen und ausführen, ohne an Setting up ca-certificates-java hängen zu bleiben, was mich überhaupt erst hierher gebracht hat.

Als Referenz bin ich auf Ubuntu 15.04 lebendig, Linux 3.19.0-42-generic. Auch betroffen.

Da ich kein Overlay verwenden kann (ich benötige RHEL-Gäste), habe ich eine btrfs- Partition auf einem Ersatzlaufwerk erstellt und in / var / lib / docker gemountet (Docker-Daemon zuvor stoppen). Docker verwendet btrfs jetzt gerne, doch das Bild von @akihirosuda hängt noch bei der zweiten Überprüfung (seltsam).

@ Mikeatlas
Vielen Dank, dass Sie mein test18180 Bild getestet haben.

Das Ergebnis ist nicht seltsam.
Der zweite Scheck ( Checking whether sendfile(2) is killable. ) hängt in alten Kerneln.
Sie benötigen einen neueren Kernel mit 296291cd, um die zweite Prüfung zu bestehen.

| AUFS? | Kernel enthält 296291cd? | Erwartetes Ergebnis |
| --- | --- | --- |
| Y | Y | Hängt (1. Scheck: Checking whether hitting docker#18180. ) |
| Y | N | Hängt (2. Scheck: Checking whether sendfile(2) is killable. ) |
| N | Y | Pass |
| N | N | Hängt (2. Scheck: Checking whether sendfile(2) is killable. ) |

@cfstras Danke, ich werde das untersuchen.

@cfstras , es ist reproduzierbar und ich habe # 19073 geöffnet.

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

BEARBEITEN:
Früher habe ich mich geirrt, warum Docker nach dem Ändern der Kernelversionen nicht funktioniert hat, aber ich kann bestätigen, dass das zusätzliche Paket für meinen Kernel installiert und Docker erneut installiert wurde. Dieses Problem wurde für mich behoben:

sudo apt-get Docker-Engine entfernen
sudo apt-get install linux-image-extra-3.13.0-71-generic
curl -sSL https://get.docker.com/ | Sch

@lwcolton interessant, linux-image-extra-3.13.0-71-generic ist kein Paket, das ich installieren wollte (aber ich habe die generischen Extras-Pakete später installiert, wie bereits erwähnt) .... aber ich hatte trotzdem den Eindruck, dass das AUFS-Modul weit älter ist als nur der relativ neue 3.13.0-71 Kernel. Unabhängig davon war ein Downgrade auf Docker 1.8.3 auch nicht allzu schmerzhaft, und wenn ich den Vorgang erneut durchführen müsste, würde ich es vorziehen, Docker an jedem Tag der Woche herunterzustufen, anstatt den Linux-Kernel herunterzustufen.

@dschep Hinweis für andere: Für den Wechsel zu OverlayFS ist unter Linux die Kernel-Version 3.18 + erforderlich. Wie auf Dockers Seite angegeben, ist _Over vielversprechend wie OverlayFS noch relativ jung.

@mikeatlas Ich denke, dies ist die bislang größte Einschränkung bei OverlayFS: "Daher ist es unwahrscheinlich, dass die Verwendung von yum in einem Container auf einem Docker-Host mithilfe des Overlay-Speichertreibers ohne Implementierung von Problemumgehungen funktioniert."

@brunoborges yum wird derzeit gepatcht, um mit Overlays zu arbeiten. Daher sollten neuere Versionen von yum bald in der Lage sein, mit Overlays zu arbeiten (es wird jedoch immer noch einige Probleme geben, sodass dies von Ihrem Anwendungsfall / Ihrer Situation abhängt Sie). Übermäßige Inode-Nutzung kann ein weiteres Problem sein.

Ich glaube, ich habe auch dieses Problem. In der Anrufverfolgung wird Apparmor erwähnt, aber das Deaktivieren von Apparmor macht keinen Unterschied. Durch die Verwendung von Devicemapper wurde das Problem behoben.

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>

Dies wurde in AUFS Upstream behoben - boot2docker wurde aktualisiert, um den Fix einzuschließen (der mit der nächsten Version veröffentlicht wird), und alle betroffenen Benutzer, die nicht von boot2docker betroffen sind, sollten die aktualisierte AUFS-Version anwenden. : +1:

@tianon hast du irgendwelche verweise auf die upstream bugs?

http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/5345 ist die Ankündigung der Upstream-Version - nicht sicher, ob es mehr Diskussionen gibt

http://comments.gmane.org/gmane.linux.file-systems.aufs.user/5337 enthält weitere Hintergrundinformationen zu diesem Problem

Dankeschön!

Dies wurde in AUFS Upstream behoben - boot2docker wurde aktualisiert, um den Fix einzuschließen (der mit der nächsten Version veröffentlicht wird), und alle betroffenen Benutzer, die nicht von boot2docker betroffen sind, sollten die aktualisierte AUFS-Version anwenden. : +1:

Nett.

Wurde die fehlerhafte Version von AUFS auf Docker Hub verwendet?

@tianon "Aktualisierte AUFS-Version anwenden" bedeutet für Nicht-Boot2docker-Benutzer (alle, die die Docker-Engine _not_ in der Entwicklung unter Mac OS X ausführen, für die b2d hauptsächlich entwickelt wurde), dass sie auf ein Linux-Kernel-Update mit warten müssen Dieser AUFS-Patch ... Oder ... könnte man in Anbetracht der Anzahl der anscheinend betroffenen Installationen / Personen vereinfachte / minimale Anweisungen von irgendjemandem zum Patchen von AUFS auf 4.1.13+ geben? Der Leitfaden für 4.1.13+ ist definitiv nicht trivial zu lesen; Das Patchen des Linux-Kernels selbst für dieses spezielle Update ist nichts für schwache Nerven.

Nur damit ich verstehe, wenn ich dieses boot2docker.iso erstelle und es in ~/.docker/machine/cache und eine neue VM mit docker-machine erstelle, verwendet die VM diese neue Kopie von boot2docker .

Nur damit ich verstehe, wenn ich diese boot2docker.iso erstelle und in ~ / .docker / machine / cache lege und eine neue VM mit Docker-Maschine erstelle, wird die VM diese neue Kopie von boot2docker verwenden.

Technisch gesehen würde das funktionieren, aber eine bessere Option könnte darin bestehen, --virtualbox-boot2docker-url , z.

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

Ah, ok, danke für die Klarstellung. Nun, das scheint dann zu funktionieren.

Senden einer Anfrage zum Aktualisieren von AUFS auf Canonical: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043

Wird es eine neue Version von boot2docker geben, da 1.9.1 das

bearbeiten. Mit dem @ AkihiroSuda boot2docker- Image konnte ich fortfahren. Danke an alle!

Ja, dieser Fix ist nach 1.9.1. @ Tianon sagte, eine Veröffentlichung ist geplant. Normalerweise geht es zur gleichen Zeit aus, zu der docker zur Veröffentlichung ausgeht. Da sie bei Veröffentlichungen in der Regel einem zweiwöchigen Zyklus folgen, gehe ich davon aus, dass eine Veröffentlichung unmittelbar bevorsteht. In der Zwischenzeit hat @AkihiroSuda einen Fix erstellt, den Sie verwenden können, oder Sie können Ihren eigenen erstellen, was wirklich unkompliziert ist und nur Zeit braucht.

Danke @AkihiroSuda für das Bild, es funktioniert! :) :)

+1 Debian Wheezy und Ubuntu 15.04

@ jakirkham Release ist ein 2-Monats-Zyklus, aber wir veröffentlichen sehr bald 1.10-rc1, boot2docker wird auch dafür eine rc1-Version haben.

Oh, sorry, muss es verwechselt haben. Danke, dass du mich klargestellt hast, @tiborvass. Hast du das verstanden, @shusso?

@ Jakirkham Ich habe, danke: +1:

Mit diesem Fix konnte ich eine Docker-Maschinen-Host-Virtualbox erstellen:

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

Derzeit scheinen Docker-Computer-Hosts, die ich in der Google Compute Engine mit der Option --driver google erstellt habe, dieses Problem zu haben. Der Google-Treiber bietet keine Möglichkeit, eine andere ISO-Datei anzugeben. Daher kann ich den obigen Fix nicht für Google Compute verwenden.

Kennt jemand eine Problemumgehung? oder in der Tat, wenn Google das Problem kennt oder wenn ich einen Fehlerbericht für sie einreichen sollte.

Wird der Google Docker-Maschinentreiber von Docker oder von Google verwaltet?

Treiber finden Sie hier; https://github.com/docker/machine/tree/master/drivers/google

Ich denke, das VM-Image, das auf Google Compute ausgeführt wird, muss hier sein:

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

Das ist:

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

Beim Durchsuchen der obigen Informationen scheint eine mögliche Problemumgehung die von @nathanleclaire vorgeschlagene zu sein

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

Es scheint auch eine Option "--google-machine-image" für den Google-Treiber für Docker-Machine verfügbar zu sein. Der Befehl:

$ gcloud Bilderliste berechnen

Listet die verfügbaren öffentlichen Bilder auf. Ich stelle fest, dass kürzlich ein neuer Ubuntu-List aufgestellt wurde.

Nur zur bestätigung:

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

Hat funktioniert. Ich werde auch untersuchen, wie man mit dem festen boot2docker ein benutzerdefiniertes Computer-Image erstellt und versucht, dieses mit der Docker-Maschine zu verbinden.

Wenn Sie dies auf boot2docker tun, geben Sie bitte den RC an
https://github.com/tianon/boot2docker-legacy/releases/tag/v1.10.0-rc1 a
Schuss. : +1:

@tianon Ich teste es mit dem folgenden Bild trecloux / docker-java-zombie
Und es sieht gut aus ... aber es hängt immer noch mit akihirosuda / test18180 Bild

Ernsthaft beeindruckende Arbeit @AkihiroSuda Du bist ein hartnäckiger Bug-Zapper !!

@trecloux benutzt du btrfs und wirst für sendfile hängen?
In diesem Fall handelt es sich um ein bekanntes Problem: https://github.com/docker/docker/issues/19073

@AkihiroSuda Ich verwende das Boot2docker-Image v1.10.0-rc1 mit 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

Hier ist die Ausgabe Ihres Testbildes:

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

@ Trecloux Es ist erwartetes Verhalten. Nichts hängt auf.

@ AkihiroSuda Ok, sorry. Und danke für deine Mühe :-)
Also @tianon : 1.10.0-rc1 sieht gut aus.

selbes Problem hier. Hängt beim Einrichten von Ca-Zertifikaten ab, die CPU wird verrückt ...

$ 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

MacOSX 10.11.2 ausführen

@sgoendoer versuchen, das Bild von @AkihiroSuda mit docker-machine create --driver virtualbox --virtualbox-boot2docker-url="file:/path_to_the_image" nameofmachine

Gibt es eine Idee für Nicht-Boot2docker-Benutzer, mit welcher Kernel-Version dies behoben werden soll? 3.13.0-71 scheint zu funktionieren, 3.13.0-74 und 3.13.0-76 scheinen kaputt zu sein ...

Gleiches Problem hier; Es gibt also keine einfache Lösung dafür?
Ist das in der RC-Version behoben? Ich versuche es jetzt. Obwohl es wahrscheinlich andere Probleme verursacht.

NEUESTE SCHNELLE ARBEITSPLÄTZE (Update: 21. Januar, 15:33 UTC)

| Distribution | Problemumgehung |
| --- | --- |
| Allgemeines | Verwenden Sie devicemapper / overlay / btrfs (dies kann jedoch ein anderes Problem verursachen ..) |
| Boot2Docker | : white_check_mark: Upgrade auf v1.10.0-rc1 |
| Ubuntu 14.04LTS | : arrow_down: Kernel auf 3.13.0-71 oder älter herabstufen |
| Ubuntu 15.04 | : arrow_down: Kernel auf 3.19.0-39 oder älter herabstufen (: Warnung: nicht getestet) |
| Ubuntu 15.10 | : arrow_down: Kernel auf 4.2.0-18 oder älter herabstufen |
| Debian 7/8 | : arrow_down: Downgrade des Kernels auf Version 3.16.7-ckt11 von Version 3.16.0 ( apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 ) oder älter |
| Debian 9 | : white_check_mark: (unterstützt AUFS seit Kernel 3.18-1 ~ exp1 nicht) |
| Gentoo | : white_check_mark: Upgrade auf aktuelle (: Warnung: nicht getestet) |
| RHEL / CentOS | : white_check_mark: (unterstützt AUFS nicht) |
| openSUSE | : white_check_mark: (unterstützt AUFS nicht) |

Händler stellen Tickets aus

| Distribution | Status | URL ausgeben |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: Geschlossen | https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | : white_medium_square: In Bearbeitung | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | Noch nicht bestätigt https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

@AkihiroSuda v1.10.0-rc1 behebt die Zombies nicht für mich, wer hat auch das Problem?

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)   

Nachdem nach einiger Zeit begonnen wurde, den nicht mehr existierenden Prozess zu beenden, erschien dies, aber danach existiert der Zombie immer noch:

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>

Dieses Mal ist es nicht mehr über Strace zugänglich, ich denke, es ist immer noch angebracht, auch wenn es nicht ist.
: ~ # strace -p 23810

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

@wzrdtales
Könnten Sie bitte LWP-Stapel wie unter https://github.com/docker/docker/issues/18180#issuecomment -166186061 erhalten?
Was ist deine Cmdline und Version von Phantomjs?

Sicher, Phantomjs Version: 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

Und auch der Aufgabenstapel:

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

So fügen Sie auch Systeminformationen hinzu:

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 Verwenden Sie Docker (nicht Boot2Docker) v1.10.0-rc1 unter Debian?
Es funktioniert nicht, da das Problem eher ein Fehler des Kernels als des Docker ist.

Ich untersuche Debian-Kernel und aktualisiere die Liste https://github.com/docker/docker/issues/18180#issuecomment -173436661.

@ AkihiroSuda y, es ist direkt auf Debian. Ich habe den Debian-Punkt auf Ihrer Liste überwacht, danke für den Hinweis :)

Für Debian sollten wir keine v3.16.7-ckt20-basierten Kernel verwenden
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 Ich habe die Liste aktualisiert, bitte verwenden Sie den ckt11-Kernel.

@AkihiroSuda : FWIW, ich glaube, die Empfehlung, auf v3.16.7-ckt11 herunterzustufen, gefährdet Sie für CVE-2016-0728, das eine bekannte öffentliche Root-Eskalation aufweist. Ich habe gerade https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 gepingt, aber zu Ihrer Information, bevor Sie ein Downgrade durchführen.

@ zmerlynn Vielen Dank für den Hinweis!

NEUESTE SCHNELLE ARBEITSPLÄTZE (Update: 26. Januar, 1:49 UTC)

| Distribution | Problemumgehung |
| --- | --- |
| Allgemeines | Verwenden Sie devicemapper / overlay / btrfs (dies kann jedoch ein anderes Problem verursachen.).
Wenn Sie AUFS aktualisieren und den Kernel manuell erstellen können, können Sie auch AUFS v20160111 oder höher verwenden. |
| Boot2Docker | : white_check_mark: Upgrade auf v1.10.0-rc1 |
| Ubuntu 14.04LTS | : arrow_down: Kernel auf 3.13.0-71 oder älter herabstufen |
| Ubuntu 15.04 | : arrow_down: Kernel auf 3.19.0-39 oder älter herabstufen (: Warnung: nicht getestet) |
| Ubuntu 15.10 | : arrow_down: Kernel auf 4.2.0-18 oder älter herabstufen |
| Debian 7/8 | : arrow_down: Downgrade des Kernels auf Version 3.16.7-ckt11 von Version 3.16.0 ( apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 ) oder älter |
| Debian 9 | : white_check_mark: (unterstützt AUFS seit Kernel 3.18-1 ~ exp1 nicht) |
| Gentoo | : white_check_mark: Upgrade auf aktuelle (: Warnung: nicht getestet) |
| RHEL / CentOS | : white_check_mark: (unterstützt AUFS nicht) |
| openSUSE | : white_check_mark: (unterstützt AUFS nicht) |

: Warnung: Das Herabstufen des Kernels kann ein Sicherheitsrisiko darstellen (z. B. CVE-2016-0728).

Händler stellen Tickets aus

| Distribution | Status | URL ausgeben |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: Geschlossen | https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | : white_medium_square: In Bearbeitung | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | : white_medium_square: In Bearbeitung | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

Wir sind auch auf dieses Problem gestoßen. Mongod steckt im R-Zustand mit 100% CPU fest.

Hier ist der wahre Trick, um die richtige Stapelverfolgung zu erhalten, die mich hierher führt:

echo "l"> / proc / sysrq-trigger

Von dort aus können Sie sehen, dass CPU 2 von AUFS in einer Inifinity-Schleife steckt

[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

Die Suche nach do_xino_fwrite führt mich hierher!

Ich scheine auf dieses Problem auch bei Debian Stretch zu stoßen, wo es beim Einrichten von Zertifikaten hängt.

Hier ist die Fehlermeldung: https://gist.github.com/clball/738feb46094802a1bcf7
Hier sind Versionsinformationen: https://gist.github.com/clball/494fe8598dd0cdfd6d10
Hier ist die Docker-Datei: https://gist.github.com/8778f8db143478d6c8ab

Was ist hier die Lösung für OSX? Gibt es bereits ein Docker-Update?

Noch nicht, aber es gibt einen Release-Kandidaten. (https://github.com/tianon/boot2docker-legacy/releases/tag/v1.10.0-rc2)

Die Lösung für mich war, das Speicher-Backend zu ändern.

Fügen Sie eine Zeile zu / etc / default / docker hinzu
¡¡Seien Sie vorsichtig, Sie verlieren Ihre Containerdaten!

DOCKER_OPTS="--storage-driver=devicemapper"

Ich empfehle, den Docker-Dienst zu beenden, den Docker-Ordner in / var / lib zu löschen und dann die Zeile hinzuzufügen und den Docker-Dienst neu zu starten.

@ referup-tarantegui Der Heads devicemapper gilt als furchtbar leistungsschwach, es sei denn, er ist direkt auf echten physischen Festplatten installiert. Sehen
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-nicht-so-tief-in-Docker-Speicher-Treiber eintauchen.html # 44
und
https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/ "Device Mapper- und Docker-Leistung"

Es gibt eine Version B für den Release Candidate2

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

Die Tabelle über Ubuntu wurde aktualisiert.

NEUESTE SCHNELLE ARBEITSPLÄTZE (Update: 3. Februar, 6.30 UTC)

| Distribution | Problemumgehung |
| --- | --- |
| Allgemeines | Verwenden Sie devicemapper / overlay / btrfs (dies kann jedoch ein anderes Problem verursachen.).
Wenn Sie AUFS aktualisieren und den Kernel manuell erstellen können, können Sie auch AUFS v20160111 oder höher verwenden. |
| Boot2Docker | : white_check_mark: Upgrade auf v1.10.0-rc3 |
| Ubuntu 14.04LTS | : white_check_mark: Aktualisieren Sie den Kernel auf 3.13.0-77.121hf1533043v20160201b1 (PPA) |
| Ubuntu 15.04 | : white_check_mark: Aktualisieren Sie den Kernel auf 3.19.0-49.55hf1533043v20160201b1 (PPA) |
| Ubuntu 15.10 | : white_check_mark: Kernel auf 4.2.0-27.32hf1533043v20160201b1 (PPA) |
| Debian 7/8 | : arrow_down: Downgrade des Kernels auf Version 3.16.7-ckt11 von Version 3.16.0 ( apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 ) oder älter |
| Debian 9 | : white_check_mark: (unterstützt AUFS seit Kernel 3.18-1 ~ exp1 nicht) |
| Gentoo | : white_check_mark: Upgrade auf aktuelle (: Warnung: nicht getestet) |
| RHEL / CentOS | : white_check_mark: (unterstützt AUFS nicht) |
| openSUSE | : white_check_mark: (unterstützt AUFS nicht) |

Händler stellen Tickets aus

| Distribution | Status | URL ausgeben |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: Geschlossen | https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | : white_medium_square: In Bearbeitung (ETA: 20. Februar) | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | : white_medium_square: In Bearbeitung | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

@AkihiroSuda , ich denke du meintest v1.10.0-rc2 für boot2docker oder vielleicht sollte der Link hierher gehen (https://github.com/boot2docker/boot2docker/releases/tag/v1.10.0-rc3).

@ Jakirkham Danke, habe den Link behoben.

rc3 ist auf dem offiziellen repo anstelle meiner gabel:
https://github.com/boot2docker/boot2docker/releases/tag/v1.10.0-rc3

Wir untersuchten die technischen Schulden, die uns zwangen, meine Gabel zu benutzen, und fanden das heraus
es war seit Docker-Maschine 0.5 behoben worden, also bewegen wir uns weiter und
nach oben. :Lächeln:

Übrigens für diejenigen, die Kernel auf die oben für Ubuntu-PPAs aufgeführten Chiluk-Patch-Versionen umstellen möchten. Für Ubuntu 14.04, linux-image-3.13.0-77-generic , wären Ihre Schritte beispielsweise:

$ 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

Dann müssen Sie Ihre /etc/default/grub -Konfiguration aktualisieren, dann sudo update-grub ausführen und dann den gepatchten neuen Kernel-Build neu starten. Wenn Sie dies noch nicht getan haben, finden Sie hier eine Anleitung zum Festlegen eines anderen Standardkerns in grub .

Ich kann bestätigen, dass dieses Problem unter Docker 1.10.0 nicht besteht, wodurch meine Situation auch unter OS X 10.11 behoben wurde. Ansonsten wollte ich auf 1.9.0 downgraden.

Ich bekomme immer noch das java Problem mit hängengebliebenen Containern / Prozessen auf Docker 1.10:

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

@AkihiroSuda Ich versuche Ihre schnellen Problemumgehungen (danke!), Aber ich kann den älteren Kernel nicht auf meinem Debian 8 (jessie) Server installieren. Ich bekomme:

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

Wenn ich @ mikeatlas- Vorschläge versuche (übrigens musste sudo apt-get install software-properties-common , damit sudo add-apt-repository ppa:chiluk/1533043 funktioniert), erhalte ich einen Update-Fehler, weshalb die Installation vermutlich nicht funktioniert

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

Meine Docker-Informationen:

$ 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 danke für den Tipp, software-properties-common benötigen, ich habe meinen Beitrag oben aktualisiert.

@jamshid : Nachdem Sie die PPA hinzugefügt und apt-get update , überprüfen Sie, welche Kernel für Ihren Computer verfügbar sind ... Es sieht so aus, als gäbe es einen neueren Build ( 3.13.0-78 ), aber ich sehe ihn nicht es ist verfügbar, nachdem ich selbst ein Update hier ausgeführt habe. Hier erfahren Sie jedoch, wie Sie herausfinden können, welche Kernel installiert werden können:

$ 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

Wenn Sie etwas in der Richtung von linux-image-3.13.0-77-generic oder höher nicht sehen, muss etwas anderes nicht richtig sein.

Oh, @jamshid, Sie führen Debian 8 aus? Hinweis oben: 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 auf Debian 8 gibt

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

Eine Stunde aktives Googlening, um das ckt11 -Paket zu finden, half nichts.
Bitte, irgendwelche Vorschläge, wie man den aktuellen Debian 8-Kernel herunterstufen kann?

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 Sie finden die zuvor installierten Pakete in /var/cache/apt/archives . Sie sollten in der Lage sein, ein Downgrade mit dpkg -i <old_package>.deb .

Bestätigt, dass die Installation des neuen Kernels von der PPA das Problem für mich behoben hat (Ubuntu 14.04.3 / Kernel 3.13.0-78-generic / Docker 1.9.1)
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043

Hat jemand die Downgrade-Anweisungen erhalten, um mit Debian (nicht Ubuntu) zu arbeiten? Ich frage mich, ob der Grund, warum mein apt-get update mit dem folgenden Fehler fehlschlägt (nach dem Hinzufügen des ppa-Repos):

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

Sind auf https://launchpad.net/~chiluk/+archive/ubuntu/1533043 nur Ubuntu-Pakete verfügbar

@jamshid Ubuntu ppa unterstützt Debian nicht.

Wenn 3.16.7-ckt11-1 + deb8u3 leider nicht mehr verfügbar ist, können Sie den neuesten Kernel patchen: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207#47

(Ich kann das Deb-Paket hochladen, wenn jemand es braucht)

Wenn jemand den Kernel braucht, habe ich ihn hier hochgeladen, er ist etwas neuer als deb8u3, aber es scheint nicht so, als hätte er den Fehler, zumindest bin ich eine Weile nicht darauf gestoßen, sondern habe ihn gepatcht Der neueste Kernel ist wahrscheinlich die bessere Lösung. Wenn Sie es jedoch brauchen:
https://wizardtales.com/linux-image-3.16.0-0.bpo.4-amd64_3.16.7-ckt11-1+deb8u6~bpo70+1_amd64.deb

@wzrdtales : +1:

Für diejenigen wie mich, die immer noch Schwierigkeiten haben, dies zu regeln, möchte ich Sie auf TINI als eine gute Lösung hinweisen:
https://github.com/krallin/tini

Mit wenigen Zeilen in der Docker-Datei habe ich einen anständigen Init-Prozess erhalten, mit dem Zombies entfernt werden können.
Dadurch kann der Übergang zum Devicemapper vermieden werden.

Prost,
Francesco

Also benutze ich Tini. Dies hat mir hier jedoch nicht geholfen, da das Problem beim Erstellen des Images aufgetreten ist.

Auch wenn ich einen Container betreibe, verwende ich tini, aber das hat mich immer noch betroffen.

@fflatorre
Vielen Dank für Informationen, aber das Zombie-Problem, das Tini lösen kann, scheint sich von diesem Problem zu unterscheiden.
https://github.com/docker/docker/issues/18180#issuecomment -167042078

Selbst mit Tini können wir einen Zombie bekommen:

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 Ich vergesse zu erwähnen, dass dieses Problem beim Erstellen des Images nicht auftritt . Wir erstellen ein sehr einfaches Image und dann wird die Bereitstellungslogik an eine Reihe von ansiblen Skripten delegiert. Während der Bereitstellung hing einer der Prozesse (kafka). TINI scheint dieses Problem bisher gemildert zu haben.
Ich erkenne an, dass dies möglicherweise keine Lösung für Sie ist. Ich würde sogar vorschlagen, ein Downgrade von Workaround auf Placebo durchzuführen :)
Hoffe wir können bekommen wird bald sortiert.

Ich hatte das gleiche Problem beim Ausführen von Docker 1.9.1 unter OSX 10.11.3:

$ docker -v
Docker version 1.9.1, build a34a1d5

Upgrade auf die neueste Docker Toolbox-Version behoben:

$ docker -v
Docker version 1.10.1, build 9e83765

Zur Information habe ich einige Probleme und Problemumgehungen im Zusammenhang mit AUFS / Overlay / BtrFS / ZFS / Devicemapper-Speichertreibern aufgelistet: https://github.com/AkihiroSuda/docker-issues/

Hoffe, dies kann denen helfen, die sich für # 18180 und andere interessieren.

@AkihiroSuda Ich habe versucht, dem Link https://launchpad.net/%7Echiluk/+archive/ubuntu/1533043/+packages zu folgen, aber ich darf die Seite nicht anzeigen.

Siehe auch: https://github.com/docker/toolbox/issues/318#issuecomment -184143546

@ schmunk42
Ich konnte auch nicht auf die Seite zugreifen.
Ich denke, Chiluk macht Pakete neu. Sie können ihn unter https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 fragen

Für Leute, die Probleme damit haben, erfahren Sie hier, wie Sie das Problem unter Ubuntu 14.04 mithilfe des vorgeschlagenen

Bevor wir beginnen, können wir bestätigen, dass wir auf einem betroffenen Kernel ausgeführt werden, indem wir Folgendes ausführen (dh <3.19.0-50 unter Ubuntu 14.04):

$ uname -r
3.19.0-49-generic

Da wir dies wissen, müssen wir zuerst die vorgeschlagenen Pakete Folgendes ausführen :

$ 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

Nachdem dies erledigt ist, installieren wir den aktualisierten Kernel:

$ 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

Und das lasst uns neu starten

$ sudo shutdown -r now

Nach dem Neustart können wir bestätigen, dass die neuesten jetzt auf dem neuesten Kernel ausgeführt werden:

$ uname -r
3.19.0-50-generic

Danke @vpetersson Ich versuche herauszufinden, was passieren wird, wenn diese Version des Kernels veröffentlicht wird. Wird die vorgeschlagene Installation nur überschrieben oder müssen Sie etwas tun, um wieder normal zu werden?

@IainColledge Ja, ich würde mir vorstellen, dass dies der Fall wäre, aber ich bin mir nicht ganz sicher.

Die Tabelle über Ubuntu und Debian wurde aktualisiert.

NEUESTE SCHNELLE ARBEITSPLÄTZE

| Distribution | Problemumgehung |
| --- | --- |
| Allgemeines | Verwenden Sie devicemapper / overlay / btrfs (dies kann jedoch ein anderes Problem verursachen.).
Wenn Sie AUFS aktualisieren und den Kernel manuell erstellen können, können Sie auch AUFS v20160111 oder höher verwenden. |
| Boot2Docker | : white_check_mark: Upgrade auf v1.10.0 oder höher |
| Ubuntu 14.04LTS | : white_check_mark: Kernel auf 3.13.0-79.123 oder höher aktualisieren |
| Ubuntu 15.04 | : white_check_mark: Kernel auf 3.19.0-51.57 oder höher aktualisieren |
| Ubuntu 15.10 | : white_check_mark: Kernel auf 4.2.0-30.35 oder höher aktualisieren |
| Debian 7/8 | : arrow_down: Kernel auf Version 3.16.7-ckt11 von Release 3.16.0 oder älter herunterstufen ( dpkg-Archiv von @wzrdtales) |
| Debian 9 | : white_check_mark: (unterstützt AUFS seit Kernel 3.18-1 ~ exp1 nicht) |
| Gentoo | : white_check_mark: Upgrade auf aktuelle (: Warnung: nicht getestet) |
| RHEL / CentOS | : white_check_mark: (unterstützt AUFS nicht) |
| openSUSE | : white_check_mark: (unterstützt AUFS nicht) |

Händler stellen Tickets aus

| Distribution | Status | URL ausgeben |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: Geschlossen | https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | : white_check_mark: Geschlossen | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | : white_medium_square: In Bearbeitung | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

Eine Sache noch; Ich habe einige bekannte Fehler in Bezug auf Speichertreiber aufgelistet: https://github.com/AkihiroSuda/docker-issues

Nur für den Fall, dass jemand den neuesten Debian-Kernel "linux_3.16.7-ckt20-1 + deb8u3" mit Patches haben möchte, den ich bereits erwähnt habe - ich habe ihn manuell erstellt und er befindet sich unter https://fxposter.org/linux-image-3.16 .0-4-amd64_3.16.7-ckt20-1 + deb8u3a ~ test_amd64.deb.

tolle! Ich habe dieses Problem jetzt seit ein paar Wochen und ich denke, das Update für Ubuntu wurde erst gestern veröffentlicht: P.

Die Bestätigung, dass das neueste 14.04LTS-Kernel-Update auf 3.19.0-51 meine Java-Zombies beendet. Vielen Dank!

Debian unterstützte dieses Problem.

NEUESTE SCHNELLE ARBEITSPLÄTZE

| Distribution | Problemumgehung |
| --- | --- |
| Allgemeines | Verwenden Sie devicemapper / overlay / btrfs (dies kann jedoch ein anderes Problem verursachen.).
Wenn Sie AUFS aktualisieren und den Kernel manuell erstellen können, können Sie auch AUFS v20160111 oder höher verwenden. |
| Boot2Docker | : white_check_mark: Upgrade auf v1.10.0 oder höher |
| Ubuntu 14.04LTS | : white_check_mark: Kernel auf 3.13.0-79.123 oder höher aktualisieren |
| Ubuntu 15.04 | : white_check_mark: Kernel auf 3.19.0-51.57 oder höher aktualisieren |
| Ubuntu 15.10 | : white_check_mark: Kernel auf 4.2.0-30.35 oder höher aktualisieren |
| Debian 7 | : white_check_mark: Upgrade des Kernels auf 3.2.73-2 + deb7u3 (des Pakets linux-image-3.2.0-4-amd64) oder höher |
| Debian 8 | : white_check_mark: Upgrade des Kernels auf 3.16.7-ckt20-1 + deb8u4 (des Pakets linux-image-3.16.0-4-amd64) oder höher |
| Debian 9 | : white_check_mark: (unterstützt AUFS seit Kernel 3.18-1 ~ exp1 nicht) |
| Gentoo | : white_check_mark: Upgrade auf aktuelle (: Warnung: nicht getestet) |
| RHEL / CentOS | : white_check_mark: (unterstützt AUFS nicht) |
| openSUSE | : white_check_mark: (unterstützt AUFS nicht) |

Händler stellen Tickets aus

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

Das Upgrade des Kernels von 14.04LTS hat bei mir funktioniert: +1:

Ich bin unter OSX auf Boot2Docker Version 1.10.2, Build Master: 611be10, Docker Version 1.10.2, Build c3959b1 und habe dies zuerst von Docker-Compose erhalten:

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

Dann habe ich docker kill 38e1e2590dfa ausprobiert, aber der Prozess hängt für immer. 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"

Nur als Hinweis (ich weiß, dass dies geschlossen ist, bin mir aber nicht sicher, ob es sinnvoll ist, es als neue Ausgabe zu öffnen). Ich hatte das gleiche Problem in einer späteren Version, bis ich zu Devmapper wechselte.

$ 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 Das Problem wurde im Kernel 3.13.0-79.123 behoben (Ihr Problem scheint 3.13.0-77 zu sein).

Kann dieses Problem wirklich mit einem Kernel-Upgrade gelöst werden? Wir haben das gleiche Problem mit Docker 1.9.1 unter Ubuntu 14.04 mit 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 ja, dieses Problem war ein

Ich sperre die Diskussion zu diesem Problem, da das ursprüngliche Problem hier behoben wurde, und ich möchte verhindern, dass dieses Problem möglicherweise nicht verwandte Probleme erfasst. Siehe diesen Kommentar; https://github.com/docker/docker/issues/18180#issuecomment -193708192 für die Kernelversionen, die zur Behebung dieses Problems erforderlich sind