나는 같은 문제에 직면하고 있습니다. 조사 중입니다.

우리도 같은 문제에 직면 해 있습니다.

네, Docker 1.9에 문제가 있습니다. 1.8.3으로 다운 그레이드했고 모든 문제가 해결되었습니다. 이제 해결 방법을 조사하고 있습니다. 여기에 게시합니다! Tks

도커 1.9.1a와 동일한 문제가 있습니다.

도커 1.8.3이 있으므로 다른 버전의 도커를 설치하는 과정이 상황을 해결할 수 있습니다. @bsao.

도커 버전 1.9.1에서 이와 동일한 문제가 발생하면 a34a1d5 빌드

boot2docker에서만 볼 수 있습니까?

aufs가있는 재고 우분투 또는 내 컴퓨터에서 리포지토리 할 수 ​​없습니다. 내가 거기에 repo를 할 수 있는지 확인하기 위해 boot2docker를 사용해 보겠습니다.

OSX를 사용하는 ubuntu : 14.10 용 Docker 1.9.1의 +1

이것은 업무용 VPN을 켠 후에 나타나기 시작한 문제입니다. VPN을 끄고 OSX에서 도커 머신을 다시 시작한 후에도이 문제가 계속 발생했습니다. Docker 1.9.1을 다시 설치 한 다음 1.8.3을 다시 설치했지만 여전히 문제가 나타납니다. Mac에서 모든 도킹 장치를 사용하지는 않지만 대부분을 사용하지 못하도록 차단합니다.

OS X 10.11을 사용하는 ubuntu 12.04 용 Docker 1.9.1의 +1

제 사무실의 개발자들도이 문제를 우연히 발견했습니다.

이 버전 / 빌드 는 작동했습니다 : Docker 버전 1.9.0, 빌드 76d6bc9

이 버전 / 빌드 중단 : Docker 버전 1.9.1, 빌드 a34a1d5

@crosbymichael 불행히도

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하고 우분투 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에서 docker는 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 빌드 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-machine에서 동일
Docker 버전 1.9.1, 빌드 a34a1d5
docker-machine 버전 0.5.1 (HEAD)

나는 이것을 docker-machine, OS X 10.10.5에서 재현 할 수 있으므로 boot2docker와 관련된 것일 수 있습니다. docker top 는 Java 프로세스에 대해 <defunct> 도 제공합니다.

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, Win 7

stats 명령이 컨테이너에서 사용할 수있는 메모리를 표시하더라도 OOM으로 판명 된 유사한 문제가 발생했습니다. 이 문제는 작업 관리자가 0 개의 사용 가능한 물리적 메모리를 표시 한 직후에 발생했지만 통계는 계속 <100 %를 표시했습니다.

이상한 점은 프로세스가 계속 실행되어 죽지 않았다는 것입니다. -m으로 재 시도 할 수 있지만, 이것이 1.9.x에서 발생하는 것이 이상하지만 (이 논의에 따라) 1.8에서는 발생하지 않습니다. 또한 1GB DigitalOcean 드롭 릿 (1.9.1)에서도 동일하게 실행했습니다. 아마도 그 사람이 스왑을 사용하고 있는지 확인해야합니다.

1.9.1을 제거하고 1.8.3을 설치 한 후에도 실제로 계속 발생했습니다. ssh 키 및 항목을 설정하는 일반적인 첫 번째 실행과 달리 1.8.3에서 셸을 시작하기 때문에 Mac에서는 제거가 매우 철저하지 않은 것처럼 보였습니다.

_USER POLL_

_이 토론에 변경 사항이있을 때 알림을받는 가장 좋은 방법은 오른쪽 상단의 구독 버튼을 클릭하는 것입니다 ._

아래에 나열된 사람들은 무작위 +1로 의미있는 토론에 감사했습니다.

@mattes

31 명의 참가자가이 문제에 참여하고 있습니다.

@ bean5 귀하의 의견을 건설적으로 유지하십시오.

@thaJeztah 저는 기분을 상하게하거나 해체하려는 의도가 없었습니다. 나는 사람들의 GitHub의 쇼 수가 참여한다는 사실에 관심을 끌기 위해 말은 ... 나는 @GordonTheTurtle이 한 일을 한 사람들의 목록을 구성하고 싶다고 모였다. 그가 의미하는 바에 혼란 스러웠을 수도 있습니다. 어쨌든 지난 몇 주 동안 한 번 이상 저에게 영향을 미쳤 기 때문에이 문제를 큰 기대를 가지고보고 있습니다. 다양한 사용자의 정보가있어 기쁩니다.

내 설정에서이 문제를 복제 할 수 있습니다 (Mac에서 Docker Machine 사용).

지금까지 발견 한 내용은 다음과 같습니다.

다른 포스터에서 언급했듯이이를 복제하는 가장 간단한 방법은 AUFS와 함께 boot2docker 1.9.1 ISO를 사용하는 것입니다. 이 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에있는 것이 아니라 실행중인 환경에있는 것 같습니다.

aufs에서 문제가없는 1.9.1 릴리스를 사용하고 있지만 기본 컴퓨터 구성보다 훨씬 더 많은 cpu / ram / storage가 있습니다.

방금 VM의 메모리를 4GB로 늘리려 고했지만 여전히 재현 할 수 있습니다.

@ 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

그러나 ... System.exit(0); 가 println 후에 추가되면 모든 것이 정상입니다.

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

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 출력 _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 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)

(잘못된 파일 설명자) 오류가 계속해서 무한 반복되는 경우.

              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가 실패합니까? 이것은 명시적인 "System.exit (0);"없이 좀비 프로세스를 유발하는 Java "hello world"를 본 이전 게시물과 일치 할 수 있습니다. -아니면 완전히 다른 문제 일 수도 있습니다. 소음에 대해 죄송합니다.

무한 반복하는 동안 CPU는 어떻게됩니까?

@andrewgdavis 100 %입니다

java "hello world"는 명시적인 "System.exit (0);"없이 좀비 프로세스를 유발합니다.

그것은 확실히 여기서 발생한 문제와 유사하게 들립니다.

b2d 문제를 확실히 확인할 수 있습니다 (심지어 4.1.13 커널 범프에 대해 가장 긍정적으로 추적하기 위해 bisect를 수행했습니다). 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에서 뭔가 깨졌습니다. 전자에 대해 boot2docker ISO를 굽는 것이이 버그를 발생시키는 것이 아니라 전자가 발생한다는 것을 확인할 수 있습니다.

따라서 boot2docker와 특별히 관련이 없지만 AUFS와 상호 작용하는 커널 버전과 관련된 것 같습니다.

또는 Docker의 AUFS 드라이버가
최신 커널-TBD, 아마도 4.1.12 사이의 Linux 안정 git bisect 포함
및 4.1.13 : 외침 :

머리에 머리를 쓰는 이론이 있어요 ...

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.13mm / 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의 메모리를 1024MB에서 2048MB로 늘리고 CPU 1 개 대신 2 개를 할당하여이 문제를 직접 해결할 수있었습니다.

공장:

VM : Ubuntu 14.04 (2GB RAM)
Docker 엔진 : 1.9.1
Docker 기본 이미지 : ubuntu : latest

작동하지 않음 :

VM : Ubuntu 15.10 (2GB 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 7 월 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 11 월 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 빌드

Docker 1.9.1이있는 OS X 10.9.5에서 발생했습니다.

@marsinvasion 에서 영감을 받아

죄송합니다. 곧 통화했습니다. 작업중인 Dockerfile을 변경하고 빌드를 다시 실행하면 작동이 중지되었습니다.

또한 이전에 빌드 된 ubuntu : 15.04 이미지에서이 끔찍한 버그 (OS X의 docker-machine boot2docker 1.9.1)를 확인했습니다. 좀비 컨테이너를 없애려면 내 도커 서버를 다시 시작해야하는 것 같습니다.

나는 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 이미지 빌드에 대한 불길한 경고가 있습니다. "yum"해결 방법은 무엇입니까? 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 종료 중단 문제도 해결되었습니다.

OpenJDK 대신 Oracle Java를 설치하여 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

그러나 나는 문제의 범위를 과소 평가하고 있었는데, boot2docker 1.9.1은 openjdk가 잘 설치된 CentOS 컨테이너에서도 좀비 자바 프로세스로 이어집니다.
root 322 11.1 0.0 0 0 ? Zsl 18:43 29:48 [java] <defunct>

CentOS 기반 이미지를 빌드하고 overlayfs 가 yum (https://github.com/)와 호환되지 않기 때문에 --engine-storage-driver overlay 내 Docker 서버를 구성 할 수 없습니다 overlayfs 도커 / 도커 / 문제 / 10180).

나는 Docker 사람들이 이것을 권장하지 않을 것이라고 확신하지만,이 차단 문제를 지나가는 방법은 약간 오래된 AUFS와 함께 docker 1.9.1을 사용하는 boot2docker.iso를 빌드하는 것입니다. https://github.com/boot2docker/boot2docker/issues/1099#issuecomment -163052066의 지침.

오라클 jdk1.7.0_75 및 jdk1.8.0_65를 시도했습니다. 중지하고 없어진 Java 프로세스를 만듭니다.

발신자 : https://github.com/docker/docker/issues/10589
@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 사용)을 테스트했으며 버그가 재현되지 _not_하므로 최신 커널의 일부 변경 사항과 AUFS 패치 간의 이상한 상호 작용에 여전히 있습니다. " 나라. :실망한:

테스트를 거쳐 새로운 4.1.14 커널 에 여전히 버그가 존재하므로 AUFS 패치와 이상하게 상호 작용하는 4.1.13으로 백 포트 된 일부 커밋에 여전히 앉아 있습니다. 임시).

나는 그것에게 오래된 대학 시도를 주기로 결정하고 boot2docker repo를 복제했다; 그런 다음 dockerfile의 aufs 커밋을 이전 버전으로 수정했습니다. 따라서 docker 1.9.1 커널 4.1.13 + 1.9.1 이전에 제공된 이전 AUFS 버전. 내 컴퓨터에서 컴파일이 느립니다 ... git bisect와 함께 실행하여 결과를 집계 할 수있는 도커 떼 설정이 있습니까? 그것은 달콤 할 것입니다.

어쨌든 효과가 있으면 곧 결과를 게시하겠습니다.

최신 정보:
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 11 월 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으로 다운 그레이드하고 컴퓨터를 다시 만들고 이미지를 다시 가져올 수 있습니다.
이쪽으로 가면 여기에 짧은 보고서를 작성할 수 있습니까?

그래서 왜 이것이 다른 언어가 아닌 자바에서만 발생하는지 궁금해했습니다. 이전 게시물 중 하나에서 간단히 컴파일하고 실행하여 가장 기본적인 복제물을 자세히 설명 할 수있었습니다.

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

실패한 자바 프로세스를 초래 한 경우
그리고

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

예상 된 (존재하지 않는) 케이스에 대해.

그런 다음 파이썬을 사용하여 비슷한 것을 재현하려고했습니다. 나는 성공하지 못했지만 시도했습니다. 관심있는 사람들을 위해 좀비 자바 프로세스에서 본 마지막 strace 출력 exit_group(0) = ? 을 표시하려고했습니다. (이 링크는 파이썬 스레딩 / seccomp / etc 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만으로이 자바 프로세스를 성공적으로 실행할 수있었습니다. (제발 내 끔찍한 자바를 놀리지 마세요.)

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를 실행하고 있었고 일어났습니다.)

도커 머신 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 포스트 훅은 영원히 중단됩니다. 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 docker 1.9.0 또는 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로 새 도커 머신을 만드는 방법을 설명합니다. 그 조언이 제 베이컨을 구했습니다! 그렇게하면 컨테이너에 JRE RPM을 다시 설치할 수 있습니다.

@ mobsy74 @stremlenye 는 boot2docker 1.9.0으로 시도했지만 때때로 중단됩니다.

@brunoborges 시도해 주셔서 감사합니다. 따라서이 버그가 수정 될 때까지 1.8.3을 고수 할 것입니다.

@stremlenye 당신은 boot2docker 1.8.3을 의미합니까?

트윗 담아 가기

안녕하세요,
나는 같은 문제가 있었다.
Docker 도구를 1.9.1에서 1.9.0으로 다운 그레이드 할 때 문제가 해결되었습니다.
https://github.com/docker/toolbox/releases/download/v1.9.0/DockerToolbox-1.9.0.pkg

(도커 머신에서) 여러 CPU를 활성화하면이 문제가 해결되었습니다.

--virtualbox-cpu-count=4

@heiths Docker 도구 버전을 공유해 주시겠습니까?

imho, boot2docker는 aufs에서 다른 사용 가능한 스토리지 드라이버 중 하나로 이동해야합니다. aufs가 리눅스 커널에 들어 가지 않은 이유가 있습니다.

@robvanmieghem 각 드라이버에는 한계가 있습니다. Aufs는 전반적으로 매우 안정적이며 overlayfs에는 사용에 따라 일부 차단 문제가 있습니다.

@brunoborges DockerToolbox-1.9.1c-이것은 Windows와 OSX에서 저에게

@thaJeztah 는 overlayfs가 완벽한 솔루션이라고

배포판과 파일 시스템의 조합만큼이나 많은 의견이 있습니다. :) 모든 사용 사례에 완벽한 솔루션은 없습니다. 따라서 오픈 소스와 Linux의 정신에 따라 최선의 결정은 더 나은 서비스를 제공하는 것이라고 생각합니다. 여러 배포판을 지원합니다. 이미 Boot2Docker 또는 RancherOS를 선택할 수 있으며 데비안 배포판 기반에서 boot2docker를 다시 빌드하기위한 작업이 수행되었다고 생각합니다. docker-machine은 클라우드 및 베어 메탈에서 우분투를 지원하므로 우분투 기반 vm iso는 알파인 또는 CoreOS 등에 구축 된 것과 같은 다른 것만 큼 함께 던지기가 어렵지 않을 것이라고 확신합니다. 그런 다음 각각에 대해 파일 시스템의 선택-다시, RancherOS는 이제 ZFS를 선택적 설치로 제공하는 반면 CoreOS는 기본적으로 BTRFS를 사용하는 데 사용되었으며 여전히 옵션이라고 생각하며 커널 3.19부터 Ubuntu는 즉시 OverlayFS를 지원합니다-Snappy Core 기반의 모든 사용자 b2d 이미지? ;)

이제 docker-machine 매개 변수 이름 지정을 표준화하고 'boot2docker'에 대한 참조를 제거하여 혼동을 줄일 수 있다면-boot2docker-url 매개 변수를 사용하여 RancherOS를 설치하는 것은 다소 직관적이지 않습니다.)

@ 파란색 +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 +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가있는 도커 머신을 사용합니다.

Docker 1.9.1에서 --virtualbox-cpu-count=2 가 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

여러 CPU에 대한 @AkihiroSuda 의 주장을 확인할 수 있습니다. 8 코어가있는 호스트

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 및 기타에 나타나는 경향이 있음)이 버그를 트리거하는 데 필요한 것 같습니다.

BTW, 다시 생각하면 AUFS 중단은 버그의 "원인"이 아니라 버그의 "결과"일 수 있습니다.
이 주제를 살펴보고 있습니다 : http://www.serverphorums.com/read.php?12 , 673905
(그 당시에는 bash를 init 프로세스로 사용했기 때문에 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를 생략하는 Boot2Docker ISO ( boot2docker-v1.9.1-fix1.iso )를 만들었습니다. https://github.com/AkihiroSuda/boot2docker/releases/tag/v1.9.1-fix1

모두에게 효과가 있기를 바랍니다. : 스마일 :

커밋 296291cd는 mm/filemap.c:generic_perform_write 에서 fs/aufs/xino.c:do_xino_fwrite() 허용 할 수없는 무한 -EINTR 루프를 생성합니다.

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() 에서 반환 할 수 없습니다.
그것이 우리가 버그에 부딪히는 이유입니다.

뿡뿡
Canonical이 원래 커밋 296291cd를 커널 3.19 트리로 백 포트했기 때문에 버그가 발생했습니다. http://kernel.ubuntu.com/git/ubuntu/ubuntu-vivid.git/commit/?id=6b08592b8acc677d5b9bb7986343fdd6e0ad3303

@AkihiroSuda 와우, 찾아 주셔서 감사합니다! 다음 단계는 무엇입니까? 해당 패치를 되돌려 야합니까? 아니면 패치를 개선 할 방법이 있습니까? 커널 업스트림에 패치를 보내는 것을 고려하고 있습니까?

@AkihiroSuda , 수정은 매력처럼 작동합니다. 감사!

뿡 빵뀨

쉬운 질문이 아닙니다.
커밋 296291cd가 없으면 sendfile(2) 는 죽일 수 없습니다.
이처럼 죽을 수없는 sendfile 가 일부 특정 환경에서 보안 문제 (즉, 익명 사용자의 프로세스 소모 공격)를 유발할 수 있다고 우려합니다.

커밋 296291cd를 개선하려고하는데 시간이 좀 걸릴 수 있습니다.

어쨌든이 버그를 커널 버그질라에보고했습니다 : https://bugzilla.kernel.org/show_bug.cgi?id=109971

또한 디버깅을 쉽게하기 위해 Docker 컨테이너 akihirosuda/test18180 도 만들었습니다. https://github.com/AkihiroSuda/test18180/tree/v0.0.1

$ docker run -it --rm akihirosuda/test18180
[INFO] Checking whether hitting docker#18180.
<-- hangs up here with commit 296291cd
[INFO] OK. not hitting docker#18180.
[INFO] Checking whether sendfile(2) is killable.
[INFO] If the container hangs up here, you are still facing the bug that linux<strong i="18">@296291cd</strong> tried to fix.
<-- hangs up here without commit 296291cd
[INFO] OK. sendfile(2) is killable.
<-- No kernel can reach here

@AkihiroSuda hm, 좋아, 문제처럼 들립니다. repro-container와 연구에 감사드립니다. 적어도 작업해야 할 매우 구체적인 작업이 있습니다. 다른 사람들이 참여하여 해결책을 찾는 데 도움을 주길 바랍니다. 지금까지 훌륭한 작업을 해주셔서 감사합니다.

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

뿡 빵뀨
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 를 실행하려는 다음 시도 ( "Setting up ca-certificates-java"), _still_ 죽었고 이번에는 내 컴퓨터를 잠갔습니다. ,하지만 이제 SSH 액세스 권한이 없으므로 집에 가서 2016 년까지 기다렸다가 다른 사람이 그때까지 더 나은 해결책을 가지고 있는지 확인하려고합니다 = /

그래서 ... 우분투 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.

Ubuntu 14.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 테스트 이미지에 매달려 있습니다.

원시 바이너리를 사용하여 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 스크립트를 가져와 /etc/init.d check_init() 본문을 주석 처리 한 다음 echo '' 로 바꾸고 /etc/init.d 드롭했습니다. 그런 다음 ln -s /etc/init.d/docker /etc/rc2.d/S99docker 로 부팅 시작시 루트로 실행되도록 설정하고 sudo reboot . 그 후 바이너리 설치에서 부팅 할 때 도커 1.8.3 서비스를 다시 실행합니다. 도커 웹 사이트의 바이너리 설치 페이지에 이러한 단계가 실제로 문서화되지 않은 이유를 모르겠습니다. 어쨌든.

$ 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, Linux 3.19.0-42-generic에 있습니다. 또한 영향을받습니다.

오버레이를 사용할 수 없기 때문에 (RHEL 게스트가 필요합니다) 예비 드라이브에 btrfs 파티션을 만들고 / var / lib / docker에 마운트했습니다 (이전에 docker 데몬 중지). Docker는 이제 btrfs를 즐겁게 사용하고 있지만 @akihirosuda 의 이미지는 여전히 두 번째 검사에서 중단됩니다 (이상한).

뿡 빵뀨
test18180 이미지를 테스트 해 주셔서 감사합니다.

결과는 이상하지 않습니다.
두 번째 검사 ( Checking whether sendfile(2) is killable. )는 이전 커널에서 중단됩니다.
두 번째 검사를 통과하려면 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://github.com/docker/docker/issues/18180#issuecomment -168111226

편집하다:
이전에는 커널 버전을 변경 한 후 docker가 작동하지 않는 이유에 대해 잘못 알고 있었지만 커널에 대한 추가 패키지를 설치 한 다음 docker를 다시 설치하면이 문제가 해결되었습니다.

sudo apt-get 도커 엔진 제거
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 OverlayFS로 전환하려면 Linux에서 커널 버전 3.18 +가 필요하며 Docker의 페이지에 인용 된 대로 _OverlayFS가 유망한 것처럼 아직 비교적 젊습니다.

@mikeatlas 이것이 지금까지 OverlayFS에서 가장 큰 제한이라고 생각합니다. "_ 따라서 오버레이 스토리지 드라이버를 사용하는 Docker 호스트의 컨테이너 내부에서 yum을 사용하는 것은 해결 방법을 구현하지 않고는 작동하지 않을 것입니다 ._".

@brunoborges yum은 현재

이 문제도 발생하고 있다고 생각합니다. 통화 추적은 의류를 언급하지만 의류를 비활성화해도 차이가 없습니다. 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

추신 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가 아닌 사용자 (주로 b2d가 빌드 된 Mac OS X에서 개발중인 docker 엔진 _not_를 실행하는 모든 사람)를 위해 Linux 커널 업데이트를 기다려야 함을 의미합니다. 이 AUFS 패치 ... 아니면 ... 얼마나 많은 설치 / 사람이 영향을 받는지 고려할 때, AUFS를 4.1.13+로 패치하는 방법에 대한 간단한 / 최소한의 지침을 누구든지 제공 할 수 있습니까? 4.1.13+에 대한 가이드 는 확실히 읽기에 사소하지 않습니다. 이 특정 수정을 위해 리눅스 커널을 직접 패치하는 것은 마음이 약한 사람을위한 것이 아닙니다.

이 boot2docker.iso 빌드하고 ~/.docker/machine/cache 로 새 VM을 만드는 경우 해당 VM이 boot2docker 의 새 복사본을 사용하게되는지 이해합니다 docker-machine .

이 boot2docker.iso를 빌드하고 ~ / .docker / machine / cache에 넣고 VM이이 boot2docker의 새 사본을 사용할 docker-machine으로 새 VM을 만드는 경우 이해합니다.

기술적으로 예, 작동하지만 더 나은 옵션은 --virtualbox-boot2docker-url . 예 :

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

아, 설명 해주셔서 감사합니다. 글쎄, 이것은 작동하는 것 같습니다.

AUFS를 Canonical로 업데이트하는 요청을 보냈습니다. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043

1.9.1 에 수정 사항이없는 것처럼 보이는 boot2docker의 새 릴리스가 있습니까?

편집하다. @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 호스트 가상 상자를 만들 수있었습니다.

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

현재 --driver google 옵션을 사용하여 Google 컴퓨팅 엔진에서 만든 docker-machine 호스트에이 문제가있는 것 같습니다. Google 드라이버에는 다른 .iso를 지정하는 옵션이 없으므로 위의 수정 사항을 Google 컴퓨팅에서 사용할 수 없습니다.

누구든지 해결 방법을 알고 있습니까? 또는 실제로 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 오버레이 오버레이

docker-machine 용 Google 드라이버에 사용할 수있는 "--google-machine-image"옵션도있는 것으로 보입니다. 명령 :

$ gcloud compute 이미지 목록

사용 가능한 공개 이미지를 나열합니다. 나는 최근에 새로운 우분투 wily가 올라 왔다는 것을 알았습니다.

확인하기 위해 :

$ 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 진지하게 인상적인 작품입니다.

@trecloux btrfs를 사용하고 sendfile에 대해 중단됩니까?
그렇다면 알려진 문제입니다 : https://github.com/docker/docker/issues/19073

@AkihiroSuda 저는 aufs와 함께 v1.10.0-rc1 boot2docker 이미지를 사용하고 있습니다.

$ 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 이상으로 다운 그레이드 |
| 데비안 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로 다운 그레이드 |
| 데비안 9 | : white_check_mark : (커널 3.18-1 ~ exp1 이후 AUFS를 지원하지 않음) |
| 젠투 | : 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 |
| 데비안 | 아직 확인되지 않음 | 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

뿡 빵뀨
https://github.com/docker/docker/issues/18180#issuecomment -166186061에서와 같이 LWP 스택을 얻을 수 있습니까?
또한 cmdline과 phantomjs의 버전은 무엇입니까?

물론입니다. phantomjs 버전 : 1.9

cmdline

$builddir/node_modules/phantomjs/lib/phantom/bin/phantomjs $builddir/node_modules/testem/assets/phantom.js http://localhost:7357/3891

:~# cat /proc/21996/stack # bash
[<ffffffff8106fee9>] do_wait+0x1e9/0x260
[<ffffffff81071042>] SyS_wait4+0xa2/0x110
[<ffffffff8106ecd0>] child_wait_callback+0x0/0x70
[<ffffffff810f945a>] zap_pid_ns_processes+0xfa/0x190
[<ffffffff81070b26>] do_exit+0x8e6/0xa80
[<ffffffff81070d46>] do_group_exit+0x46/0xb0
[<ffffffff81070dc7>] SyS_exit_group+0x17/0x20
[<ffffffff8154e50d>] system_call_fast_compare_end+0x10/0x15
[<ffffffffffffffff>] 0xffffffffffffffff

:~# cat /proc/23810/stack #phantomjs
[<ffffffff81070935>] do_exit+0x6f5/0xa80
[<ffffffff81070d46>] do_group_exit+0x46/0xb0
[<ffffffff8107ffd3>] get_signal_to_deliver+0x233/0x610
[<ffffffff81014507>] do_signal+0x67/0xad0
[<ffffffff811bcf38>] new_sync_read+0x78/0xb0
[<ffffffff8101e045>] read_tsc+0x5/0x20
[<ffffffff810d2442>] ktime_get_ts+0x42/0xd0
[<ffffffff811d091e>] poll_select_copy_remaining+0xfe/0x150
[<ffffffff8101501b>] do_notify_resume+0xab/0xc0
[<ffffffff8154e7ca>] int_signal+0x12/0x17
[<ffffffffffffffff>] 0xffffffffffffffff

또한 작업 스택 :

:~# 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 데비안에서 Docker (Boot2Docker 아님) v1.10.0-rc1을 사용하고 있습니까?
문제는 Docker가 아닌 커널 버그이기 때문에 작동하지 않습니다.

데비안 커널을 조사 중이며 https://github.com/docker/docker/issues/18180#issuecomment -173436661 목록을 업데이트하겠습니다.

@AkihiroSuda y, 그것은 데비안에 직접 있습니다. 나는 당신의 목록에서 데비안 포인트를 감독했습니다. 지적 해 주셔서 감사합니다 :)

데비안의 경우 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을 핑했지만 다운 그레이드하기 전에 참고

@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 이상으로 다운 그레이드 |
| 데비안 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로 다운 그레이드 |
| 데비안 9 | : white_check_mark : (커널 3.18-1 ~ exp1 이후 AUFS를 지원하지 않음) |
| 젠투 | : white_check_mark : 최신 버전으로 업그레이드 (: warning : 테스트되지 않음) |
| RHEL / CentOS | : white_check_mark : (AUFS를 지원하지 않음) |
| openSUSE | : white_check_mark : (AUFS를 지원하지 않음) |

: warning : 커널 다운 그레이드는 보안 위험이 될 수 있습니다 (예 : 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 |
| 데비안 | : white_medium_square : 진행 중 | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

우리는 또한이 문제를 만났습니다. mongod는 100 % CPU로 실행되는 R 상태에 갇혀 있습니다.

여기에 나를 이끄는 올바른 스택 추적을 얻는 실제 트릭이 있습니다.

echo "l"> / proc / sysrq-trigger

거기에서 CPU 2가 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로 검색하면 바로 여기로 안내합니다!

Debian Stretch에서도 인증서를 설정하는 데이 문제가 발생하는 것 같습니다.

오류 메시지는 다음과 같습니다. https://gist.github.com/clball/738feb46094802a1bcf7
버전 정보 : https://gist.github.com/clball/494fe8598dd0cdfd6d10
다음은 dockerfile입니다. https://gist.github.com/8778f8db143478d6c8ab

그렇다면 여기서 OSX의 솔루션은 무엇입니까? 이미 도커 업데이트가 있습니까?

아직은 아니지만 출시 후보가 있습니다. (https://github.com/tianon/boot2docker-legacy/releases/tag/v1.10.0-rc2)

나를위한 해결책은 스토리지 백엔드를 변경하는 것이 었습니다.

/ etc / default / docker에 줄 추가
¡ ¡ 컨테이너 데이터를 잃을 수 있으니주의하십시오 !!

DOCKER_OPTS="--storage-driver=devicemapper"

도커 서비스를 중지하고 / var / lib에서 도커 폴더를 지운 다음 줄을 추가하고 도커 서비스를 다시 시작하는 것이 좋습니다.

@ 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)로 업그레이드 |
| 데비안 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로 다운 그레이드 |
| 데비안 9 | : white_check_mark : (커널 3.18-1 ~ exp1 이후 AUFS를 지원하지 않음) |
| 젠투 | : 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 : 진행 중 (예 : 2 월 20 일) | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| 데비안 | : white_medium_square : 진행 중 | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

@AkihiroSuda , v1.10.0-rc2 를 의미

@jakirkham 감사합니다, 링크를 수정했습니다.

rc3는 내 포크 대신 공식 저장소에 있습니다.
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으로 다운 그레이드하려고했습니다.

도커 1.10에서 java 중단 된 컨테이너 / 프로세스 문제가 여전히 발생합니다.

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

@AkihiroSuda 빠른 해결 방법을 시도하고 있지만 (감사합니다!) 데비안 8 (jessie) 서버에 이전 커널을 설치할 수 없습니다.

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

내가 @mikeatlas을 시도 할 때 제안 (BTW로했다 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 데비안 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

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 패키지를 찾기위한 한 시간 동안의 활발한 검색이 도움이되지 않았습니다.
최신 데비안 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 / 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 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 에서 우분투 패키지 만 사용할 수

@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 :

저와 같은 사람들은 여전히 ​​이것을 분류하기 위해 고군분투하고 있습니다.
https://github.com/krallin/tini

dockerfile에 몇 줄만 있으면 좀비를 제거 할 수있는 적절한 초기화 프로세스가 있습니다.
이렇게하면 devicemapper 로의 전환을 피할 수 있습니다.

건배,
프란체스코

그래서 저는 tini를 ​​사용합니다. 그러나 이미지를 빌드하는 동안 발생한 문제이므로 여기에서는 도움이되지 않았습니다.

또한 컨테이너를 실행할 때 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://github.com/AkihiroSuda/docker-issues/

이것이 # 18180 등에 관심이있는 사람들을 도울 수 있기를 바랍니다.

@AkihiroSuda https://launchpad.net/%7Echiluk/+archive/ubuntu/1533043/+packages 링크를 따라 가려고했지만 페이지를 볼 수 없습니다.

참조 : https://github.com/docker/toolbox/issues/318#issuecomment -184143546

뿡뿡
또한 페이지에 액세스 할 수 없습니다.
나는 chiluk이 패키지를 다시 만들고 있다고 생각합니다. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 에서 그에게 요청할 수 있습니다.

이에 문제가있는 사람들을 위해 제안 된 커널을 사용하여 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 이상으로 업그레이드 |
| 데비안 7/8 | : arrow_down : 커널을 릴리스 3.16.0 이하의 3.16.7-ckt11 버전으로 다운 그레이드합니다 (@wzrdtales의 dpkg 아카이브 ) |
| 데비안 9 | : white_check_mark : (커널 3.18-1 ~ exp1 이후 AUFS를 지원하지 않음) |
| 젠투 | : 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 |
| 데비안 | : white_medium_square : 진행 중 | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

하나 더; 스토리지 드라이버에 대한 몇 가지 알려진 버그를 나열했습니다. https://github.com/AkihiroSuda/docker-issues

누군가가 앞서 언급 한 패치가있는 최신 "linux_3.16.7-ckt20-1 + deb8u3"데비안 커널을 갖고 싶은 경우를 대비하여-수동으로 빌드했으며 https://fxposter.org/linux-image-3.16에 있습니다. .0-4-amd64_3.16.7-ckt20-1 + deb8u3a ~ test_amd64.deb.

놀랄 만한! 나는이 문제를 몇 주 동안 겪어 왔으며 우분투에 대한 수정 사항이 어제 출시되었다고 생각합니다.

3.19.0-51에 대한 최신 14.04LTS 커널 업데이트를 확인하면 Java 좀비가 끝납니다. 감사!

데비안이이 문제를 지원했습니다.

최신 빠른 해결 방법

| 배포판 | 해결 방법 |
| --- | --- |
| 일반 | 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 이상으로 업그레이드 |
| 데비안 7 | : white_check_mark : 커널을 3.2.73-2 + deb7u3 (linux-image-3.2.0-4-amd64 패키지) 이상으로 업그레이드 |
| 데비안 8 | : white_check_mark : 커널을 3.16.7-ckt20-1 + deb8u4 (linux-image-3.16.0-4-amd64 패키지) 이상으로 업그레이드 |
| 데비안 9 | : white_check_mark : (커널 3.18-1 ~ exp1 이후 AUFS를 지원하지 않음) |
| 젠투 | : 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 |
| 데비안 | : 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 인 것 같습니다).

커널 업그레이드로이 문제를 실제로 해결할 수 있습니까? Kernel 3.13.0-83-generic을 사용하는 Ubuntu 14.04의 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 예,이 문제는 커널 문제였습니다. 다른 것이 비슷한 동작을 초래하거나 커널에 회귀가있을 수 있습니다. 그러나 현재 릴리스에 문제가있는 경우 새 문제를여십시오. docker 1.9.1은 EOL이므로 더 이상 업데이트를 수신하지 않습니다.

여기서 원래 문제가 해결 되었기 때문에이 문제에 대한 토론을 잠그고 있으며이 문제가 관련없는 문제를 수집하지 않도록 방지하고 싶습니다. 이 주석을 참조하십시오. 이 문제를 해결하는 데 필요한 커널 버전의 경우 https://github.com/docker/docker/issues/18180#issuecomment -193708192