私は同じ問題に直面しています。 調査中です。

私たちも同じ問題に直面しています。

はい、それは問題のem docker1.9です。 1.8.3にダウングレードし、すべての問題が解決しました。 現在、回避策を調査しています。 ここに投稿します！ Tks

docker1.9.1aでも同じ問題が発生します

私はdocker1.8.3を持っているので、別のバージョンのdockerをインストールするプロセスで状況が改善される可能性があります。 @bsao。

dockerバージョン1.9.1でこれと同じ問題が発生している場合は、ビルドa34a1d5

これはboot2dockerでのみ表示されますか？

aufsを使用したスト​​ックubuntuまたは自分のマシンでレポできません。 boot2dockerを試して、そこでレポできるかどうかを確認します。

OSXを使用したubuntu：14.10のDocker1.9.1で+1

これは、仕事でVPNをオンにした後に発生し始めた問題です。 VPNをオフにしてOSXでDockerマシンを再起動した後も、この問題が引き続き発生しました。 Docker 1.9.1を再インストールしてから1.8.3を再インストールしましたが、まだ問題が発生しています。 Macですべてではないにしてもほとんどのドッカーを使用できないようにします。

OS X10.11を使用するubuntu12.04のDocker1.9.1で+1

私のオフィスの開発者も偶然これに出くわしました。

このバージョン/ビルドは機能しました：Dockerバージョン1.9.0、ビルド76d6bc9

このバージョン/ビルドがハングしました：Dockerバージョン1.9.1、ビルドa34a1d5

@crosbymichael残念ながら、Boot2Docker以外の環境では試していません。

git-bisectingとdockerのノウハウを持っている人なら、@ chico1198が提供するビルドIDを使用できます。

OSX El Capitanの1.9.1でも同じ問題が発生しましたが、1.9.0にダウングレードしても効果はありませんでした。

OSX 10.9.3で同じ問題が発生しました：
Dockerバージョン1.9.1、ビルドa34a1d5
Dockerバージョン1.9.0、ビルド76d6bc9

@crosbymichael boot2dockerにログインして、 ps auxf 。これは、私が見たものです。

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>

ubuntu 14.04からイメージをビルドしようとして、OSX10.11のdocker1.9.1で+1

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

Docker 1.8.3へのダウングレードは、私の一時的な回避策です。 これがtargetで使用している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) 

これを再現できませんでした。 それは常に「証明書の設定」でハングしますか？ パイプを閉じるために^Dを送信してみましたか？ SIGUSR1をデーモンに送信して、スタックトレースがスタックしたときにここに貼り付けることもできますか？

OS X10.10のdocker1.9.1で+1

@ostermanのMakefileを使用して1.8.3にダウングレードしようとしましたが、SSHキーにも問題がありました。

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

debian：jessieとubuntu内で異なるopenjdkインストールを実行してテストしました
OSX 10.11.1、boot2docker 1.9.1：ハングする
OSX 10.11.1、boot2docker 1.9.0：動作します
Docker1.9.1を搭載したUbuntu14.04：動作します

boot2dockervmsは次のもので作成されました。
docker-machine create -d virtualbox --virtualbox-boot2docker-url = https://github.com/boot2docker/boot2docker/releases/download/v1.9.0/boot2docker.iso
そして
docker-machine create -d virtualbox --virtualbox-boot2docker-url = https://github.com/boot2docker/boot2docker/releases/download/v1.9.1/boot2docker.iso

Ubuntu 14.04では、 https： //docs.docker.com/engine/installation/ubuntulinux/のドキュメントに従ってdockerがインストールされました

+ 1、OSX Yosemite10.10.5でdocker1.9.1ビルドa34a1d5を実行します。

これは再現できません。

ここで同じ問題。
Windowsで以前のバージョンにダウングレードする方法はありますか？

自分で見つけました。
https://github.com/docker/docker/releases

+1、ドッカー1.9.1 @ El Capitan

+ 1、OS X10.11.1上のDocker1.9.1

+ 1、Docker 1.9.1a、OS X 10.10.5

+ 1、Docker 1.9.1ビルドa34a1d5、Windows 10

+ 1、Docker 1.9.1ビルドa34a1d5、OS X 10.11.1、Docker-Machine0.5.1ビルド7e8e38e

+1

OSX10.11.1のDockerマシンでも同じです
Dockerバージョン1.9.1、ビルドa34a1d5
docker-machineバージョン0.5.1（HEAD）

これはdocker-machine、OS X 10.10.5で再現できるので、boot2dockerに関連している可能性があります。 docker top <defunct>は、Javaプロセスの

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

/ cc @tianon @nathanleclaire @jeffdmおそらく、どこを見ればいいのか、何をデバッグすべきか考えている人がいるかもしれませんが、実際には何かを見つけることができませんでした。

VMにはどのくらいのRAMがありますか？ それがのように見えることを考えると、OOMである可能性があります
プロセスが予期せず終了します。 ：がっかり：

メモリは問題ではないように見えますが、 <defunct>プロセスは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

コンテナもスタックしているようで、VMを再起動して強制終了する必要がありました

+1 Dockerバージョン1.9.1、ビルドa34a1d5、Win7。

statsコマンドでコンテナに使用可能なメモリが表示されていても、同様の問題が発生し、OOMであることが判明しました。 この問題は、タスクマネージャーが0の空き物理メモリを示した直後に発生しましたが、統計は引き続き100％未満を示しました。

奇妙なことに、プロセスは実行され続けたので、強制終了されませんでした。 -mを使用して再試行できますが、これが1.9.xで発生するのは奇妙ですが、（この説明に従って）1.8では発生しません。 また、1GBのDigitalOceanドロップレット（これも1.9.1）で同じものを実行することに成功しました。 おそらくスワップを使用しているので、それを確認する必要があります

1.9.1をアンインストールして1.8.3をインストールした後も、実際に発生し続けました。 Macでは、sshキーなどを設定する通常の最初の実行とは異なり、シェルの起動が1.8.3で遅滞なく行われたため、アンインストールはそれほど完全ではなかったようです。

_USER POLL_

_このディスカッションに変更があったときに通知を受け取る最良の方法は、右上の[購読]ボタンをクリックすることです。_

以下にリストされている人々は、ランダムな+1であなたの有意義な議論に感謝しています：

@mattes

この問題とカウントに関する31人の参加者。

@ bean5コメントを建設的にしてください

@thaJeztah私はつもりはありませんでした。 githubが参加している人の数を示しているという事実に注意を引くつもりです...そして、 作成したいと思ったことを集めました。 たぶん私は彼の意味に混乱しました。 いずれにせよ、この問題は過去数週間に何度も私に影響を与えたので、私は大きな期待を持ってこの問題を見ています。 いろいろなユーザーからの情報をいただいてうれしいです。

セットアップでこの問題を再現できます（MacのDocker Machineを使用）。

これが私のこれまでの発見です。

他のポスターで指摘されているように、これを複製する最も簡単な方法は、AUFSでboot2docker 1.9.1ISOを使用することです。 このDockerfileは、問題をかなり迅速に再現する必要があります。

FROM debian:jessie

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

dmesgを見ると、そのようなビルドを試みた後にいくつかのAUFSエラーが表示されますが、それらが関連しているとは100％確信していません。

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

overlayをストレージドライバーとして使用するDocker1.9.1マシンを作成する場合：

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

プロセスはハングせず、この行は正常に実行されます。 AUFSやカーネルが問題のようです。

boot2docker / boot2docker _did_は、1.9.1リリースのカーネルバージョンとAUFSコミットの両方をバンプするため、これらは両方とも除外またはさらに調査する必要がある要因です。

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

現在、1.9.1バイナリで1.9.0 ISOを試し、潜在的なバグ領域の表面積をさらに減らすことができるかどうかを確認しています。

Dockerfileは正常にビルドされ、Docker1.9.1バイナリを使用するboot2docker1.9.0ISOでハングしません。 問題はDocker1.9.1にあるのではなく、Dockerが実行されている環境にあるようです。

私はaufsで問題なく1.9.1リリースを使用していますが、デフォルトのマシン構成よりもはるかに多くのCPU / RAM /ストレージを持っています。

VMのメモリを4GBに増やしてみましたが、それでも再現できます

@ cpuguy83 AUFS on boot2docker 1.9.1？

上記のように、b2dは非常に特殊なバージョンのAUFSをバンドルしています。

うん、

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

また、一部のJavaプロセスがコンテナー内で機能しなくなっていることもわかります。 次の手順でこの問題を再現できます
コンテナを実行します。

docker run --rm -it myJavaContainerFromCentos7 bash

次のコマンドでFoo.javaを作成します。

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

コンパイルして実行すると、100％cpuを使用する1つのコアを持つ無効なJavaプロセスが発生します。
javac Foo.java && java Foo

ただし... printlnの後にSystem.exit(0);が追加された場合、すべて問題ありません。

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

バージョン情報：
osx 10.10.3
docker 1.9.1
boot2dockerバージョン1.9.1uname-aは「linuxci4.1.13-boot2docker」です
numproc = 1

System.exit（0）;を使用したstrace出力。

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

プロセスはハングしましたが、コンテナに入ることができます。

docker exec -it myContainer bash

そして、以下を参照してください。

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

統計をざっと見てください：

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

1.8.3ではすべて正常に動作します。

+ 1、Dockerバージョン1.9.1、ビルドa34a1d5、OS X

+ 1、Dockerバージョン1.9.1、ビルドa34a1d5、OS X 10.10.5、Dockerマシンバージョン：0.5.1（HEAD）

+1

Dockerバージョン1.9.1、ビルドa34a1d5 、OS X 10.11.1（15B42）

+1

Dockerバージョン1.9.1、OS X10.11.1でa34a1d5をビルド

この問題は本当に奇妙です。 失敗したapt-getコマンドをstraceすると、出力の終わりは次のようになります。

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)

これらの（不正なファイル記述子）エラーが無期限にループし続ける場合。

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は失敗していますか？ これは、Javaの「helloworld」が明示的な「System.exit（0）」なしでゾンビプロセスを引き起こしているのを見た以前の投稿に対応している可能性があります。 -あるいは、それはまったく別の問題かもしれません。 騒音でごめんなさい。

無期限にループしている間、CPUはどうなりますか？

@andrewgdavis 100％です

java "hello world"は、明示的な "System.exit（0）;"なしでゾンビプロセスを引き起こします。

それは確かにここで遭遇した問題に似ているように聞こえます。

私は間違いなくb2dの問題を確認できます（4.1.13カーネルバンプに最も積極的に追跡するためにバイセクトを実行しました）。 4.2.6でもb2dで再現できます。

追加の問題として、私のGentooホストは現在4.1.13 + AUFSパッチを使用しており、まったく同じ問題が発生しているため、b2d固有のものはすべて除外しました。

4.1.12から4.1.13までのコミットを調べて、関連する可能性のあるものが飛び出すかどうかを確認する価値があると思います。

（つまり、https：//www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.1.13）

うん、カーネル4.1.12 => 4.1.13から何かが壊れています。 前者のboot2dockerISOをベイク処理してもこのバグは発生しませんが、前者は発生することが確認できます。

したがって、boot2dockerとは特に関係ありませんが、AUFSと相互作用するカーネルバージョンに関係しているようです。

または、DockerのAUFSドライバーが
新しいカーネル-未定、おそらく4.1.12の間にLinuxで安定したgitバイセクト
および4.1.13：cry：

私は髪の毛の頭脳理論を持っています...

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

上記のコミットにより、filemap.cがgeneric_perform_write（struct file * file、struct iov_iter * i、loff_t pos）に変更されます。

以下は私が個人的にテストしたいコードのチャンクです。コメントはデッドロックとライブロックの両方の競合状態を説明しており、CPUが100％に固定されているのがわかります。 しかし、それは私と私の結論へのジャンプマットだけです。

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 git bisect中にそのコミットを特定のテストポイントとして使用できます！

mongodbシャットダウンすると、同様のハングが発生します。 1.9.xに間違いなく存在します。 1.8.xには存在しません。

DockerマシンのVMのメモリを1024MBから2048MBに増やし、1つではなく2つのCPUを割り当てることで、この問題を自分で解決することができました。

作品：

VM：Ubuntu 14.04（2GB RAM）
Dockerエンジン：1.9.1
Dockerベースイメージ： ubuntu：latest

動作しません：

VM：Ubuntu 15.10（2 GB RAM）
Dockerエンジン：1.9.1,1.9.0,1.8.3
Dockerベースイメージ： ubuntu：latest 、 ubuntu：14.04

@marsinvasion可能であれば、テストした両方のシステムでuname -aの出力を出力できますか？

VM：Ubuntu 14.04
Linux ubuntu 3.19.0-25-generic＃26〜14.04.1-Ubuntu SMP Fri Jul 24 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 Wed Nov 11 11:39:30 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux

+1
Dockerバージョン1.9.1、OS X10.11.1でa34a1d5をビルド

Docker1.9.1を搭載したOSX10.9.5で発生しました。

@marsinvasionに触発されて、

おっと、すぐに話しました。 作業中のDockerfileを変更してビルドを再実行すると、動作が停止しました。

以前にビルドしたubuntu：15.04イメージから、この厄介なバグ（OSX上のdocker-machineboot2docker 1.9.1）も確認できます。 これらのゾンビコンテナをなくすには、Dockerサーバーを再起動する必要があるようです。

https://github.com/docker-library/java/issues/19は関連していると思いましたが、そうではないかもしれません。ここでハングアップし、「java」が見つからないというエラーが発生しました。

回避策として、サーバーをオーバーレイに切り替えました。 その前に、ゾンビコンテナもたくさん作成しました。

Dockerバージョン1.9.1、OS X10.11.1でa34a1d5をビルド

既存のboot2docker.isoシステムをhttps://docs.docker.com/engine/userguide/storagedriver/overlayfs-driver/に移行することに何が関係しているのか知っている人はい何ですか、 ますか？

1.9.1aで修正されています-OSXを使用している場合はこれをインストールしてください-https ：//github.com/docker/toolbox/releases/download/v1.9.1a/DockerToolbox-1.9.1a.pkg

Docker Toolbox1.9.1aでは完全に修正されていません。 そのバージョンでこのバグに苦しんでいます。 コメントを振り返ると、私だけではないようです。

いいえ、まだ構築されていません

virtualboxでVMを削除し、それを機能させるために最初からやり直す必要がありました。

また、新しいVMを数回削除して作成しようとしましたが、役に立ちませんでした。

1.9.1aをインストールし、 docker-machine rm default 、Dockerクイックスタートターミナルを使用してデフォルトのマシンを再生成しました。 再構築されたイメージ（ java:7-jreから派生）が実行されても、まだ機能しません。 上記のように構築されたオーバーレイマシンで引き続き問題なく動作します。

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

^ありがとう！ オーバーレイマシンが動作していることを確認できます。

エンジンストレージドライバーとしてoverlayを使用すると、MongoDBのシャットダウンハングを修正することもできました。

OpenJDKの代わりにOraclejavaをインストールすることで、Dockerfileビルドの失敗を回避できます。

# 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

しかし、私は問題の範囲を過小評価していました。openjdkが正常にインストールされるCentOSコンテナーでも、boot2docker1.9.1はゾンビJavaプロセスにつながります。
root 322 11.1 0.0 0 0 ? Zsl 18:43 29:48 [java] <defunct>

CentOSベースのイメージをビルドしているため、Dockerサーバーを--engine-storage-driver overlay構成できません。また、 overlayfsはyum （https://github.com/）と互換性がありません。 docker / docker / issues / 10180）。

Dockerの人々はこれを推奨しないと確信していますが、このブロッキングの問題を回避する方法は、少し古いAUFSでdocker1.9.1を使用するboot2docker.isoを構築することです。 https://github.com/boot2docker/boot2docker/issues/1099#issuecomment-163052066の手順。

oraclejdk1.7.0_75およびjdk1.8.0_65を試しました。 ハングし、機能しないJavaプロセスを作成します。

FROM： https ：
@neverfoxここでもまったく同じ問題、同じ画像+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"
            }
        }
    }
}
]

docker run -it cassandra:2.1.11を実行しただけで、ターミナルがスタックし、コンテナを停止する方法がありません。 VM全体を停止する必要があります。

+1

Mac OSX 10.11.1（15B42）を実行しているDocker1.9.1で本日以前に問題を再現できました

Docker1.9.0をインストールすることで回避できました

_情報が不足していることをお詫びします。日中の早い時間に私の作業機械にありました-後で更新された情報を提供します_

：+1：

ここでは、Docker1.9.1とOSX10.11でも同じです。

この問題を抱えている人のために

これまでのところ、これを_docker_バグではなく、現在のboot2dockerバージョンで使用されているカーネル内のAUFSと組み合わせたカーネルの問題に絞り込んでいます。 https://github.com/docker/docker/issues/18180#issuecomment-161832035を参照して

• 進捗状況を常に把握したい場合は、このページの[購読]ボタンを使用してください。 この問題の解決に役立つ可能性のある新しい情報がない場合は、コメントしないでください。
• これを解決したい場合は、カーネルのgit-bissectを実行すると、 https： //github.com/docker/docker/issues/18180#issuecomment-161834068が役立つ場合があります
• 各コメントは購読者に2000以上の電子メールを送信し、無数の子犬が死ぬことを忘れないでください：smile：

Storage Driver: devicemapper （ Server Version: 1.9.1とカーネル4.2.6を使用）をテストしたところ、バグは再現されないため、「新しいカーネルの変更とAUFSパッチの間の奇妙な相互作用」が続いています。 " 土地。 ：がっかり：

テスト済みで、バグはまだ新しい4.1.14カーネルに存在するため、4.1.13にバックポートされたコミットにまだ座っています。AUFSパッチと奇妙に相互作用します（暫定）。

私はそれに古い大学で試してみることにし、boot2dockerリポジトリのクローンを作成しました。 次に、dockerfileのaufscommitを以前のバージョンに変更しました。 したがって、docker1.9.1カーネル4.1.13 + 1.9.1より前に出荷された以前のAUFSバージョン。 私のマシンではコンパイルが遅いです... git bisectと組み合わせて実行し、結果を集約できるdocker swarmセットアップはありますか？ それは甘いでしょう。

とにかく、うまくいったらすぐに結果を投稿します...

更新：
4.1.13+このAUFSコミットはまだ問題を示しています。
ENV AUFS_COMMIT 1724fe65683d126a92c6baeea0b3c7d0306c63ef

結果を集約するための簡単なセットアップを私は知りませんが、おそらく構築することができます。

FWIW、 https： //sources.debian.net/src/ca-certificates-java/jessie/debian/postinst.in/は、そのパッケージで実行されている正確なスクリプトであり、 https：//sources.debian.net/src /ca-certificates-java/jessie/src/main/java/org/debian/security/UpdateCertificates.java/は、ハング+機能

今日、関連する問題が発生しました（Javaプロセスがハングします）。

ホスト環境：Linux lenovo 4.2.0-19-generic＃23-Ubuntu SMP Wed Nov 11 11:39:30 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux
ディストリビューション：Ubuntu 15.10
Dockerエンジン：1.9.1
Dockerマシン：0.5.0（04cfa58）

私はネットワークマルチホストチュートリアルに従っていoracle / nosqlイメージで遊んでいることです。 このイメージはOracleLinuxに基づいており、OpenJDKを使用しています。

@brunoborgesはい、同じ問題である可能性があります。https： //github.com/docker/docker/issues/18500#issuecomment-163334612を参照して

@brunoborgesは、boot2docker.isoのバージョンを確認するだけです。 1.9.1場合は、 1.9.0にダウングレードして、マシンを再作成し、イメージをもう一度プルすることができます。
このようにしたら、ここに短いレポートを書いていただけませんか？

だから私はなぜこれがJavaでのみ起こり、他の言語では起こらないのか疑問に思いました。 以前の投稿の1つで、コンパイルして実行するだけで、最も基本的な複製について詳しく説明することができました。

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

Javaプロセスが機能しなくなった障害の場合
その後

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

予想される（機能していない）ケースの場合。

次に、Pythonを使用して同様の何かを再現しようとしました。 私は失敗しました-しかし、私は試みました。 興味のある人のために、ゾンビJavaプロセスから見た最後のstrace出力exit_group(0) = ?を表示しようとしていました。 （このリンクは、Pythonスレッド/ seccompなどに関する多くの情報を提供してくれましたhttp://stackoverflow.com/questions/25678139/how-do-you-cleanly-exit-after-enabling-seccomp-in-python）

カーネルランドに移りましょう。boot2dockerisoを再構築した後、aufsバージョンとカーネルバージョンをいじりました（実際には何も違いはありませんでした）。コンパイルプロセスがnumproc = 1を使用するのがいかに遅いかにうんざりしました。 そこで、6に変更しました。==> 1 cpuではなくなったことに注意してください（1日に1 cpuしかないのは誰ですか？）。 突然の失敗事例

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

働き始めた。

明らかに、次に試すことは、1CPUに戻すことでした。 ==>失敗。 廃止されたJavaプロセスに戻ります。

それで、Javaがどのようにシャットダウンするかについてもっと調べたいと思いました。 それは明確に定義されていません。 しかし、たった1つのCPUで、このJavaプロセスを正常に実行できました:(私の恐ろしいJavaをからかってはいけません。）

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

class Foo {

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

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

他の誰かがこの動作を確認できますか？ <<質問は今や議論の余地があります

更新：複数のコアがある場合でも、無効なJavaプロセスが発生する可能性があります。 （私はcassandra-cliを実行していましたが、それが起こりました。）

docker-machine ssh myVM

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

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

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

bitbucket-server --update-ca-certificatesの構築で同じハングの問題が発生しても問題なく動作しますが、jdkposthookは永久にハングします。 1.9.1boot2dockerを使用する場合にのみ問題が発生します。 RancherOSイメージに切り替えましたが、問題はありませんでした。 OSX10.10。

El Capitan、Docker 1.9.1、Ubuntu 14.04.1を使用すると、次のようになります。無限にハングするca-certificates-javaを設定します。

@stremlenyeは1.9.0にロールバックしました。 まだハングします。

@brunoborges docker1.9.0またはboot2docker.iso1.9.0？

@stremlenye Docker 1.9.0 ...システムでboot2docker.iso1.9.0を取得するための手順は何ですか？

@brunoborges上記のこのコメントをチェックしてください：

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

carsten-ulrich-saitow-agは、-virtualbox-boot2docker-urlフラグを使用して1.9.0isoで新しいdocker-machineを作成する方法を説明しています。 そのアドバイスは私のベーコンを救った！ これを実行すると、JRERPMをコンテナーに再度インストールできるようになりました。

@ mobsy74 @stremlenyeはboot2docker1.9.0で試しましたが、時々ハングします。

@brunoborgesお試しいただきありがとうございます。 したがって、このバグが修正されるまで、1.8.3を使用します。

@stremlenyeはboot2docker1.8.3を意味しますか？

@brunoborgesはい

こんにちは、
私は同じ問題を抱えていました。
Dockerツールを1.9.1から1.9.0にダウングレードすると問題が解決しました
https://github.com/docker/toolbox/releases/download/v1.9.0/DockerToolbox-1.9.0.pkg

（Dockerマシンで）複数のCPUを有効にすると、これが解決しました。

--virtualbox-cpu-count=4

@heiths Dockerツールのバージョンを共有していただけますか？

imho、boot2dockerは、aufsから他の利用可能なストレージドライバーの1つに移行する必要があります。 aufsがLinuxカーネルに組み込まれなかったのには十分な理由があります。

@robvanmieghem各ドライバーには制限があります。 Aufsは全体的に非常に安定しており、overlayfsにはいくつかのブロッキングの問題があります（用途によって異なります）

@ brunoborgesDockerToolbox-1.9.1c-これはWindowsとOSXで機能しました。

@thaJeztahは、overlayfsが完璧なソリューションであるとは決して言いませんでした。 btrfsはboot2dockerに適したオプションだと思いますが、boot2dockerはdockerコンテナーの実行専用であり、btrfsがLinuxカーネルで完全にサポートされているという事実に加えて、内容を確認するのは非常に簡単です。

これについては、ディストリビューションとファイルシステムの組み合わせと同じくらい多くの意見があります:)すべてのユースケースに完璧なソリューションはないので、オープンソースとLinuxの精神では、より良いものを提供することが最善の決断だと思います。ディストリビューションの複数の選択肢のサポート。 すでにBoot2DockerまたはRancherOSの選択肢があり、Debianディストリビューションベースでboot2dockerを再構築するためにいくつかの作業が行われたと思います。 docker-machineはクラウド上のubuntuとベアメタルをサポートするので、ubuntuベースのvm isoは、alpineやCoreOSなどで構築されたものと同様に一緒に投げるのは難しいことではないと確信しています。ファイルシステムの選択-繰り返しになりますが、RancherOSはオプションのインストールとしてZFSを提供しますが、CoreOSはデフォルトでBTRFSを使用していましたが、それはまだオプションであり、カーネル3.19の時点でUbuntuはOverlayFSをサポートしています-SnappyCoreベースの誰でもb2dイメージ？ ;）

さて、docker-machineパラメーターの名前を標準化し、「boot2docker」への参照を削除して混乱を減らすことができれば、boot2docker-urlパラメーターを使用してRancherOSをインストールするのはやや直感的ではありません;）

@ far-blue +1

@ heiths + 1。 これは1.9.1cのOSXでも私にとってはそれを解決しました

CPUを> 1に設定すると、問題を回避できます。 1.9.1cは役に立ちませんでした。

@heiths @fredriksvenssonこの問題が複数のコンテナー環境でランダムに発生し、CPUの量も増やしようとしました（メモリもありますが、それは重要ではありません）。 stop <all> / start <all>の数サイクルは、問題が解決していないことを示しています。 同じ方法で環境をチェックして、ソリューションが安定していることを確認することをお勧めします。
/ cc @timechanter

ああ、それは間違いなくなくなっていません。 ただし、ハングする可能性が10％であるのに対して100％である場合は、少なくとも短期的には管理可能です。

@heiths --virtualbox-cpu-count=4も私のために働いた。

@timechanter +

OSX 10.10.5

Dockerツールボックス1.9.1をアンインストールしました。 Dockerツールボックス1.9.0にダウングレードするとうまくいきました。

El CapitanMacOSXでも同じ問題

@heiths --virtualbox-cpu-count=4は私にも役立ちます。

Docker Toolbox1.9.1bおよび1.9.1eを使用するWindows7で私に起こりました。

「ca-certificates-java（20130815ubuntu1）を設定しています...」-El CapitanMacOSX。 助けてください、みんな!!! 直せない

@ troian88をboot2docker.iso1.9.0または1.8.3にダウングレードします。

@ troian88 、複数のCPUを搭載した

--virtualbox-cpu-count=2がDocker 1.9.1でハングしているSetting up ca-certificates-java一時的な回避策であることを確認できます

この問題を抱えている人のために

これまでのところ、これを_docker_バグではなく、現在のboot2dockerバージョンで使用されているカーネル内のAUFSと組み合わせたカーネルの問題に絞り込んでいます。 https://github.com/docker/docker/issues/18180#issuecomment-161832035を参照して

• 進捗状況を常に把握したい場合は、このページの[購読]ボタンを使用してください。 この問題の解決に役立つ可能性のある新しい情報がない場合は、コメントしないでください。
• これを解決したい場合は、カーネルのgit-bissectを実行すると、 https： //github.com/docker/docker/issues/18180#issuecomment-161834068が役立つ場合があります
• 各コメントは購読者に2000以上の電子メールを送信し、無数の子犬が死ぬことを忘れないでください：smile：

@ externl @ stremlenyeありがとう。

LWPスタックを見ると、バグの原因はaufs_destroy_inodeであることがわかりました。

これについてさらに詳しく見ていきます。

iノード- です。

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

注意

複数のCPUで実行すると、バグを回避できると言われています。
ただし、物理的な4CPUボックスでバグを見つけることはできます。 （ただし、確率は1％未満です。）
したがって、 --virtualbox-cpu-count=2は、バグを回避できることを保証しません。

CPUの数は依然として重要であることに注意してください。
taskset 0x1 javaを実行すると、決定論的にバグにぶつかることがあります（ taskset特定のCPUをプロセスに割り当てます）。

@AkihiroSudaこれを

この問題は、Docker1.8.3を使用しているWindows7でも発生することに注意してください。

古いカーネルでも同じ（上記のAkihiroSudaのコメントとまったく同じスタックトレース）が見られます。
Linux 3.19.0-42-generic #48~14.04.1-Ubuntu SMP x86_64とDocker version 1.9.1, build a34a1d5

複数のCPUに関する@AkihiroSudaの主張を確認できます

そのAUFSデバッグは本当に興味深いように見えます-おそらく、AUFSに問題を報告し、AUFSメンテナがデバッグを支援できるかどうかを確認する価値がありますか？ AUFS（Dockerなし）だけで再現できれば、おそらく彼らにとって役立つでしょうが、それは必ずしも簡単なことではありません。 ：スマイル：

@tianon aufs-usersに投稿しました： http ： //permalink.gmane.org/gmane.linux.file-systems.aufs.user/5335

@ AkihiroSuda 、Java以外のユースケースでこれがハングするのを見ました。 つまり、フォークされたMongoDBデーモンをシャットダウンしようとしています。 これは、MongoDBの起動時や通常の使用では発生しませんが、シャットダウン時に確実に発生します。

@jakirkhamおかげで、バグをトリガーするには、特定のスレッド構成（Java、MongoDB、およびおそらく他のものに表示される傾向があります）が必要なようです。

ところで、考え直してみると、AUFSのハングは、バグの「原因」ではなく、バグの「結果」である可能性があります。
私はこのトピックを調べています： http ：
（2日前に初期化プロセスとしてbashを使用していたため、 zap_pid_ns_processes()もハングしていることに気づきませんでした。https：//github.com/docker/docker/issues/18180#issuecomment- 166186061）

https://github.com/docker/docker/issues/18180#issuecomment -161843456
@andrewgdavis 、あなたはまったく正しいです！

このバグは、Linuxカーネル（ mm/filemap.c ）へのコミット296291cdによって引き起こされたリグレッションのようです。

コミット296291cdを省略したBoot2DockerISO（ boot2docker-v1.9.1-fix1.iso ）を作成しました： https ：

それが皆のために働くことを願っています。 ：スマイリー：

コミット296291cdは、 mm/filemap.c:generic_perform_writeで無限の-EINTRループを生成しますが、 fs/aufs/xino.c:do_xino_fwrite()はこれを許容できません。

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

do_xino_fwrite()無限にループするため、単一のプロセッサで実行している場合、 zap_pid_ns_processes() （別のLWPで実行）はschedule()から戻ることはできません。
それが私たちがバグにぶつかっている理由です。

@ gilles-duboscq
Canonicalが最初にコミット296291cdをカーネル3.19ツリーにバックポートしたためにバグが発生しています： http ：//kernel.ubuntu.com/git/ubuntu/ubuntu-vivid.git/commit/？id = 6b08592b8acc677d5b9bb7986343fdd6e0ad3303

@AkihiroSudaうわー、見つけてくれてありがとう！ 次のステップは何ですか？ そのパッチを元に戻す必要がありますか、それともパッチを改善する方法はありますか？ アップストリームのカーネルにパッチを送信することを検討していますか？

@AkihiroSuda 、あなたの修正は魅力のように機能します。 ありがとう！

@thaJeztah

それは簡単な質問ではありません。
コミット296291cdがないと、 sendfile(2)は強制終了できません。
この殺せないsendfileは、特定の環境でセキュリティの問題（つまり、匿名ユーザーによるプロセス枯渇攻撃）を引き起こす可能性があるのではないかと心配しています。

commit 296291cdを改善しようとしていますが、時間がかかる場合があります。

とにかく、私はこのバグをカーネルのバグジラに報告しました： https ：//bugzilla.kernel.org/show_bug.cgi

また、デバッグを容易にするためにDockerコンテナーakihirosuda/test18180を作成しました： https ：

$ 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うーん、申し分なく、問題のように聞こえます、はい。 再現コンテナと調査に感謝します。 少なくとも、取り組むべき非常に具体的なタスクがあります。うまくいけば、他の人が参加して、解決策を見つける手助けをしようとします。 これまでの素晴らしい仕事をありがとうございました。

OS X El CapitanDarwinカーネルバージョン15.2.0に見舞われました
Dockerバージョン1.9.1、ビルドd12ea79c9de6d144ce6bc7ccfe41c507cca6fd35
boot2docker 1.9.1

以下のコマンドを使用したboot2docker1.9.0へのダウングレードは私のために機能しました：

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は296291cdをサポートする予定です。
http://article.gmane.org/gmane.linux.file-systems.aufs.user/5343

したがって、次のステップはAUFSの更新を待つことです。

あなたはヒーローです、@ AkihiroSuda！ これを理解するためにアップストリームと協力してくれてありがとう！ ：ハート：

誰かが@AkihiroSuda修正を適用したい場合、これは魅力のように機能します：

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

Ubuntu 14.04を使用している場合は、カーネル3.13.0-71以前にダウングレードすると問題が解決するはずです。 その後、 296291cdがバックポートさ

@ebpittsヒントをありがとう、 3.13.0-71にダウングレードするためのやや相対的な手順は次のとおりです。

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

この時点で、ブートロード中に選択する2つのカーネルが必要です。 ただし、SSH経由でリモートVagrantボックスで実行していたため、GRUBブートローダーがありませんでした...そこで、ブートオプションとして新しいデフォルトカーネル（私の場合は3.13.0-74）を削除しました。

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

コマンドの出力には、Grubの更新に関するいくつかの情報が含まれていたため、 /boot/grub/grub.cfgを調べて、再起動時にデフォルトのブートオプションがどのようになるかを確認できます。 このヘッダーの削除/再追加を行う必要があったようですが、 grub.cfgファイルが正常に見えたら（ 3.13.0-71-genericが唯一の最初の起動オプションでした）、次に進んで再起動します。

sudo reboot

そして、SSHを私のボックスに戻します。

$ uname -r
3.13.0-71-generic

しかし、今ではdockerが機能していないように見えました。 したがって、完全に再インストールするには、最初に削除する必要があります。

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

そして、正直なところ、OPタイトルにぶら下がっている同じコンテナでdocker buildを実行しようとすると（「ca-certificates-javaのセットアップ」）、今度はそれが死んでマシンがロックされました。 、しかし今はSSHアクセスがないので、家に帰って2016年まで待って、それまでに他の誰かがより良い修正を行っているかどうかを確認します= /

だから... Ubuntu 14.04 + Docker 1.9.1でこの問題が発生した後、カーネルを3.13.0-71にダウングレードした後でも、効果があるとは断言できません。 うん。

ええ、もう一度確認するために、 $ docker run -it --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="7">@296291cd</strong> tried to fix.

これは、Ubuntu14.04をAUFSを使用してカーネルバージョン3.13.0-71にダウングレードした後です。

$ 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は、Ubuntuでのカーネルのダウングレードが本当に修正されていると確信していますか？

私は明示的にストレージドライバを設定した場合でも、面白いdevicemapperで/var/default/docker ：

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

docker info実行して、Dockerサービスを再起動します。

$ 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

私はまだakihirosuda/test18180:latestテスト画像にぶら下がっています。

生のバイナリを使用して、Ubuntu14ボックスでDocker1.8.3（ apt-getなしで3.13.0-71-genericダウングレードしたことに注意してください。上記を参照してください）

https://get.docker.com/builds/Linux/x86_64/docker-1.8.3から1.8.3バイナリをインストールし、それを/usr/bin/dockerに移動して、 sudo chmod +x /usr/bin/docker実行可能権限を付与しました。

次に、生のsysvinit-debianスクリプトを取得し、 check_init()本文をコメントアウトして、単純にecho ''置き換え、 /etc/init.dドロップしました。 次に、ブート起動時にln -s /etc/init.d/docker /etc/rc2.d/S99dockerてrootとして実行するように設定し、 sudo reboot 。 その後、バイナリインストールからの起動時にdocker1.8.3サービスを実行します。 これらの手順がdockerのWebサイトのバイナリインストールページに実際に文書化されていない理由がわかりません。 いずれかの方法。

$ 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

ここではすべて良さそうです- $ docker run -it hello-world正しく実行できます。 akihirosuda/test18180を実行すると、実際にはハングします（???）が、 Setting up ca-certificates-javaにとらわれることなく、元のコンテナーをビルドして実行することができます。これにより、最初にここに移動しました。

参考までに、私はUbuntu 15.04 vivid、Linux3.19.0-42-genericを使用しています。 また影響を受けます。

オーバーレイを使用できないため（RHELゲストが必要）、スペアドライブにbtrfsパーティションを作成し、それを/ var / lib / dockerにマウントしました（以前はdockerデーモンを停止しました）。 Dockerはbtrfsをうまく使用していますが、 @ akihirosudaのイメージは2回目のチェックでハングします（奇妙な）。

@mikeatlas
test18180画像をテストしていただきありがとうございます。

結果は奇妙ではありません。
2番目のチェック（ Checking whether sendfile(2) is killable. ）は、古いカーネルでハングアップします。
2番目のチェックに合格するには、296291cdの新しいカーネルが必要です。

| AUFS？ | カーネルには296291cdが含まれていますか？ | 期待される結果|
| --- | --- | --- |
| Y | Y | ハング（最初のチェック： Checking whether hitting docker#18180. ）|
| Y | N | ハング（2回目のチェック： Checking whether sendfile(2) is killable. ）|
| N | Y | パス|
| N | N | ハング（2回目のチェック： Checking whether sendfile(2) is killable. ）|

@cfstrasありがとう、調べてみます。

@cfstras 、再現可能で、＃19073を開きました。

@mikeatlas RE： https ：

編集：
以前、カーネルのバージョンを変更した後にdockerが機能しなかった理由について間違っていましたが、カーネルの追加パッケージをインストールしてからdockerを再インストールすると、この問題が解決したことを確認できます。

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

@lwcolton興味深い、 linux-image-extra-3.13.0-71-genericは私がインストールしようと思っていたパッケージではありません（ただし、前述のように、後で汎用エクストラパッケージをインストールしました）...それでも、AUFSモジュールははるかに古いという印象を受けました比較的最近の3.13.0-71カーネルです。 とにかく、Docker 1.8.3へのダウングレードもそれほど苦痛ではありませんでした。もう一度プロセスを実行する必要がある場合は、LinuxカーネルをダウングレードするよりもDockerをダウングレードする方が好きです。

@dschep LinuxでOverlayFSに切り替えるにはカーネルバージョン3.18 +が必要であり、Dockerのページで引用されているように、 _OverlayFSと同じくらい有望ですが、まだ比較的若いことに。 使用する前に注意が必要です。_そして、OverlayFSをオンにする前に、イメージを事前にレジストリにプッシュして、イメージを効果的にバックアップする必要があるという警告が表示されます。

@mikeatlasこれがOverlayFSのこれまでの最大の制限だと思います：「_したがって、オーバーレイストレージドライバーを使用してDockerホスト上のコンテナー内でyumを使用すると、回避策を実装しないと機能しない可能性があります。_」

@brunoborges yumは現在、overlayfsで動作するようにパッチが適用されているため、まもなく、新しいバージョンのyumがoverlayfsで動作できるようになるはずです（ただし、まだいくつかの問題があるため、使用例や状況によって異なります。それら）。 iノードの過度の使用は別の問題になる可能性があります。

私もこの問題を経験していると思います。 コールトレースにはapparmorが記載されていますが、apparmorを無効にしても違いはありません。 devicemapperを使用すると、問題が解決しました。

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>

これはAUFSアップストリームで修正されました-boot2dockerは修正を含むように更新され（次のリリースでリリースされる予定です）、影響を受ける非boot2dockerユーザーは更新されたAUFSリリースを適用する必要があります。 ：+1：

@tianonアップストリームのバグへの参照はありますか？

http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/5345はアップストリームリリースの発表です-それ以上の議論があるかどうかは

http://comments.gmane.org/gmane.linux.file-systems.aufs.user/5337には、この問題の背景となる議論の詳細があります。

ありがとうございました！

これはAUFSアップストリームで修正されました-boot2dockerは修正を含むように更新され（次のリリースでリリースされる予定です）、影響を受ける非boot2dockerユーザーは更新されたAUFSリリースを適用する必要があります。 ：+1：

いいね。

バグのあるバージョンのAUFSがDockerHubで使用されましたか？

@tianon 「更新されたAUFSリリースを適用する」とは、boot2docker以外のユーザー（主にb2dが構築されているMac OS Xで開発中のdockerエンジンを実行しているすべてのユーザー）がLinuxカーネルの更新を待つ必要があることを意味します。このAUFSパッチ...または...影響を受けていると思われるインストール/人の数を考慮すると、AUFSを4.1.13+にパッチする方法について、簡単で最小限の指示を誰かが提供できますか？ 4.1.13+のガイドは、読むのが

私はこれをビルドする場合、私は理解してちょうどそうboot2docker.isoとに入れて~/.docker/machine/cacheとして新しいVMを作成しますdocker-machine VMは、この新しいコピーに使用することboot2docker 。

このboot2docker.isoをビルドして〜/ .docker / machine / cacheに配置し、Docker-machineを使用して新しいVMを作成し、VMがこの新しいboot2dockerのコピーを使用するかどうかを理解しました。

技術的にはそうです、それはうまくいくでしょう、しかしより良いオプションは--virtualbox-boot2docker-urlを使うことかもしれません、例えば：

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

ああ、わかりました、明確にしてくれてありがとう。 さて、これはその時働いているようです。

AUFSをCanonicalに更新するリクエストを送信しました： https ：

1.9.1には修正が含まれていないようですが、boot2dockerの新しいリリースはありますか？

編集します。 @AkihiroSuda boot2docker画像で、続行できました。 みんなありがとう！

ええ、この修正は1.9.1以降です。 @tianonはリリースが計画されていると言った。 通常、 dockerがリリースされると同時に消えます。 リリースは2週間のサイクルに従う傾向があるため、リリースが差し迫っていると思います。 暫定的に、 @ AkihiroSudaは、使用できる修正または独自の修正を作成しました。これは非常に簡単で、時間がかかります。

画像をありがとう@AkihiroSuda 、それは動作します！ :)

+1 DebianWheezyとUbuntu15.04

@jakirkhamのリリースは2か月周期ですが、まもなく1.10-rc1をリリースします。boot2dockerにもそのためのrc1バージョンがあります。

ああ、すみません、それを混ぜたに違いありません。 @tiborvass、私をまっすぐにしてくれてありがとう。 @shusso、あなたはそれを捕まえましたか？

@jakirkhamやった、ありがとう：+1：

この修正を使用して、docker-machineホストvirtualboxを作成することができました：

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

現在、-driver googleオプションを使用してGoogle Compute Engineで作成したdocker-machineホストには、この問題があるようです。 グーグルドライバーには別の.isoを指定するオプションがないため、グーグルコンピューティングで上記の修正を使用することはできません。

誰かが回避策を知っていますか？ または実際、グーグルが問題を認識している場合、またはどこにバグレポートを提出する必要があるか。

google docker-machineドライバーはdockerによって維持されていますか、それともgoogleによって維持されていますか？

ドライバーはここにあります。 https://github.com/docker/machine/tree/master/drivers/google

Google Computeで実行されているVMイメージは、次のようになっている必要があると思います。

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

あれは：

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

上記をスキャンすると、潜在的な回避策は@nathanleclaireによって提案されたもののように見えます

$ docker-machine create -d google--engine-storage-driverオーバーレイオーバーレイ

docker-machineのgoogleドライバーで使用できる「--google-machine-image」オプションもあるようです。 コマンド：

$ gcloudコンピューティングイメージリスト

利用可能な公開画像を一覧表示します。 最近、新しいubuntuwilyが登場したことに気づきました。

ただ確認するため：

$ docker-machine create -d google--engine-storage-driverオーバーレイオーバーレイ

働いた。 また、固定のboot2dockerを使用してカスタムマシンイメージを作成し、それをdocker-machineに接続する方法についても調査します。

boot2dockerでこれを打つ人には、RCを渡してください。
https://github.com/tianon/boot2docker-legacy/releases/tag/v1.10.0-rc1 a
ショット。 ：+1：

@tianon次の画像でテストしますtrecloux / docker-java-zombie
そしてそれはよさそうだ....しかしそれはまだakihirosuda / test18180画像でハング

真剣に印象的な作品@AkihiroSudaあなたは1つの永続的な

@treclouxはbtrfsを使用していて、sendfileでハングアップしていますか？
もしそうなら、それは既知の問題です： https ：

@AkihiroSuda私はaufsでv1.10.0-rc1boot2dockerイメージを使用しています：

$ 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

テスト画像の出力は次のとおりです。

$ 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これは予想される動作です。 何もハングアップしていません。

@AkihiroSudaわかりました、ごめんなさい。 そしてあなたの努力に感謝します:-)
だから@tianon ：1.10.0-rc1はよさそうだ。

ここで同じ問題。 CA証明書の設定にハングアップし、CPUが混乱します...

$ 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

MacOSX10.11.2を実行している

@sgoendoerは@AkihiroSudaの画像をdocker-machine create --driver virtualbox --virtualbox-boot2docker-url="file:/path_to_the_image" nameofmachine使用しようとします

boot2docker以外のユーザーの場合、これが修正されるカーネルバージョンはありますか？ 3.13.0-71は機能しているようで、3.13.0-74と3.13.0-76は壊れているようです...

ここで同じ問題。 それで、これに対する簡単な修正はありませんか？
これはRCバージョンで修正されていますか？ 今それを試してみてください。 それはおそらく他の問題を引き起こしますが。

最新のクイックワークアラウンド（更新：1月21日15:33 UTC）

| ディストリビューション| 回避策|
| --- | --- |
| 一般| devicemapper / overlay / btrfsを使用します（ただし、別の問題が発生する可能性があります。）|
| Boot2Docker | ：white_check_mark： v1.10.0-rc1にアップグレード|
| Ubuntu 14.04LTS | ：arrow_down：カーネルを3.13.0-71以前にダウングレードする|
| Ubuntu 15.04 | ：arrow_down：カーネルを3.19.0-39以前にダウングレードします（：warning：テストされていません）|
| Ubuntu 15.10 | ：arrow_down：カーネルを4.2.0-18以前にダウングレードする|
| Debian 7/8 | ：arrow_down：カーネルをバージョン3.16.7にダウングレード-リリース3.16.0のckt11（ apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 ）以前|
| Debian 9 | ：white_check_mark :(カーネル3.18-1〜exp1以降はAUFSをサポートしていません）|
| Gentoo | ：white_check_mark：最近のものにアップグレードします（：warning：テストされていません）|
| RHEL / CentOS | ：white_check_mark：（AUFSをサポートしていません）|
| openSUSE | ：white_check_mark：（AUFSをサポートしていません）|

ディストリビューターはチケットを発行します

| ディストリビューション| ステータス| 発行URL |
| --- | --- | --- |
| Boot2Docker | ：white_check_mark：クローズ| https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | ：white_medium_square：進行中| https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | まだ確認されていません| https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

@AkihiroSuda v1.10.0-rc1は私のためにゾンビを修正していません、誰もが問題を抱えていますか？

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)   

しばらくして無効なプロセスでstraceを開始した後、これが表示されましたが、この後もゾンビは存在します。

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>

今回はstrace経由でアクセスできなくなりましたが、接続されていなくても接続されていると思います。
：〜＃strace -p 23810

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

@wzrdtales
https://github.com/docker/docker/issues/18180#issuecomment -166186061のようにLWPスタックを取得して
また、あなたのコマンドラインとphantomjsのバージョンは何ですか？

確かに、phantomjsバージョン：1.9

コマンドライン

$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

また、タスクスタック：

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

また、システム情報を追加するには：

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 DebianでDocker（Boot2Dockerではなく）v1.10.0-rc1を使用していますか？
問題はDockerのバグではなくカーネルのバグであるため、機能しません。

Debianカーネルを調べており、リストhttps://github.com/docker/docker/issues/18180#issuecomment-173436661を更新し

@AkihiroSuda y、直接debianにあります。 私はあなたのリストのDebianポイントを監督しました、指摘してくれてありがとう:)

Debianの場合、v3.16.7-ckt20ベースのカーネルを使用しないでください
http://kernel.ubuntu.com/git/ubuntu/linux.git/tag/?h=linux-3.16.y&id=v3.16.7-ckt20
http://kernel.ubuntu.com/git/ubuntu/linux.git/commit/?h=linux-3.16.y&id=475a23000dd8d2f264bab9d6eb71a2a6b9d4de72

@wzrdtalesリストを更新しました。ckt11カーネルを使用してください。

@AkihiroSuda ：FWIW、 v3.16.7-ckt11にダウングレードすることをお勧めすると、パブリックルートエスカレーションが知られているCVE-2016-0728のリスクにさらされると思います。 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207にpingを実行しましたが、ダウングレードする前に参考までに。

@zmerlynnご指摘ありがとうございます！

最新のクイックワークアラウンド（更新：1月26日1:49 UTC）

| ディストリビューション| 回避策|
| --- | --- |
| 一般| devicemapper / overlay / btrfsを使用します（ただし、別の問題が発生する可能性があります）。
AUFSをアップグレードしてカーネルを手動でビルドできる場合は、AUFSv20160111以降も使用できます。 |
| Boot2Docker | ：white_check_mark： v1.10.0-rc1にアップグレード|
| Ubuntu 14.04LTS | ：arrow_down：カーネルを3.13.0-71以前にダウングレードする|
| Ubuntu 15.04 | ：arrow_down：カーネルを3.19.0-39以前にダウングレードします（：warning：テストされていません）|
| Ubuntu 15.10 | ：arrow_down：カーネルを4.2.0-18以前にダウングレードする|
| Debian 7/8 | ：arrow_down：カーネルをバージョン3.16.7にダウングレード-リリース3.16.0のckt11（ apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 ）以前|
| Debian 9 | ：white_check_mark :(カーネル3.18-1〜exp1以降はAUFSをサポートしていません）|
| Gentoo | ：white_check_mark：最近のものにアップグレードします（：warning：テストされていません）|
| RHEL / CentOS | ：white_check_mark：（AUFSをサポートしていません）|
| openSUSE | ：white_check_mark：（AUFSをサポートしていません）|

：警告：カーネルのダウングレードはセキュリティリスクになる可能性があります（例：CVE-2016-0728）

ディストリビューターはチケットを発行します

| ディストリビューション| ステータス| 発行URL |
| --- | --- | --- |
| Boot2Docker | ：white_check_mark：クローズ| https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | ：white_medium_square：進行中| https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | ：white_medium_square：進行中| https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

また、この問題も発生しました。mongodは100％CPUで実行されているR状態でスタックしています。

これが私をここに導く正しいスタックトレースを取得するための本当のトリックです：

echo "l"> / proc / sysrq-トリガー

そこから、CPU2がAUFSによって無限ループに陥っていることがわかります

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

do_xino_fwriteで検索すると、ここに移動します。

証明書の設定でハングするDebianStretchでもこの問題が発生しているようです。

エラーメッセージは次のとおりです： https ：
バージョン情報は次のとおりです： https ：
これがdockerfileです： https ：//gist.github.com/8778f8db143478d6c8ab

では、ここでのOSXの解決策は何ですか、Dockerアップデートはすでにありますか？

まだですが、リリース候補があります。 （https://github.com/tianon/boot2docker-legacy/releases/tag/v1.10.0-rc2）

私にとっての解決策は、ストレージバックエンドを変更することでした。

/ etc / default / dockerに行を追加します
¡¡コンテナデータが失われることに注意してください！

DOCKER_OPTS="--storage-driver=devicemapper"

Dockerサービスを停止し、/ var / libのdockerフォルダーを消去してから、行を追加してDockerサービスを再起動することをお勧めします。

@ referup-taranteguiは、実際の物理ディスクに直接マウントしない限り、 devicemapperドライバーのパフォーマンスが著しく低いと見なされます。 見る
https://jpetazzo.github.io/assets/2015-03-03-not-so-deep-dive-into-docker-storage-drivers.html#43 https://jpetazzo.github.io/assets/2015 -03-03-not-so-deep-dive-into-docker-storage-drivers.html＃44
そして
https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/ 「デバイスマッパーとDockerのパフォーマンス」

リリース候補2にはバージョンBがあります

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

Ubuntuに関する表を更新しました。

最新のクイックワークアラウンド（更新：2月3日6:30 UTC）

| ディストリビューション| 回避策|
| --- | --- |
| 一般| devicemapper / overlay / btrfsを使用します（ただし、別の問題が発生する可能性があります）。
AUFSをアップグレードしてカーネルを手動でビルドできる場合は、AUFSv20160111以降も使用できます。 |
| Boot2Docker | ：white_check_mark： v1.10.0-rc3にアップグレード|
| Ubuntu 14.04LTS | ：white_check_mark：カーネルを3.13.0-77.121hf1533043v20160201b1 （PPA）にアップグレードする|
| Ubuntu 15.04 | ：white_check_mark：カーネルを3.19.0-49.55hf1533043v20160201b1 （PPA）にアップグレードする|
| Ubuntu 15.10 | ：white_check_mark：カーネルを4.2.0-27.32hf1533043v20160201b1 （PPA）にアップグレードする|
| Debian 7/8 | ：arrow_down：カーネルをバージョン3.16.7にダウングレード-リリース3.16.0のckt11（ apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 ）以前|
| Debian 9 | ：white_check_mark :(カーネル3.18-1〜exp1以降はAUFSをサポートしていません）|
| Gentoo | ：white_check_mark：最近のものにアップグレードします（：warning：テストされていません）|
| RHEL / CentOS | ：white_check_mark：（AUFSをサポートしていません）|
| openSUSE | ：white_check_mark：（AUFSをサポートしていません）|

ディストリビューターはチケットを発行します

| ディストリビューション| ステータス| 発行URL |
| --- | --- | --- |
| Boot2Docker | ：white_check_mark：クローズ| https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | ：white_medium_square：進行中（ETA：2月20日）| https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | ：white_medium_square：進行中| https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

@ AkihiroSuda 、 boot2dockerのv1.10.0-rc2を意味していると思います。または、リンクがここにあると想定されていたと思います（https://github.com/boot2docker/boot2docker/releases/tag/v1.10.0-rc3）。

@jakirkhamありがとう、リンクを修正しました。

rc3は私のフォークではなく公式リポジトリにあります：
https://github.com/boot2docker/boot2docker/releases/tag/v1.10.0-rc3

フォークの使用を余儀なくされた技術的負債を調査したところ、
docker-machine 0.5以降で修正されていたため、次の段階に進んでいます。
上向き。 ：スマイル：

ところで、UbuntuPPA用にカーネルを上記のchilukパッチバージョンに切り替えようとしている人のために。 たとえば、Ubuntu 14.04、 linux-image-3.13.0-77-generic場合、手順は次のようになります。

$ 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

次に、 /etc/default/grub構成を更新してから、 sudo update-grub実行してから、パッチを適用した新しいカーネルビルドで再起動する必要があります。 これまでにこれを行ったことがない場合は、grubで別のデフォルトカーネルを

この問題はDocker1.10.0には存在しないことを確認できます。これにより、OS X10.11でも状況が修正されました。 それ以外の場合は、1.9.0にダウングレードする予定でした。

Docker1.10でjavaハングしたコンテナ/プロセスの問題が発生します。

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

@AkihiroSudaクイックアラウンドを試していますが（ありがとう！）、Debian 8（jessie）サーバーに古いカーネルをインストールできません。次のようになります。

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

@mikeatlasの提案を試してみると（ sudo add-apt-repository ppa:chiluk/1533043を機能させるにはsudo apt-get install software-properties-common必要でした）更新に失敗します。これがインストールが機能しない理由だと思います

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

私のDocker情報：

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

@jamshid software-properties-commonが必要なことについてのヒントをありがとう、私は上記の投稿を更新しました。

@jamshid ：PPAを追加してapt-get updateを実行した後、マシンで使用できるカーネルを確認してください...新しいビルド（ 3.13.0-78 ）があるようですが、表示されませんここで自分で更新を実行した後に利用できます。 ただし、インストールできるカーネルを_できる_方法は次のとおりです。

$ 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

linux-image-3.13.0-77-generic以上の線に沿って何かが表示されない場合は、他の何かが正しくないはずです。

ああ、 @ jamshidはDebian8を実行していますか？ 上記の注： 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

Debian 8のapt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3は

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

ckt11パッケージを見つけるための1時間のアクティブなグーグルは役に立ちませんでした。
最近のDebian8カーネルをダウングレードする方法について何か提案はありますか？

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以前にインストールされたパッケージは/var/cache/apt/archivesます。 dpkg -i <old_package>.debダウングレードできるはずです。

PPAから新しいカーネルをインストールすると問題が解決することを確認しました（Ubuntu 14.04.3 / Kernel 3.13.0-78-generic / Docker 1.9.1）
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043

誰かがDebian（Ubuntuではなく）で動作するようにダウングレードの指示を受けましたか？ 私のapt-get updateが以下のエラーで失敗する理由（ppaリポジトリを追加した後）かどうか疑問に思っています：

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

https://launchpad.net/~chiluk/+archive/ubuntu/1533043で利用できるのはubuntuパッケージだけ

@jamshid UbuntuppaはDebianをサポートしていません。

3.16.7-ckt11-1 + deb8u3が残念ながら利用できなくなった場合は、最新のカーネルにパッチを適用できます： https ：//bugs.debian.org/cgi-bin/bugreport.cgi？bug = 812207＃47

（誰かがそれを必要とするならば、私はdebパッケージをアップロードすることができます）

誰かがカーネルを必要とする場合、私はそれをここにアップロードしました、それはdeb8u3より少し新しいです、しかしそれはバグを持っているようには見えません、少なくとも私はこれをかなり長い間実行していませんでしたが最新のカーネルがおそらくより良い解決策です。 ただし、必要な場合：
https://wizardtales.com/linux-image-3.16.0-0.bpo.4-amd64_3.16.7-ckt11-1+deb8u6~bpo70+1_amd64.deb

@wzrdtales ：+1：

私のような人がまだこれを分類するのに苦労している人のために、私はあなたに素晴らしい回避策としてTINIを指摘したいと思います：
https://github.com/krallin/tini

dockerfileに数行あるだけで、ゾンビを削除できる適切なinitプロセスが得られました。
これにより、devicemapperへの移行を回避できます。

乾杯、
フランチェスコ

だから、私はティニを使います。 しかし、私が遭遇した問題はイメージの構築中にあったため、ここでは役に立ちませんでした。

また、コンテナを実行するときは、tiniを使用しますが、それでも影響を受けました。

@fflatorre
情報ありがとうございますが、tiniが解決できるゾンビの問題はこの問題とは違うようです。
https://github.com/docker/docker/issues/18180#issuecomment -167042078

実際、tiniを使用しても、ゾンビを取得できます。

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イメージを構築するときにこの問題が発生していないことを忘れてしまいました。 非常に基本的なイメージを作成してから、プロビジョニングロジックを一連のAnsibleスクリプトに委任します。 プロビジョニング中に、プロセスの1つ（kafka）がハングしていました。 これまでのところ、TINIはその問題を軽減したようです。
私はそれがあなたにとって解決策ではないかもしれないことを認めます、確かに私はそれを回避策からプラセボにダウングレードすることを提案します:)
私たちが得ることができることを願っていますがすぐに分類されます。

OSX10.11.3でDocker1.9.1を実行しても同じ問題が発生しました。

$ docker -v
Docker version 1.9.1, build a34a1d5

最新のDockerToolboxリリースへのアップグレードが修正されました。

$ docker -v
Docker version 1.10.1, build 9e83765

詳細については、AUFS / Overlay / BtrFS / ZFS / devicemapperストレージドライバーに関連するいくつかの問題と回避策をリストしました： https ：

これが＃18180などに興味のある人に役立つことを願っています。

@AkihiroSudaリンクhttps://launchpad.net/%7Echiluk/+archive/ubuntu/1533043/+packagesをたどろうとしましたが、ページを表示できません。

参照： https ：

@ schmunk42
また、ページにアクセスできませんでした。
chilukはパッケージを作り直していると思います。 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043で彼に尋ねることができ

これに問題がある人のために、 -proposedカーネルを使用して次のとおりです。 もちろん、カーネルがメインブランチに移行すると、これは関係ありません。

始める前に、実行することで、影響を受けるカーネルで実行していることを確認できます（つまり、Ubuntu 14.04では<3.19.0-50）。

$ uname -r
3.19.0-49-generic

これはわかっているので、最初に次を実行して提案されたパッケージを

$ 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

それが終わったら、更新されたカーネルをインストールしましょう。

$ 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

そして再起動しましょう

$ sudo shutdown -r now

再起動後、最新のカーネルで最新のものが実行されていることを確認できます。

$ uname -r
3.19.0-50-generic

ありがとう@vpeterssonは、このバージョンのカーネルがリリースされたときに何が起こるかを

@IainColledgeはい、そうなると思いますが、完全には

UbuntuとDebianに関する表を更新しました。

最新のクイックワークアラウンド

| ディストリビューション| 回避策|
| --- | --- |
| 一般| devicemapper / overlay / btrfsを使用します（ただし、別の問題が発生する可能性があります）。
AUFSをアップグレードしてカーネルを手動でビルドできる場合は、AUFSv20160111以降も使用できます。 |
| Boot2Docker | ：white_check_mark： v1.10.0以降にアップグレードする|
| Ubuntu 14.04LTS | ：white_check_mark：カーネルを3.13.0-79.123以降にアップグレードする|
| Ubuntu 15.04 | ：white_check_mark：カーネルを3.19.0-51.57以降にアップグレードする|
| Ubuntu 15.10 | ：white_check_mark：カーネルを4.2.0-30.35以降にアップグレードする|
| Debian 7/8 | ：arrow_down：カーネルをバージョン3.16.7にダウングレード-リリース3.16.0以前のckt11（@wzrdtalesによるdpkgアーカイブ）|
| Debian 9 | ：white_check_mark :(カーネル3.18-1〜exp1以降はAUFSをサポートしていません）|
| Gentoo | ：white_check_mark：最近のものにアップグレードします（：warning：テストされていません）|
| RHEL / CentOS | ：white_check_mark：（AUFSをサポートしていません）|
| openSUSE | ：white_check_mark：（AUFSをサポートしていません）|

ディストリビューターはチケットを発行します

| ディストリビューション| ステータス| 発行URL |
| --- | --- | --- |
| Boot2Docker | ：white_check_mark：クローズ| https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | ：white_check_mark：クローズ| https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | ：white_medium_square：進行中| https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

もう一つ; ストレージドライバーに関する既知のバグをいくつかリストアップしました： https ：

誰かが前述のパッチ付きの最新の「linux_3.16.7-ckt20-1 + deb8u3」debianカーネルを手に入れたい場合に備えて、手動でビルドしました。https：//fxposter.org/linux-image-3.16にあります。 .0-4-amd64_3.16.7-ckt20-1 + deb8u3a〜test_amd64.deb。

すごい！ 私はこの問題を数週間抱えていますが、Ubuntuの修正が昨日リリースされたと思います：P

3.19.0-51への最新の14.04LTSカーネルアップデートが私のJavaゾンビに終止符を打つことを確認します。 ありがとう！

Debianはこの問題をサポートしていました。

最新のクイックワークアラウンド

| ディストリビューション| 回避策|
| --- | --- |
| 一般| devicemapper / overlay / btrfsを使用します（ただし、別の問題が発生する可能性があります）。
AUFSをアップグレードしてカーネルを手動でビルドできる場合は、AUFSv20160111以降も使用できます。 |
| Boot2Docker | ：white_check_mark： v1.10.0以降にアップグレードする|
| Ubuntu 14.04LTS | ：white_check_mark：カーネルを3.13.0-79.123以降にアップグレードする|
| Ubuntu 15.04 | ：white_check_mark：カーネルを3.19.0-51.57以降にアップグレードする|
| Ubuntu 15.10 | ：white_check_mark：カーネルを4.2.0-30.35以降にアップグレードする|
| Debian 7 | ：white_check_mark：カーネルを3.2.73-2 + deb7u3（linux-image-3.2.0-4-amd64パッケージの）以降にアップグレードする|
| Debian 8 | ：white_check_mark：カーネルを3.16.7-ckt20-1 + deb8u4（linux-image-3.16.0-4-amd64パッケージの）以降にアップグレードする|
| Debian 9 | ：white_check_mark :(カーネル3.18-1〜exp1以降はAUFSをサポートしていません）|
| Gentoo | ：white_check_mark：最近のものにアップグレードします（：warning：テストされていません）|
| RHEL / CentOS | ：white_check_mark：（AUFSをサポートしていません）|
| openSUSE | ：white_check_mark：（AUFSをサポートしていません）|

ディストリビューターはチケットを発行します

| ディストリビューション| ステータス| 発行URL |
| --- | --- | --- |
| Boot2Docker | ：white_check_mark：クローズ| https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | ：white_check_mark：クローズ| https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | ：white_check_mark：クローズ| https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

14.04LTSのカーネルのアップグレードは私のために働いた：+1：

私はBoot2Dockerバージョン1.10.2、ビルドマスター：611be10、Dockerバージョン1.10.2、ビルドc3959b1のOSXを使用しており、最初にdocker-composeからこれを取得しました：

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

次にdocker kill 38e1e2590dfa試しましたが、プロセスが永久にハングします。 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"

メモと同じように（これが閉じられていることは知っていますが、新しい問題として開くことが理にかなっているかどうかはわかりません）。 devmapperに切り替えるまで、後のバージョンでも同じ問題が発生していました。

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

@einhverfrこの問題はカーネル3.13.0-79.123で修正されています（あなたのものは3.13.0-77のようです）

この問題は、カーネルのアップグレードで本当に解決できますか？ カーネル3.13.0-83-genericを搭載したUbuntu14.04のDocker1.9.1でも同じ問題が発生しています。

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はい、この問題はカーネルの問題でした。 他の何かが同様の動作を引き起こす可能性があるか、カーネルにリグレッションがある場合です。 ただし、現在のリリースで問題が発生している場合は、新しい問題を開いてください。 docker 1.9.1はEOLであるため、更新を受信しなくなることに注意してください。

ここでの元の問題が解決されたため、この問題に関する議論をロックしています。この問題が無関係な問題を収集するのを防ぎたいと思います。 このコメントを参照してください。 この問題を修正するために必要なカーネルバージョンについては、 https： //github.com/docker/docker/issues/18180#issuecomment-193708192を