我正面临着同样的问题。 我正在调查。

我们也面临着同样的问题。

是的，这是docker 1.9中的问题。 我降级到1.8.3，所有问题都解决了。 现在，我正在研究一个工作环境。 将在这里发布！ ks

我在docker 1.9.1a中遇到了同样的问题

我有docker 1.8.3，所以也许安装不同版本的docker的过程可以纠正这种情况。 @bsao。

在Docker 1.9.1版中遇到同样的问题，构建a34a1d5

您仅在boot2docker上看到此消息吗？

我无法使用aufs在我的机器上回购股票ubuntu。 让我尝试使用boot2docker看看我是否可以回购到那里。

使用OSX在Docker 1.9.1中为ubuntu：14.10 +1

这是我打开VPN进行工作后开始出现的问题。 即使在我关闭VPN并在OSX上重新启动docker计算机之后，它仍然存在此问题。 我重新安装了Docker 1.9.1，然后是1.8.3，仍然看到了问题。 阻止我在Mac上使用大多数（如果不是全部）泊坞窗。

使用OS X 10.11在Docker 1.9.1中为ubuntu 12.04 +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>

尝试在OSX 10.11上使用docker 1.9.1进行+1，并尝试从ubuntu 14.04构建映像

+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是我的临时解决方法。 这是我在Makefile使用的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 X 10.10上使用docker 1.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：有效
带有Docker 1.9.1的Ubuntu 14.04：可以工作

boot2docker vms使用以下命令创建：
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/上的文档安装了

+1，在OSX Yosemite 10.10.5上运行docker 1.9.1构建a34a1d5。

我无法重现。

这里同样的问题。
有什么方法可以降级到Windows上的早期版本吗？

我自己找到的。
https://github.com/docker/docker/releases

+1，码头工人1.9.1 @ El Capitan

+1，OS X 10.11.1上的Docker 1.9.1

+ 1，Docker 1.9.1a，OS X 10.10.5

+1，Docker 1.9.1 build a34a1d5，Windows 10

+1，Docker 1.9.1构建a34a1d5，OS X 10.11.1，Docker-Machine 0.5.1构建7e8e38e

+1

在OSX 10.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？ 考虑到它看起来像
进程意外终止。 ：失望

看起来内存不是问题，但是<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，Win 7。

即使stats命令显示了容器可用的内存，我也遇到了类似的问题，结果是OOM。 该问题在任务管理器显示0可用物理内存后很快就发生了，而统计数据继续显示<100％。

奇怪的是，该进程一直在运行，因此没有被杀死。 我可以使用-m重试，但是奇怪的是，这种情况发生在1.9.x上，但是（在讨论之后）却不在1.8上。 同样，在1GB DigitalOcean的Droplet（也为1.9.1）上运行相同的操作成功。 也许使用交换，应该检查一下

在我卸载1.9.1和安装1.8.3之后，它实际上一直在发生。 看起来在Mac上卸载不是很彻底，因为在1.8.3上启动外壳没有延迟，这与正常的第一次运行不同，因为它会设置ssh密钥和内容。

_USER POLL_

_在讨论中发生更改时获得通知的最佳方法是单击右上方的“订阅”按钮。_

以下列出的人感谢您通过随机+1进行有意义的讨论：

@mattes

31位参与者就此问题进行计数。

@ bean5请保持您的建设性意见

@thaJeztah我不是要冒犯也不具有@GordonTheTurtle希望构建一个完成+1的人员的列表。 也许我对他的意思感到困惑。 无论如何，我对这个问题怀有极大的期待，因为在过去的几周中，它多次影响了我。 我很高兴收到来自不同用户的信息。

我可以在设置中重复使用此问题（在Mac上使用Docker Machine）。

到目前为止，这是我的发现。

正如其他张贴者所指出的，复制此内容的最简单方法是将boot2docker 1.9.1 ISO与AUFS一起使用。 这个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作为存储驱动程序的Docker 1.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会很好地构建并且不会挂在带有Docker 1.9.1二进制文件的boot2docker 1.9.0 ISO上。 问题似乎不在于Docker 1.9.1，而是在于运行它的环境。

我正在使用1.9.1发行版，而在aufs上没有任何问题，但是比默认的机器配置要多得多的cpu / ram / storage。

我只是尝试将虚拟机的内存增加到4GB，但仍然能够复制

@ cpcpyy83 boot2docker 1.9.1上的AUFS？

如上所述，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");
    }
}

编译并运行它会导致Java进程失效，带有100％cpu的1个内核：
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
码头工人1.9.1
boot2docker版本1.9.1 uname -a是“ linux ci 4.1.13-boot2docker”
numproc = 1

strace输出与System.exit（0）;

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

strace输出_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，build a34a1d5，OS X 10.10.5，Docker Machine Version：0.5.1（HEAD）

+1

Docker版本1.9.1，内部版本a34a1d5 ，OS X 10.11.1（15B42）

+1

Docker版本1.9.1，在OS X 10.11.1上构建a34a1d5

这个问题确实很奇怪。 如果我strace失败的apt-get命令，则输出的结尾是：

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“ hello world”在没有显式“ System.exit（0）;”的情况下导致了僵尸进程。 -也许那是一个完全不同的问题。 如果是这样的话，抱歉。

您的cpu无限循环时会发生什么？

@andrewgdavis 100％

java“ hello world”导致没有明确的“ System.exit（0）;”的僵尸进程

这肯定听起来类似于这里遇到的问题。

我可以肯定地确认b2d问题（即使是二分法也可以最肯定地跟踪到4.1.13内核颠簸）。 我也可以使用b2d在4.2.6上进行复制。

另外，我的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出现了问题。 我可以确认为前者烘焙boot2docker ISO不会触发此错误，但前者会触发。

因此，它与boot2docker没有特别关系，但似乎与与AUFS交互的内核版本有关。

或Docker中AUFS驱动程序与
较新的内核-TBD，可能在4.1.12之间具有linux稳定的git bisect
和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（结构文件* file，结构iov_iter * i，loff_t pos）

下面是我个人要测试的代码块，因为该注释同时描述了死锁和活锁竞争条件，并且我认为CPU固定为100％。 但这就是我和我的结论结论垫。

4.1.13毫米/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-machine VM的内存从1024 MB增加到2048 MB并分配2个CPU而不是1个，我已经能够自己解决此问题。

作品：

VM：Ubuntu 14.04（2GB内存）
Docker引擎：1.9.1
Docker基本映像： ubuntu：latest

不起作用：

VM：Ubuntu 15.10（2 GB内存）
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

虚拟机：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 X 10.11.1上构建a34a1d5

在OS X 10.9.5上使用docker 1.9.1遇到。

受@marsinvasion的启发，我给了

糟糕，很快就进行了交谈。 在更改我正在处理的Dockerfile并重新运行构建时，它停止工作。

还从以前构建的ubuntu：15.04映像中看到了此可怕的错误（在OS X上为docker-machine boot2docker 1.9.1）。 似乎需要重新启动我的docker服务器，以使那些僵尸容器消失。

我以为https://github.com/docker-library/java/issues/19是相关的，但也许不相关，在这里我们遇到了麻烦，在那里他们遇到了找不到“ java”的错误。

将我的服务器切换为叠加作为一种解决方法。 在此之前，它还创建了一堆僵尸容器。

Docker版本1.9.1，在OS X 10.11.1上构建a34a1d5

谁知道将现有的boot2docker.iso系统迁移到https://docs.docker.com/engine/userguide/storagedriver/overlayfs-driver/涉及什么，或者进行完全重建会更容易吗？ 该页面上有关于CentOS映像构建的不祥警告-什么是“百胜”解决方法，它与https://github.com/docker/docker/issues/10180相关

在1.9.1a中已修复-如果您在OSX上安装此文件-https: //github.com/docker/toolbox/releases/download/v1.9.1a/DockerToolbox-1.9.1a.pkg

绝对不是由Docker Toolbox 1.9.1a修复的。 遇到该版本的错误。 回顾评论，看来我不是唯一的一个。

仍然没有建立

我必须删除virtualbox中的VM并从头开始才能正常工作。

另外，尝试多次删除和创建新VM均无济于事。

安装1.9.1a，执行docker-machine rm default并使用Docker Quickstart Terminal重新生成默认计算机。 重建的图像（从java:7-jre派生）并运行，仍然无法正常工作。 可以继续使用上面建议的构建的覆盖机器正常工作：

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

^谢谢！ 我可以确认套印机正在工作。

使用overlay作为引擎存储驱动程序还可以修复MongoDB关闭挂起。

您可以通过安装Oracle java而非OpenJDK来解决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容器上，boot2docker 1.9.1也会导致僵尸Java进程。
root 322 11.1 0.0 0 0 ? Zsl 18:43 29:48 [java] <defunct>

我无法使用--engine-storage-driver overlay配置我的docker服务器，因为我构建了基于CentOS的映像，并且overlayfs与yum不兼容（https://github.com/ docker / docker / issues / 10180）。

我敢肯定Docker人们会不建议这样做，但是我克服这个阻塞问题的方法是构建一个boot2docker.iso，它使用Docker 1.9.1和一个稍旧的AUFS。 https://github.com/boot2docker/boot2docker/issues/1099#issuecomment -163052066中的说明。

尝试使用Oracle jdk1.7.0_75和jdk1.8.0_65; 都挂起并创建一个已失效的Java进程。

从： 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）的Docker 1.9.1上复制问题

通过安装Docker 1.9.0可以解决它

_抱歉，今天早些时候在我的工作机上出现信息不足-将在以后提供更新信息_

：+1：

与Docker 1.9.1和OS X 10.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补丁进行了怪异的交互（并且幸运的是，已经在AUFS中对其进行了修复临时）。

我决定给它旧的尝试，并克隆了boot2docker存储库。 然后将dockerfile中的aufs提交修改为以前的版本。 因此，1.9.1之前发行的docker 1.9.1内核4.1.13 +先前的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/是当我们获得挂起+已失效+固定CPU时正在执行的确切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映像。 该映像基于Oracle Linux，并使用OpenJDK。

@brunoborges是的，可能是相同的问题，请参见https://github.com/docker/docker/issues/18500#issuecomment -163334612

@brunoborges只需检查您的boot2docker.iso版本-如果它是1.9.1您可以尝试降级到1.9.0并重新创建计算机并再次提取映像。
如果您这样走，您能在这里写一份简短的报告吗？

所以我想知道为什么这只会在Java上发生，而不是在其他任何语言上发生。 在我以前的一篇文章中，我能够通过简单地编译和运行来详细介绍最基本的复制品

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）

所以转到内核领域：重建boot2docker iso之后，弄混了aufs版本和内核版本（没有任何改变），我受够了使用numproc = 1进行编译过程的速度。 所以我将其更改为6。==>请注意，不再有1 cpu（谁现在只有1 cpu？ 突然失败案例

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

开始工作。

显然，接下来要尝试的是将其降低到1 cpu。 ==>失败。 返回已失效的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-机器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可以正常工作，但jdk posthook会永远挂起。 使用1.9.1 boot2docker时只有一个问题。 切换到RancherOS映像，没有问题。 OSX 10.10。

使用El Capitan，Docker 1.9.1和Ubuntu 14.04.1，我得到：设置无限期挂起的ca-certificates-java。

@stremlenye回滚到1.9.0。 仍然挂起。

@brunoborges搬运工1.9.0or boot2docker.iso 1.9.0？

@stremlenye Docker 1.9.0 ...在我的系统中获得boot2docker.iso 1.9.0的说明是什么？

@brunoborges在上面查看此评论：

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

carsten-ulrich-saitow-ag解释了如何使用--virtualbox-boot2docker-url标志使用1.9.0 iso创建新的docker-machine。 那个建议救了我的培根！ 完成此操作后，我可以再次在容器中安装JRE RPM。

@ mobsy74 @stremlenye在boot2docker 1.9.0中尝试过，有时会挂起。

@brunoborges感谢您的尝试。 因此，在解决该错误之前，我将坚持使用1.8.3。

@stremlenye您的意思是boot2docker 1.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

启用多个cpus（在docker计算机中）为我解决了这个问题。

--virtualbox-cpu-count=4

@heiths您能否共享

恕我直言，boot2docker应该从aufs转向其他可用的存储驱动程序之一。 有一个很好的理由说明aufs从未加入Linux内核。

@robvanmieghem每个驱动程序都有其局限性。 Aufs总体上相当稳定，并且overlayfs存在一些阻塞问题（取决于使用情况）

@brunoborges DockerToolbox-1.9.1c-这在Windows和osx上对我有用。

@thaJeztah从未说过overlayfs是完美的解决方案。 我确实认为btrfs是boot2docker的不错选择，boot2docker专用于运行docker容器，除了Linux内核完全支持btrfs之外，查看内容确实非常容易。

关于发行版和文件系统的组合，对此有很多意见：)没有一种解决方案会适合所有用例，因此本着开源和Linux的精神，我认为最好的决定就是提供更好的解决方案。支持多种发行版。 我们已经可以选择Boot2Docker或RancherOS，我相信已经做了一些工作来在debian发行版的基础上重新构建boot2docker。 docker-machine将在云和裸机上支持ubuntu，因此，我确定基于ubuntu的vm iso以及其他构建在alpine或CoreOS之上的vm iso不会很难集成在一起。文件系统的选择-再次，RancherOS现在提供ZFS作为可选安装，而CoreOS默认情况下使用BTRFS，我相信它仍然是一个选择，从3.19版内核开始，Ubuntu支持OverlayFS-任何支持Snappy Core的人b2d图片？ ;）

现在，如果仅能标准化docker-machine参数命名并删除对'boot2docker'的引用以减少混淆-使用boot2docker-url参数安装RancherOS有点不直观；）

@远蓝+1

@heiths +1。 这在OSX 1.9.1c上也为我解决了

将CPU设置为> 1可以避免此问题。 1.9.1c没有帮助。

@heiths @fredriksvensson我事实上我在多个容器环境中随机出现了这个问题，并且我也尝试增加CPU的数量（也有内存，但这不是重点）。 stop <all> / start <all>几个循环表明问题没有消失。 我建议您以相同的方式检查环境，以确保解决方案对您稳定。
/ cc @timechanter

哦，它绝对不会消失。 但是短期内发生挂起的可能性为10％，而挂起的可能性为100％，至少是可以控制的。

@heiths --virtualbox-cpu-count=4也为我工作。

@timechanter +1将CPU设置为> 1已经至少避免了一次该问题； 目前看来是一种有效的解决方法。

OSX 10.10.5

卸载Docker工具箱1.9.1。 降级到Docker工具箱1.9.0为我工作。

El Capitan MacOSX上的同一问题

@heiths --virtualbox-cpu-count=4对我有用。

在Windows 7中使用Docker Toolbox 1.9.1b和1.9.1e为我带来了快乐。

“设置ca-certificates-java（20130815ubuntu1）...”-El Capitan MacOSX。 伙计们，请帮忙！！！ 我无法解决

@ troian88降级到boot2docker.iso 1.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 。

我会进一步研究。

似乎是与inode-> i_mutex有关的死锁。

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

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

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

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



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

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

注意

人们说在多个CPU上运行时可以避免该错误。
但是，我仍然可以使用物理4 CPU盒来解决该错误。 （尽管<1％的概率。）
因此， --virtualbox-cpu-count=2不会_NOT_保证您可以避免该错误。

请注意，CPU的数量仍然很重要。
当我运行taskset 0x1 java时，我可以确定性地解决该错误。（ taskset为该进程分配了特定的CPU）。

@AkihiroSuda非常感谢您对此进行调查。 让我们发布！ ：心：

请注意，在使用Docker 1.8.3的Windows 7上也会发生此问题。

我们在较旧的内核上看到了相同的堆栈堆栈（与上面的AkihiroSuda的评论完全相同）：
Linux 3.19.0-42-generic #48~14.04.1-Ubuntu SMP x86_64和Docker version 1.9.1, build a34a1d5

我可以确认@AkihiroSuda关于多个CPU的断言-我也在具有8个内核的主机上也遇到了这个问题。

AUFS调试看起来真的很有趣-也许值得向AUFS提出问题，看看AUFS维护者是否可以帮助调试？ 如果我们仅使用AUFS（而不是Docker）进行复制，对他们可能会有所帮助，但这并不简单。 ：微笑：

@tianon我在aufs用户上发表了一篇文章： http : //permalink.gmane.org/gmane.linux.file-systems.aufs.user/5335

@AkihiroSuda ，我已经看到这与非Java用例有关。 即尝试关闭派生的MongoDB守护程序。 这在MongoDB启动或常规使用时不会发生，但在关闭时确实会发生。

@jakirkham谢谢，似乎需要特定的线程配置（倾向于出现在Java，MongoDB，也许还有其他东西中）才能触发该错误。

顺便说一句，顺便说一句，也许AUFS挂起是错误的“结果”，而不是错误的“原因”。
我正在研究以下主题： http :
（我没注意到zap_pid_ns_processes()也在两天前也挂起了，因为当时我使用bash作为初始化过程。https://github.com/docker/docker/docker/issues/18180#issuecomment- 166186061）

https://github.com/docker/docker/issues/18180#issuecomment -161843456
@andrewgdavis ，你说的很对！

该错误似乎是由对Linux内核（ mm/filemap.c ）的296291cd提交引起的回归。

我制作了一个Boot2Docker ISO（ boot2docker-v1.9.1-fix1.iso ），它忽略了296291cd： 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会导致安全问题（即，匿名用户的进程耗尽攻击）。

我正在尝试改进296291cd，但是可能要花一些时间。

无论如何，我将此错误报告给了内核bugzilla： https ://bugzilla.kernel.org/show_bug.cgi = 109971

为了方便调试，我还制作了一个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 hm，听起来不错，是的。 非常感谢您对容器和研究进行的研究； 至少有一项非常具体的工作需要完成，希望其他人也能加入进来，以帮助寻找解决方案。 非常感谢您到目前为止所做的出色工作。

我在OS X El Capitan Darwin Kernel版本15.2.0上被击中
Docker版本1.9.1，内部版本d12ea79c9de6d144ce6bc7ccfe41c507cca6fd35
boot2docker 1.9.1

使用以下命令降级到boot2docker 1.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感谢您的提示，这是在安装了Docker 1.9.1的情况下将Ubuntu 14.04内核降级为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

此时，您应该在引导加载期间选择两个内核。 但是，我在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

但是现在看来码头工人没有工作。 因此，完全重新安装需要首先删除：

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

而且，说实话，然后我的下一个尝试在挂在OP标题上的同一容器上运行docker build （“设置ca-certificates-java”），这次_still_死亡并锁定了我的机器，但是现在我没有SSH访问权限，我将回家并等到2016年，然后再看== /

所以...我无法肯定，即使在Ubuntu 14.04 + Docker 1.9.1上遇到此问题后将内核降级到3.13.0-71甚至仍然有效。 uck

是的，为了再次确认，我运行了$ 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.

这是在使用AUFS将Ubuntu 14.04降级到内核版本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上的内核降级确实可以解决此问题吗？

有趣的是，即使我在/var/default/docker中将存储驱动程序显式设置为devicemapper /var/default/docker ：

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

并重新启动docker服务，运行docker info ：

$ docker info
Containers: 1
Images: 16
Server Version: 1.9.1
Storage Driver: devicemapper
 Pool Name: docker-8:1-399761-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 107.4 GB
 Backing Filesystem:
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 2.817 GB
 Data Space Total: 107.4 GB
 Data Space Available: 35.25 GB
 Metadata Space Used: 2.74 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.145 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.77 (2012-10-15)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-71-generic
Operating System: Ubuntu 14.04.3 LTS
CPUs: 1
Total Memory: 490 MiB
Name: myrunner
ID: MLBL:bla:blah

我仍然挂在akihirosuda/test18180:latest测试图片中。

我使用原始二进制文件在Ubuntu 14上将Docker 1.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 。 之后，我将通过二进制安装在启动时重新运行docker 1.8.3服务。 我不知道为什么这些步骤并未真正记录在Docker网站上的二进制安装页面上。 无论如何。

$ 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上生动，Linux 3.19.0-42-generic。 也受影响。

因为我无法使用覆盖（我需要RHEL来宾），所以我在备用驱动器上创建了一个btrfs分区，并将其挂载到/ var / lib / docker（之前停止docker守护程序）。 Docker现在正在愉快地使用btrfs，但是@akihirosuda的图像仍然挂在第二个检查位置（很奇怪）。

@mikeatlas
感谢您测试我的test18180图片。

结果并不奇怪。
第二张支票（ Checking whether sendfile(2) is killable. ）挂在旧内核中。
您需要具有296291cd的较新内核才能通过第二次检查。

| AUFS？ | 内核包括296291cd吗？ | 预期结果
| --- | --- | --- |
| Y | Y | 挂起（第一张支票： Checking whether hitting docker#18180. ）|
| Y | N | 挂起（第二张支票： Checking whether sendfile(2) is killable. ）|
| N | Y | 通过|
| N | N | 挂起（第二张支票： Checking whether sendfile(2) is killable. ）|

@cfstras谢谢，我会调查一下。

@cfstras ，它是可复制的，我打开了＃19073。

@mikeatlas RE： https :

编辑：
早些时候我错了，为什么更改内核版本后docker无法工作，但是我可以确认为内核安装了额外的软件包，然后重新安装docker为我解决了这个问题：

sudo apt-get删除docker-engine
须藤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不是我认为要安装的软件包（但是，我确实如后所述安装了普通的Extras软件包）....但是，我的印象是AUFS模块远比只是相对较新的3.13.0-71内核。 无论如何，降级到Docker 1.8.3也不是一件很痛苦的事情，而且如果我不得不再次经历这一过程，我宁愿在一周的任何一天降级Docker而不是降级linux内核。

@dschep对于其他人，请注意，切换到OverlayFS要求在Linux上使用内核版本3.18 +，并且在Docker页面上引用__与OverlayFS一样很有前景，它仍然相对较年轻。

@mikeatlas我想这是迄今为止对OverlayFS的最大限制：“ _因此，如果不实施变通办法，则在Docker主机上的容器内部使用yum使用覆盖存储驱动程序是不可能的。

@brunoborges yum当前已被修补，可以在overlayfs上使用，因此，不久之后，新版本的yum应该可以在overlayfs上使用（尽管仍然存在一些问题，所以这取决于您的用例/遇到的情况）。他们）。 过度使用inode可能是另一个问题。

我相信我也遇到了这个问题。 呼叫跟踪中提到了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：

真好

Docker Hub上是否使用了错误版本的AUFS？

@tianon “应用更新的AUFS版本”对于非boot2docker用户（每个在Mac OS X上开发docker引擎_not_的用户，主要是b2d生成的用户）意味着他们必须等待Linux内核的更新这个AUFS补丁...或者...考虑到似乎有多少安装/人员受到影响，任何人都可以提供有关如何将AUFS补丁到4.1.13+的简化/最小说明吗？ 阅读4.1.13+的指南绝对是不容易的。 为这个特定的修补程序自己修补linux内核并不完全是出于胆小。

只是这样，我知道如果我构建此boot2docker.iso并将其放入~/.docker/machine/cache并使用docker-machine创建一个新VM，则该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 :

是否会有新版本的boot2docker，因为1.9.1似乎没有修复程序？

编辑。 使用@AkihiroSuda boot2docker image ，我能够继续。 谢谢大家！

是的，此修复程序在1.9.1之后。 @tianon表示已计划发布。 通常，它与docker出去发布的时间相同。 由于他们倾向于遵循2周的发布周期，因此我预计即将发布。 在此期间， @ AkihiroSuda构建了一个可以使用或可以构建自己的修复程序，这确实很简单，只是需要时间。

感谢@AkihiroSuda提供的图片，它可以正常工作！ :)

+1 Debian Wheezy和Ubuntu 15.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

目前，我在Google计算引擎上使用--driver google选项创建的docker-machine主机似乎存在此问题。 谷歌驱动程序没有选择指定其他.iso的选项，因此我无法在谷歌计算中使用上述修复程序。

有人知道解决方法吗？ 或者实际上，如果Google意识到了这个问题，或者我应该在哪里为他们提交错误报告。

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 overlay overlay

似乎也有适用于docker-machine的google驱动程序的“ --google-machine-image”选项。 命令：

$ gcloud计算图像列表

列出可用的公共图像。 我注意到最近有新的ubuntu出现了。

只是为了确认：

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

工作了我还将研究使用固定的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您是一位顽固的bug zapper ！！

@trecloux您正在使用btrfs并挂起sendfile吗？
如果是这样，这是一个已知问题： https :

@AkihiroSuda我正在将v1.10.0-rc1 boot2docker映像与aufs一起使用：

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

这是您的测试图像的输出：

$ 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

运行MacOSX 10.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或更早的版本（：警告：未测试）|
| Ubuntu 15.10 | ：arrow_down：将内核降级到4.2.0-18或更旧版本|
| Debian 7/8 | ：arrow_down：将内核降级到版本3.16.0（ apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 ）或更旧的版本3.16.7-ckt11 |
| Debian 9 | ：white_check_mark：（自内核3.18-1〜exp1起不支持AUFS）|
| Gentoo | ：white_check_mark：升级到最新版本（：警告：未测试）|
| RHEL / CentOS | ：white_check_mark：（不支持AUFS）|
| openSUSE | ：white_check_mark：（不支持AUFS）|

发行票

| 发行版| 现状发行网址|
| --- | --- | --- |
| 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堆栈吗？
另外，您的cmdline和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的风险，CVE-2016-0728具有已知的公共根升级。 我只是对https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207进行了ping操作，但是仅供参考，在您降级之前。

@zmerlynn感谢您指出！

最新快速解决方案（更新：1月26日1:49 UTC）

| 发行版| 解决方法
| --- | --- |
| 一般| 使用devicemapper / overlay / btrfs（但这可能会导致另一个问题。）。
如果可以升级AUFS并手动构建内核，则也可以使用AUFS v20160111或更高版本。 |
| 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或更早的版本（：警告：未测试）|
| Ubuntu 15.10 | ：arrow_down：将内核降级到4.2.0-18或更旧版本|
| Debian 7/8 | ：arrow_down：将内核降级到版本3.16.0（ apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 ）或更旧的版本3.16.7-ckt11 |
| Debian 9 | ：white_check_mark：（自内核3.18-1〜exp1起不支持AUFS）|
| Gentoo | ：white_check_mark：升级到最新版本（：警告：未测试）|
| RHEL / CentOS | ：white_check_mark：（不支持AUFS）|
| openSUSE | ：white_check_mark：（不支持AUFS）|

：警告：降级内核可能会带来安全风险（例如CVE-2016-0728）

发行票

| 发行版| 现状发行网址|
| --- | --- | --- |
| 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状态。

这是获取正确堆栈跟踪的真正诀窍，这将我引到了这里：

回声“ l”> / proc / sysrq-trigger

从那里，您可以看到AUFS将CPU 2卡在了无限循环中

[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搜索将我带到这里！

我似乎在Debian Stretch上也遇到了这个问题，因为它挂在设置证书上。

这是错误消息： 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并手动构建内核，则也可以使用AUFS v20160111或更高版本。 |
| 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.0（ apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 ）或更旧的版本3.16.7-ckt11 |
| Debian 9 | ：white_check_mark：（自内核3.18-1〜exp1起不支持AUFS）|
| Gentoo | ：white_check_mark：升级到最新版本（：警告：未测试）|
| RHEL / CentOS | ：white_check_mark：（不支持AUFS）|
| openSUSE | ：white_check_mark：（不支持AUFS）|

发行票

| 发行版| 现状发行网址|
| --- | --- | --- |
| 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在官方仓库中而不是我的fork上：
https://github.com/boot2docker/boot2docker/releases/tag/v1.10.0-rc3

我们调查了迫使我们使用叉子的技术债务，发现
自docker-machine 0.5起它已修复，因此我们继续前进，
向上。 ：微笑：

btw，适用于那些希望将内核切换到上面为Ubuntu PPA列出的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中设置其他默认内核。

我可以确认此问题在Docker 1.10.0上不存在，这也解决了我在OS X 10.11上的问题。 否则我将降级到1.9.0。

我仍然在docker 1.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 apt-get install software-properties-common才能使sudo add-apt-repository ppa:chiluk/1533043正常工作）时，我收到更新失败，我猜这就是为什么安装不起作用

$ 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 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 ），但我看不到我自己在这里运行更新后可用。 但是，这是您_can_找出可以安装哪些内核的方法：

$ 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，您正在运行Debian 8？ 上面的注释： Downgrade kernel to version 3.16.7-ckt11 of release 3.16.0 (apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3) or older

apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3在Debian 8上给出

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

一个小时的活跃Google搜索无法找到ckt11软件包。
请提供任何有关如何降级最近的Debian 8内核的建议？

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 /内核3.13.0-78-generic / Docker 1.9.1）
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043

有没有人得到降级说明以与Debian（不是Ubuntu）一起使用？ 我想知道我的apt-get update失败的原因并出现以下错误（添加ppa repo后）：

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 Ubuntu ppa不支持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中只有几行，我有一个不错的初始化过程能够删除僵尸。
这样可以避免过渡到devicemapper。

干杯，
弗朗切斯科

因此，我使用Tini。 但是，这对我没有帮助，因为我遇到的问题是在构建映像时。

另外，在运行容器时，我会使用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脚本。 在供应期间，用于挂起的过程之一（kafka）。 到目前为止，TINI似乎已经缓解了该问题。
我承认这可能不是您的解决方案，实际上我建议将其从解决方法降级为安慰剂:)
希望我们能得到尽快解决。

我在OSX 10.11.3上运行Docker 1.9.1时遇到了相同的问题：

$ docker -v
Docker version 1.9.1, build a34a1d5

升级到最新的Docker Toolbox版本已修复：

$ 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上解决问题。 一旦内核毕业进入主分支，这当然就不重要了。

在开始之前，我们可以通过运行来确认我们正在受影响的内核上运行（即，在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并手动构建内核，则也可以使用AUFS v20160111或更高版本。 |
| 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.0或更高版本的3.16.7-ckt11版本（@wzrdtales的dpkg存档）|
| Debian 9 | ：white_check_mark：（自内核3.18-1〜exp1起不支持AUFS）|
| Gentoo | ：white_check_mark：升级到最新版本（：警告：未测试）|
| RHEL / CentOS | ：white_check_mark：（不支持AUFS）|
| openSUSE | ：white_check_mark：（不支持AUFS）|

发行票

| 发行版| 现状发行网址|
| --- | --- | --- |
| 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

确认最新的14.04LTS内核已更新到3.19.0-51，从而结束了我的Java僵尸。 谢谢！

Debian支持此问题。

最新快速解决方案

| 发行版| 解决方法
| --- | --- |
| 一般| 使用devicemapper / overlay / btrfs（但这可能会导致另一个问题。）。
如果可以升级AUFS并手动构建内核，则也可以使用AUFS v20160111或更高版本。 |
| 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：升级到最新版本（：警告：未测试）|
| RHEL / CentOS | ：white_check_mark：（不支持AUFS）|
| openSUSE | ：white_check_mark：（不支持AUFS）|

发行票

| 发行版| 现状发行网址|
| --- | --- | --- |
| 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的OSX上，构建主版本：611be10，Docker版本1.10.2，构建c3959b1并首先从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）

内核升级真的可以解决此问题吗？ 我们在Ubuntu 14.04上使用kernel 3.13.0-83-generic遇到Docker 1.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是的，此问题是内核问题。 可能有其他原因导致类似的行为，或者内核中存在回归。 但是，如果您在当前版本中遇到问题，请打开一个新问题。 请记住，码头工人1.9.1是EOL，因此将不再接收更新。

我将讨论锁定在此问题上，因为此处的原始问题已解决，并且我想防止此问题收集可能无关的问题。 看到这个评论； https://github.com/docker/docker/issues/18180#issuecomment -193708192了解解决此问题所需的内核版本