Saya menghadapi masalah yang sama. Saya sedang menyelidiki.

Kami juga menghadapi masalah yang sama.

Ya, ini masalah em buruh pelabuhan 1.9. Saya telah menurunkan versi ke 1.8.3 dan semua masalah terpecahkan. Sekarang saya sedang menyelidiki workarround. akan posting di sini! Tks

Saya mengalami masalah yang sama dengan buruh pelabuhan 1.9.1a

Saya memiliki buruh pelabuhan 1.8.3, jadi mungkin proses memasang versi buruh pelabuhan yang berbeda memperbaiki situasinya. @bo.

mengalami masalah yang sama dengan buruh pelabuhan versi 1.9.1, buat a34a1d5

Apakah Anda hanya melihat ini di boot2docker?

Saya tidak dapat melakukan repo pada stock ubuntu dengan aufs atau pada mesin saya. biarkan saya mencoba dengan boot2docker untuk melihat apakah saya dapat melakukan repo di sana.

+1 di Docker 1.9.1 untuk ubuntu: 14.10 menggunakan OSX

Ini adalah masalah yang mulai muncul setelah saya mengaktifkan VPN untuk bekerja. Bahkan setelah saya mematikan VPN dan memulai ulang mesin buruh pelabuhan di OSX, masalah ini terus berlanjut. Saya menginstal ulang Docker 1.9.1 dan kemudian 1.8.3, masih melihat masalah. Memblokir saya dari menggunakan sebagian besar, jika tidak semua buruh pelabuhan saya di Mac.

+1 di Docker 1.9.1 untuk ubuntu 12.04 menggunakan OS X 10.11

Pengembang di kantor saya menemukan ini secara tidak sengaja juga.

Versi / build ini berfungsi : Docker versi 1.9.0, build 76d6bc9

Versi / build ini digantung : Docker versi 1.9.1, build a34a1d5

@crosbymichael sayangnya saya belum mencobanya di lingkungan lain selain Boot2Docker.

Seseorang dengan pengetahuan tentang git-bisecting dan buruh pelabuhan dapat menggunakan ID build yang disediakan oleh @ chico1198!

Saya mengalami masalah yang sama dengan 1.9.1 di OSX El Capitan, menurunkan versi ke 1.9.0 tidak membantu.

Masalah yang sama di sini di OSX 10.9.3 dengan:
Docker versi 1.9.1, build a34a1d5
Docker versi 1.9.0, build 76d6bc9

@crosbymichael Saya masuk ke boot2docker dan menjalankan ps auxf , inilah yang saya lihat:

root      1290  0.4  1.8 1346656 75692 ?       Sl   Nov27   4:53 /usr/local/bin/docker daemon -D -g /var/lib/docker -H unix:// -H tcp://0.0.0.0:2376 [...]
root      8556  0.0  0.0      0     0 ?        Ss   05:12   0:00  \_ [sh]
root     24221 99.8  0.0      0     0 ?        Zl   05:33  64:17  |   \_ [java] <defunct>
root     24657  0.0  0.0      0     0 ?        Ss   06:07   0:00  \_ [sh]
root      6174 79.6  0.0      0     0 ?        Zl   06:22  12:33      \_ [java] <defunct>
root      7295 49.3  0.0      0     0 ?        Zl   06:32   2:49      \_ [java] <defunct>

+1 dengan buruh pelabuhan 1.9.1 di OSX 10.11 dengan mencoba membangun gambar dari ubuntu 14.04

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

Mendowngrade ke Docker 1.8.3 adalah solusi sementara saya. Ini target saya gunakan di 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) 

Saya tidak bisa mereproduksi ini. Apakah selalu tergantung pada "menyiapkan sertifikat"? Apakah Anda mencoba mengirim ^D untuk menutup beberapa pipa? Dapatkah Anda juga mencoba mengirim SIGUSR1 ke daemon dan menempelkan jejak tumpukan di sini saat macet?

+1 dengan buruh pelabuhan 1.9.1 di OS X 10.10

Saya mencoba menurunkan ke 1.8.3 menggunakan Makefile @osterman dan juga mengalami masalah dengan kunci 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

Mengujinya dengan melakukan penginstalan openjdk yang berbeda di dalam debian: jessie dan ubuntu
OSX 10.11.1, boot2docker 1.9.1: hang
OSX 10.11.1, boot2docker 1.9.0: berfungsi
Ubuntu 14.04 dengan docker 1.9.1: berfungsi

VMS boot2docker dibuat dengan:
docker-machine buat -d virtualbox --virtualbox-boot2docker-url = https://github.com/boot2docker/boot2docker/releases/download/v1.9.0/boot2docker.iso
dan
docker-machine buat -d virtualbox --virtualbox-boot2docker-url = https://github.com/boot2docker/boot2docker/releases/download/v1.9.1/boot2docker.iso

Pada Ubuntu 14.04, buruh pelabuhan diinstal mengikuti dokumentasi di https://docs.docker.com/engine/installation/ubuntulinux/

+1, menjalankan buruh pelabuhan 1.9.1 membangun a34a1d5 di OSX Yosemite 10.10.5.

Saya tidak bisa mereproduksi ini.

Masalah yang sama di sini.
Apakah ada cara untuk menurunkan versi ke versi sebelumnya di Windows?

Menemukannya sendiri.
https://github.com/docker/docker/releases

+1, buruh pelabuhan 1.9.1 @ El Capitan

+1, Docker 1.9.1 di OS X 10.11.1

+1, Docker 1.9.1a, OS X 10.10.5

+1, Docker 1.9.1 membangun a34a1d5, Windows 10

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

+1

Sama pada mesin Docker pada OSX 10.11.1
Docker versi 1.9.1, build a34a1d5
docker-machine versi 0.5.1 (HEAD)

Saya dapat mereproduksi ini pada mesin galangan, OS X 10.10.5, jadi ini mungkin sesuatu yang berhubungan dengan boot2docker. docker top juga memberi saya <defunct> untuk proses java;

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

/ cc @tianon @nathanleclaire @jeffdm mungkin ada di antara kalian yang punya ide ke mana harus mencari, atau apa yang harus di-debug, saya tidak bisa menemukan sesuatu

Berapa banyak RAM yang dimiliki VM Anda? Bisa jadi OOM mengingat tampilannya seperti
proses mati mendadak. :kecewa:

Sepertinya memori bukanlah masalahnya, namun proses <defunct> memakan 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

Wadahnya sepertinya macet juga, dan saya harus mem-boot ulang vm untuk mematikannya

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

Saya mengalami masalah serupa yang ternyata OOM, meskipun perintah statistik menunjukkan memori yang tersedia untuk penampung. Masalah terjadi segera setelah pengelola tugas menunjukkan 0 memori fisik kosong, sementara statistik terus menunjukkan <100%.

Anehnya, prosesnya terus berjalan, jadi tidak mati. Saya dapat mencoba lagi dengan -m, namun anehnya hal ini terjadi pada 1.9.x, tetapi (setelah diskusi ini) tidak di 1.8. Juga, menjalankan hal yang sama pada tetesan DigitalOcean 1GB (juga 1.9.1) berhasil. Mungkin yang satu menggunakan swap, harus memeriksanya

Itu benar-benar terus terjadi pada saya setelah saya menghapus 1.9.1 dan menginstal 1.8.3. Sepertinya pencopotan pemasangan tidak terlalu menyeluruh pada Mac karena menjalankan shell tanpa penundaan di 1.8.3, tidak seperti proses normal pertama yang mengatur kunci ssh dan lainnya.

_USER POLL_

_Cara terbaik untuk mendapatkan notifikasi ketika ada perubahan dalam diskusi ini adalah dengan mengklik tombol Subscribe di kanan atas._

Orang-orang yang tercantum di bawah menghargai diskusi Anda yang bermakna dengan +1 secara acak:

@tokopedia

31 peserta tentang masalah ini dan terus bertambah.

@ bean5 tolong beri komentar yang membangun

@ thaJeztah Saya tidak bermaksud menyinggung atau dekonstruktif. Saya bermaksud untuk menarik perhatian pada fakta bahwa github menunjukkan jumlah orang yang berpartisipasi ... dan saya menyimpulkan bahwa

Saya dapat menduplikasi masalah ini di pengaturan saya (menggunakan Mesin Docker di Mac).

Inilah temuan saya sejauh ini.

Seperti dicatat oleh poster lain, cara termudah untuk menduplikasi ini adalah dengan menggunakan boot2docker 1.9.1 ISO dengan AUFS. Dockerfile semestinya mereproduksi masalah dengan cukup cepat:

FROM debian:jessie

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

Melihat dmesg , saya melihat beberapa kesalahan AUFS setelah mencoba membangun seperti itu, tetapi saya tidak 100% yakin mereka terkait:

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

Jika saya membuat mesin Docker 1.9.1 yang menggunakan overlay sebagai driver penyimpanan:

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

Prosesnya TIDAK hang dan baris ini berjalan dengan sukses! Sepertinya AUFS dan / atau kernel masalahnya.

boot2docker / boot2docker _did_ mengubah versi kernel dan AUFS commit untuk rilis 1.9.1, jadi kedua faktor tersebut perlu dikesampingkan atau diselidiki lebih lanjut:

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

Saat ini mencoba 1.9.0 ISO dengan 1.9.1 biner untuk melihat apakah area permukaan area bug potensial dapat dikurangi lebih jauh.

Dockerfile akan dibangun dengan baik dan tidak tergantung pada boot2docker 1.9.0 ISO dengan biner Docker 1.9.1. Masalahnya tampaknya tidak terletak pada Docker 1.9.1, melainkan lingkungan tempat ia dijalankan.

Saya menggunakan rilis 1.9.1 tanpa masalah pada aufs, tetapi memiliki lebih banyak cpu / ram / penyimpanan secara signifikan daripada konfigurasi mesin default.

Saya baru saja mencoba meningkatkan memori menjadi 4GB untuk VM saya, tetapi masih bisa mereproduksi

@ cpuguy83 AUFS pada boot2docker 1.9.1?

Seperti disebutkan di atas, b2d menggabungkan versi AUFS yang sangat spesifik.

Ya

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

Saya juga melihat beberapa proses java menjadi tidak berfungsi dalam sebuah wadah. Saya dapat mereproduksi masalah ini dengan langkah-langkah berikut
jalankan wadahnya:

docker run --rm -it myJavaContainerFromCentos7 bash

buat Foo.java dengan yang berikut ini:

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

mengkompilasi dan menjalankannya menghasilkan proses java yang tidak berfungsi, dengan 1 inti menggunakan 100% cpu:
javac Foo.java && java Foo

namun ... jika System.exit(0); ditambahkan setelah println semuanya baik-baik saja:

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

informasi versi:
osx 10.10.3
buruh pelabuhan 1.9.1
boot2docker versi 1.9.1 uname -a adalah "linux ci 4.1.13-boot2docker"
numproc = 1

keluaran strace dengan System.exit (0);

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

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

prosesnya sekarang sudah berhenti tetapi Anda dapat memasuki wadah:

docker exec -it myContainer bash

dan lihat yang berikut ini:

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

lihat sekilas statistik:

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

Semuanya bekerja dengan baik di 1.8.3.

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

+1, Docker versi 1.9.1, build a34a1d5, OS X 10.10.5, Versi Mesin Docker: 0.5.1 (HEAD)

+1

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

+1

Docker versi 1.9.1, build a34a1d5 di OS X 10.11.1

Masalah ini sangat aneh. Jika saya strace perintah apt-get gagal, akhir dari keluarannya adalah:

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)

Di mana kesalahan (Deskriptor file buruk) itu terus berulang tanpa batas.

RLIMIT_NOFILE
              Specifies a value one greater than the maximum file descriptor
              number that can be opened by this process.  Attempts (open(2),
              pipe(2), dup(2), etc.)  to exceed this limit yield the error
              EMFILE.  (Historically, this limit was named RLIMIT_OFILE on
              BSD.)

SIGPIPE gagal? ini mungkin sesuai dengan posting saya sebelumnya di mana saya melihat java "hello world" menyebabkan proses zombie tanpa eksplisit "System.exit (0);" - atau mungkin itu masalah yang sama sekali berbeda. jika sangat menyesal atas kebisingannya.

apa yang terjadi pada cpu Anda saat melakukan perulangan tanpa batas?

@andrewgdavis Ini di 100%

java "hello world" menyebabkan proses zombie tanpa "System.exit (0);" eksplisit

Itu pasti terdengar mirip dengan masalah yang dihadapi di sini.

Saya pasti dapat mengkonfirmasi masalah b2d (bahkan melakukan bisect untuk melacaknya paling positif ke benjolan kernel 4.1.13). Saya juga bisa mereproduksi di 4.2.6 dengan b2d.

Sebagai tambahan, host Gentoo saya saat ini menggunakan patch 4.1.13 + AUFS juga, dan saya melihat masalah yang sama persis, jadi kami pasti mengesampingkan semua yang spesifik b2d.

Saya pikir mungkin ada gunanya menelusuri komit antara 4.1.12 dan 4.1.13 untuk melihat apakah sesuatu yang mungkin terkait melompat keluar.

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

Yup, ada yang rusak dari kernel 4.1.12 => 4.1.13. Saya dapat mengonfirmasi bahwa memanggang ISO boot2docker untuk yang pertama tidak membuat bug ini tersandung tetapi yang pertama tidak.

Jadi, ini tidak secara khusus terkait dengan boot2docker, tetapi tampaknya terkait dengan versi kernel yang berinteraksi dengan AUFS.

atau mungkin cara spesifik driver AUFS di Docker berinteraksi dengan file
kernel yang lebih baru - TBD, mungkin dengan git stabil linux yang membagi dua antara 4.1.12
dan 4.1.13: menangis:

saya punya teori rambut otak ...

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

komit di atas membuat perubahan ke filemap.c menjadi generic_perform_write (struct file * file, struct iov_iter * i, loff_t pos)

di bawah ini adalah potongan kode yang secara pribadi ingin saya uji karena komentar tersebut menjelaskan kondisi balapan deadlock dan livelock dan saya melihat cpu dipatok pada 100%. tapi itu hanya saya dan tikar lompatan ke kesimpulan saya.

4.1.13 mm / peta file.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 seseorang dapat menggunakan komit itu selama git bisect sebagai titik pengujian spesifik!

Melihat hang yang serupa saat mematikan mongodb . Pasti ada di 1.9.x. Tidak ada di 1.8.x.

Saya dapat memecahkan masalah ini sendiri dengan meningkatkan memori VM mesin galangan dari 1024 menjadi 2048 MB dan menetapkan 2 CPU, bukan 1.

Pekerjaan:

VM: Ubuntu 14.04 (ram 2gb)
Mesin Docker: 1.9.1
Gambar dasar Docker: ubuntu: terbaru

Tidak bekerja:

VM: Ubuntu 15.10 (2 gb ram)
Mesin Docker: 1.9.1,1.9.0,1.8.3
Gambar dasar Docker: ubuntu: terbaru , ubuntu: 14.04

@marsinvasion Jika memungkinkan, dapatkah Anda mencetak keluaran uname -a pada kedua sistem yang diuji?

VM: Ubuntu 14.04
Linux ubuntu 3.19.0-25-generik # 26 ~ 14.04.1-Ubuntu SMP Jum 24 Juli 21:16:20 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux

VM: Ubuntu 15.10
Linux ubuntu 4.2.0-19-generik # 23-Ubuntu SMP Rabu 11 Nov 11:39:30 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux

+1
Docker versi 1.9.1, build a34a1d5 di OS X 10.11.1

Ditemukan di OS X 10.9.5 dengan buruh pelabuhan 1.9.1.

Terinspirasi oleh @marsinvasion , saya mendapatkan solusi yang berhasil dengan memberikan 2 CPU mesin galangan saya dan RAM 4096Mb.

Ups, segera bicara. Itu berhenti bekerja saat mengubah Dockerfile yang sedang saya kerjakan dan menjalankan kembali build.

Juga melihat bug yang sangat besar ini (mesin galangan boot2docker 1.9.1 di OS X), dari gambar ubuntu: 15.04 yang dibangun sebelumnya. Tampaknya perlu me-restart server buruh pelabuhan saya untuk menghapus kontainer zombie itu.

Saya pikir https://github.com/docker-library/java/issues/19 terkait tetapi mungkin tidak, di sini kita mendapatkan hang, di sana mereka mendapat kesalahan tentang tidak menemukan "java".

Mengalihkan server saya ke overlay sebagai solusi. Sebelumnya ia juga membuat banyak wadah zombie.

Docker versi 1.9.1, build a34a1d5 di OS X 10.11.1

Adakah yang tahu apa yang terlibat dalam migrasi sistem boot2docker.iso yang ada ke https://docs.docker.com/engine/userguide/storagedriver/overlayfs-driver/ atau lebih mudah untuk melakukan rekondisi penuh? Halaman itu memiliki peringatan yang tidak menyenangkan tentang build gambar CentOS - apa solusi "yum", apakah ini terkait dengan https://github.com/docker/docker/issues/10180?

Sudah diperbaiki di 1.9.1a - instal ini jika Anda menggunakan OSX - https://github.com/docker/toolbox/releases/download/v1.9.1a/DockerToolbox-1.9.1a.pkg

Jelas tidak diperbaiki oleh Docker Toolbox 1.9.1a. Menderita bug ini dengan versi itu. Melihat kembali komentar-komentarnya, sepertinya saya bukan satu-satunya.

tidak masih belum membangun

Saya harus menghapus VM di virtualbox dan mulai dari awal agar berfungsi.

Selain itu, coba hapus dan buat VM baru beberapa kali tetapi tidak berhasil.

Menginstal 1.9.1a, melakukan docker-machine rm default dan menggunakan Terminal Mulai Cepat Docker untuk membuat ulang mesin default. Gambar yang dibuat ulang (yang berasal dari java:7-jre ) dan sudah berjalan, masih tidak berfungsi. Terus bekerja dengan baik dengan mesin overlay yang dibangun seperti yang disarankan di atas:

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

^ terima kasih! Saya dapat mengonfirmasi bahwa mesin overlay berfungsi.

Menggunakan overlay sebagai driver penyimpanan mesin juga berfungsi untuk memperbaiki hang shutdown MongoDB.

Anda dapat mengatasi kegagalan build Dockerfile dengan menginstal Oracle java sebagai ganti OpenJDK:

# Oracle java is bulkier but avoids boot2docker/aufs docker issue 18180
RUN apt-get install -y software-properties-common python-software-properties && add-apt-repository -y ppa:webupd8team/java && apt-get update
RUN echo oracle-java8-installer shared/accepted-oracle-license-v1-1 select true | /usr/bin/debconf-set-selections
RUN apt-get install -y oracle-java8-installer && apt-get install -y oracle-java8-set-default

Tapi saya meremehkan ruang lingkup masalah, boot2docker 1.9.1 mengarah ke proses java zombie, bahkan pada wadah CentOS di mana openjdk diinstal dengan baik.
root 322 11.1 0.0 0 0 ? Zsl 18:43 29:48 [java] <defunct>

Saya tidak dapat mengkonfigurasi server buruh pelabuhan saya dengan --engine-storage-driver overlay karena saya membuat gambar berbasis CentOS, dan overlayfs tidak kompatibel dengan yum (https://github.com/ buruh pelabuhan / buruh pelabuhan / masalah / 10180).

Saya yakin orang-orang Docker akan _not_ merekomendasikan ini, tetapi cara saya melewati masalah pemblokiran ini adalah dengan membangun boot2docker.iso yang menggunakan docker 1.9.1 dengan AUFS yang sedikit lebih tua. Petunjuk di https://github.com/boot2docker/boot2docker/issues/1099#issuecomment -163052066.

mencoba oracle jdk1.7.0_75 dan jdk1.8.0_65; keduanya hang dan membuat proses java tidak berfungsi.

DARI: https://github.com/docker/docker/issues/10589
@neverfox masalah yang sama persis di sini, dengan gambar yang sama +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"
            }
        }
    }
}
]

Saya hanya menjalankan docker run -it cassandra:2.1.11 dan terminal Anda akan macet, tidak ada cara untuk menghentikan penampung. Anda harus menghentikan seluruh VM.

+1

Dapat menduplikasi masalah sebelumnya hari ini di Docker 1.9.1 yang menjalankan Mac OSX 10.11.1 (15B42)

Mampu menyiasatinya dengan menginstal Docker 1.9.0

_Mohon maaf atas kurangnya informasi ada di mesin kerja saya lebih awal pada siang hari - akan memberikan informasi terbaru di lain waktu _

: +1:

Sama di sini dengan Docker 1.9.1 dan OS X 10.11.

Untuk orang yang mengalami masalah ini

Sejauh ini kita telah mempersempitnya menjadi bukan bug _docker_ tetapi masalah kernel yang dikombinasikan dengan AUFS di kernel yang digunakan oleh versi boot2docker saat ini; lihat https://github.com/docker/docker/issues/18180#issuecomment -161832035

• Jika Anda ingin terus mengetahui perkembangannya, gunakan tombol berlangganan di halaman ini. jangan berkomentar jika Anda tidak memiliki informasi baru yang dapat membantu menyelesaikan masalah ini.
• jika Anda ingin membantu menyelesaikan masalah ini, melakukan git-bissect pada kernel dapat membantu https://github.com/docker/docker/issues/18180#issuecomment -161834068
• Ingatlah bahwa setiap komentar akan mengirimkan lebih dari 2000 email ke pelanggan, dan anak anjing yang tak terhitung jumlahnya akan mati: senyum:

Baru saja menguji Storage Driver: devicemapper (dengan Server Version: 1.9.1 dan kernel 4.2.6), dan bug _not_ mereproduksi, jadi kami masih dalam "interaksi aneh antara beberapa perubahan di kernel yang lebih baru dan patch AUFS "tanah. :kecewa:

Telah diuji, dan bug masih ada di kernel 4.1.14 baru , jadi kami masih menggunakan beberapa commit yang telah di-backport ke 4.1.13 berinteraksi aneh dengan patch AUFS (dan tidak beruntung karena sudah diperbaiki di sementara).

Saya memutuskan untuk mencobanya dan mengkloning repo boot2docker; lalu memodifikasi aufs commit di dockerfile ke versi sebelumnya. Jadi buruh pelabuhan 1.9.1 kernel 4.1.13 + versi AUFS sebelumnya yang dikirim sebelum 1.9.1. Kompilasi lambat di mesin saya ... apakah ada pengaturan kawanan buruh pelabuhan yang dapat saya jalankan bersama dengan git bisect dan menggabungkan hasilnya? itu akan manis.

Bagaimanapun, saya akan memposting hasil saya segera jika berhasil ...

memperbarui:
4.1.13 + komit AUFS ini masih menunjukkan masalah.
ENV AUFS_COMMIT 1724fe65683d126a92c6baeea0b3c7d0306c63ef

Saya tidak mengetahui adanya pengaturan yang mudah untuk menggabungkan hasil, meskipun ada yang bisa dibuat.

FWIW, https://sources.debian.net/src/ca-certificates-java/jessie/debian/postinst.in/ adalah skrip persis yang berjalan dalam paket itu, dan https://sources.debian.net/src /ca-certificates-java/jessie/src/main/java/org/debian/security/UpdateCertificates.java/ adalah sumber Java yang dieksekusi saat kita mendapatkan CPU yang dipatok hang + defunct +.

Masuk ke masalah terkait (proses java hang) hari ini.

Lingkungan host: Linux lenovo 4.2.0-19-generik # 23-Ubuntu SMP Rabu 11 Nov 11:39:30 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux
Distro: Ubuntu 15.10
Mesin Docker: 1.9.1
Mesin Docker: 0.5.0 (04cfa58)

Saya mengikuti tutorial multi-host jaringan . Satu-satunya perbedaan adalah saya bermain-main dengan gambar oracle / nosql . Gambar itu didasarkan pada Oracle Linux dan menggunakan OpenJDK.

@brunoborges ya, itu bisa jadi masalah yang sama, lihat https://github.com/docker/docker/issues/18500#issuecomment -163334612

@brunoborges cukup periksa versi boot2docker.iso Anda - jika 1.9.1 Anda dapat mencoba menurunkan versi ke 1.9.0 dan membuat ulang mesin Anda dan menarik gambar sekali lagi.
Jika Anda melakukannya dengan cara ini, dapatkah Anda menulis laporan singkat di sini?

Jadi saya bertanya-tanya mengapa ini hanya terjadi di java, dan bukan bahasa lain. Di salah satu posting saya sebelumnya, saya dapat merinci reproduksi paling dasar hanya dengan menyusun dan menjalankan

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

untuk kasus kegagalan yang mengakibatkan proses java tidak berfungsi
lalu

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

untuk kasus yang diharapkan (tidak mati).

Saya kemudian mencoba mereproduksi sesuatu yang serupa menggunakan python. Saya tidak berhasil - tetapi saya mencoba. Bagi yang tertarik saya mencoba memamerkan hasil strace terakhir exit_group(0) = ? yang terlihat dari proses zombie java. (Tautan ini memberi saya banyak info tentang python threading / seccomp / etc http://stackoverflow.com/questions/25678139/how-do-you-cleanly-exit-after-enabling-seccomp-in-python)

Jadi pindah ke lahan kernel: Setelah membangun kembali boot2docker iso, mengotak-atik versi aufs dan versi kernel (tidak ada yang benar-benar membuat perbedaan) saya muak dengan betapa lambatnya proses kompilasi menggunakan numproc = 1. Jadi saya mengubahnya menjadi 6. ==> note tidak lagi 1 cpu (siapa yang hanya punya 1 cpu sekarang sehari?). Tiba-tiba kasus kegagalan

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

mulai bekerja.

Jelas, hal berikutnya untuk dicoba adalah menurunkannya kembali ke 1 cpu. ==> GAGAL. kembali ke proses java yang tidak berfungsi.

Jadi saya ingin menjelajahi lebih lanjut tentang bagaimana java dimatikan. Itu tidak didefinisikan dengan baik. tetapi hanya dengan 1 cpu, proses java ini dapat dijalankan dengan sukses: (tolong jangan mengejek java saya yang mengerikan.)

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

Adakah orang lain yang dapat mengkonfirmasi perilaku ini? << pertanyaan sekarang diperdebatkan

Pembaruan: Bahkan dengan lebih dari satu inti, proses java yang tidak berfungsi dapat terjadi. (Saya menjalankan cassandra-cli dan itu terjadi.)

buruh pelabuhan-mesin 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

Memiliki masalah gantung yang sama dalam membangun bitbucket-server - update-ca-certificate berfungsi dengan baik tetapi jdk posthook hang selamanya. Hanya masalah saat menggunakan 1.9.1 boot2docker. Beralih ke image RancherOS dan tidak memiliki masalah. OSX 10.10.

Dengan El Capitan, Docker 1.9.1 dan Ubuntu 14.04.1 Saya mendapatkan: Menyiapkan ca-certificate-java yang macet tanpa batas.

@stremlenye memutar kembali ke 1.9.0. Masih hang.

@brunoborges buruh pelabuhan 1.9.0 atau boot2docker.iso 1.9.0?

@stremlenye Docker 1.9.0 ... apa saja petunjuk untuk mendapatkan boot2docker.iso 1.9.0 di sistem saya?

@brunoborges Lihat komentar ini di atas:

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

carsten-ulrich-saitow-ag menjelaskan cara membuat mesin buruh pelabuhan baru dengan iso 1.9.0 menggunakan flag --virtualbox-boot2docker-url. Nasihat itu menyelamatkan daging saya! Setelah saya melakukannya, saya dapat sekali lagi menginstal JRE RPM saya di container saya.

@ mobsy74 @stremlenye mencoba dengan boot2docker 1.9.0 dan terkadang hang.

@brunoborges Terima kasih telah mencobanya. Jadi saya akan tetap menggunakan 1.8.3 sampai bug ini diperbaiki.

@stremlenye maksud Anda boot2docker 1.8.3?

@broborges ya

Hai,
saya memiliki masalah yang sama.
Masalah terpecahkan saat menurunkan alat buruh pelabuhan dari 1.9.1 ke 1.9.0
https://github.com/docker/toolbox/releases/download/v1.9.0/DockerToolbox-1.9.0.pkg

Mengaktifkan beberapa CPU (di mesin buruh pelabuhan) memecahkan masalah ini untuk saya.

--virtualbox-cpu-count=4

@heiths bisakah kamu berbagi versi alat buruh pelabuhan?

imho, boot2docker harus menjauh dari aufs ke salah satu driver penyimpanan lain yang tersedia. Ada alasan bagus mengapa aufs tidak pernah berhasil masuk ke kernel linux.

@robvanmieghem setiap pengemudi memiliki keterbatasan. Aufs cukup stabil secara keseluruhan, dan overlayf memiliki beberapa masalah pemblokiran (tergantung penggunaan)

@brunoborges DockerToolbox-1.9.1c - ini berfungsi untuk saya di windows dan osx.

@thaJeztah tidak pernah mengatakan overlayfs adalah solusi sempurna. Saya pikir btrfs adalah pilihan yang baik untuk boot2docker, boot2docker didedikasikan untuk menjalankan kontainer buruh pelabuhan dan selain fakta bahwa btrfs didukung penuh di kernel linux, sangat mudah untuk melihat isinya.

Ada banyak pendapat tentang ini karena ada kombinasi distro dan filesystem :) Tidak ada solusi yang akan sempurna untuk semua kasus penggunaan jadi dengan semangat open source dan linux saya pikir keputusan terbaik yang harus diambil adalah memberikan yang lebih baik dukungan untuk berbagai pilihan distro. Kami sudah memiliki pilihan Boot2Docker atau RancherOS dan saya yakin beberapa pekerjaan telah dilakukan untuk membangun kembali boot2docker pada basis distro debian. docker-machine akan mendukung ubuntu di cloud dan bare metal jadi saya yakin vm iso berbasis ubuntu tidak akan sulit untuk digabungkan serta yang lain seperti yang dibangun di atas alpine atau CoreOS dll. Lalu untuk masing-masing ada pilihan filesystem - sekali lagi, RancherOS sekarang menawarkan ZFS sebagai penginstalan opsional sementara CoreOS digunakan untuk menggunakan BTRFS secara default dan saya percaya itu masih merupakan opsi dan pada kernel 3.19 Ubuntu mendukung OverlayFS di luar kotak - siapa pun untuk berbasis Snappy Core gambar b2d? ;)

Sekarang, jika saja kita dapat menstandarkan penamaan parameter mesin-buruh pelabuhan dan menghapus referensi ke 'boot2docker' untuk mengurangi kebingungan - menggunakan parameter boot2docker-url untuk menginstal RancherOS agak tidak intuitif;)

@ far-blue +1

@ hes +1. Ini menyelesaikannya untuk saya juga di OSX dengan 1.9.1c

Menyetel CPU ke> 1 menghindari masalah bagi saya. 1.9.1c tidak membantu.

@heiths @fredriksvensson Sebenarnya saya memiliki masalah ini secara acak muncul di lingkungan beberapa kontainer dan saya juga mencoba untuk meningkatkan jumlah CPU (memori juga, tapi bukan itu intinya). Beberapa siklus stop <all> / start <all> menunjukkan bahwa masalah belum hilang. Saya akan merekomendasikan Anda untuk memeriksa lingkungan Anda dengan cara yang sama untuk memastikan solusinya stabil untuk Anda.
/ cc @timechanter

Oh, itu pasti belum hilang. Tapi 10% kemungkinan hang versus 100% hang setidaknya bisa dikelola untuk jangka pendek.

@heiths --virtualbox-cpu-count=4 juga bekerja untuk saya.

@timechanter +1 Mengatur CPU ke> 1 telah menghindari masalah bagi saya setidaknya sekali; sepertinya solusi yang efektif saat ini.

OSX 10.10.5

Toolbox Docker yang tidak terpasang 1.9.1. Mendowngrade ke toolbox Docker 1.9.0 bekerja untuk saya.

Masalah yang sama di El Capitan MacOSX

@heiths --virtualbox-cpu-count=4 bekerja untuk saya juga.

Terjadi untuk saya di Windows 7 dengan Docker Toolbox 1.9.1b dan 1.9.1e.

"Menyiapkan ca-certificate-java (20130815ubuntu1) ..." - El Capitan MacOSX. Mohon bantuannya !!! Saya tidak bisa memperbaikinya

@ troian88 downgrade ke boot2docker.iso 1.9.0 atau 1.8.3.

@ troian88 , gunakan mesin buruh pelabuhan dengan beberapa CPU.

Dapat mengonfirmasi bahwa --virtualbox-cpu-count=2 adalah solusi sementara untuk menggantung Setting up ca-certificates-java dengan Docker 1.9.1

Untuk orang yang mengalami masalah ini

Sejauh ini kita telah mempersempitnya menjadi bukan bug _docker_ tetapi masalah kernel yang dikombinasikan dengan AUFS di kernel yang digunakan oleh versi boot2docker saat ini; lihat https://github.com/docker/docker/issues/18180#issuecomment -161832035

• Jika Anda ingin terus mengetahui perkembangannya, gunakan tombol berlangganan di halaman ini. jangan berkomentar jika Anda tidak memiliki informasi baru yang dapat membantu menyelesaikan masalah ini.
• jika Anda ingin membantu menyelesaikan masalah ini, melakukan git-bissect pada kernel dapat membantu https://github.com/docker/docker/issues/18180#issuecomment -161834068
• Ingatlah bahwa setiap komentar akan mengirimkan lebih dari 2000 email ke pelanggan, dan anak anjing yang tak terhitung jumlahnya akan mati: senyum:

@externl @stremlenye Terima kasih.

Melihat tumpukan LWP, saya menemukan bahwa bug tersebut disebabkan oleh aufs_destroy_inode .

Saya akan melihat lebih jauh tentang ini.

Sepertinya ada kebuntuan terkait 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).

Catatan

Orang-orang mengatakan bahwa bug dapat dihindari saat berjalan di banyak CPU.
Namun, saya masih dapat menemukan bug dengan kotak 4-CPU fisik saya. (meskipun <1% probabilitas.)
Jadi --virtualbox-cpu-count=2 tidak _NOT_ menjamin bahwa Anda dapat menghindari bug.

Perhatikan bahwa jumlah CPU tetap penting.
Saya dapat menemukan bug secara deterministik ketika saya menjalankan taskset 0x1 java . ( taskset memberikan CPU tertentu ke proses).

@AkihiroSuda terima kasih banyak telah melihat ini. Terus kabari kami! :jantung:

Perhatikan bahwa masalah ini juga terjadi di Windows 7 saat menggunakan Docker 1.8.3.

Kami melihat hal yang sama (jejak tumpukan yang persis sama seperti dalam komentar AkihiroSuda di atas) pada kernel lama:
Linux 3.19.0-42-generic #48~14.04.1-Ubuntu SMP x86_64 dengan Docker version 1.9.1, build a34a1d5

Saya dapat mengkonfirmasi pernyataan @AkihiroSuda tentang banyak CPU - Saya menekan ini di host saya juga yang memiliki 8 core.

Debugging AUFS terlihat sangat menarik - mungkin ada baiknya mengajukan masalah dengan AUFS dan melihat apakah pengelola AUFS dapat membantu men-debug? Mungkin akan membantu bagi mereka jika kami dapat mereproduksi hanya dengan AUFS (tanpa Docker), tetapi itu tidak terlalu sepele. :tersenyum:

@tianon Saya membuat posting di aufs-users: http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/5335

@ AkihiroSuda , saya telah melihat ini tergantung pada kasus penggunaan non-Java. Yakni mencoba mematikan daemon MongoDB bercabang. Ini tidak terjadi pada permulaan MongoDB atau penggunaan biasa, tetapi terjadi dengan andal saat dimatikan.

@jakirkham Terima kasih, tampaknya konfigurasi utas tertentu (cenderung muncul di Java, MongoDB, dan mungkin hal lain) diperlukan untuk memicu bug.

BTW, setelah dipikir-pikir, mungkin AUFS gantung adalah "hasil" dari bug daripada "penyebab" dari bug.
Saya melihat topik ini: http://www.serverphorums.com/read.php?12 , 673905
(Saya tidak memperhatikan bahwa zap_pid_ns_processes() juga hang dua hari yang lalu, karena saya telah menggunakan bash sebagai proses init pada saat itu. Https://github.com/docker/docker/issues/18180#issuecomment- 166186061)

https://github.com/docker/docker/issues/18180#issuecomment -161843456
@andrewgdavis , Anda benar!

Bug tampaknya merupakan regresi yang disebabkan oleh komit 296291cd ke kernel Linux ( mm/filemap.c ).

Saya membuat ISO Boot2Docker ( boot2docker-v1.9.1-fix1.iso ) yang menghilangkan komit 296291cd: https://github.com/AkihiroSuda/boot2docker/releases/tag/v1.9.1-fix1

Semoga berhasil untuk semua orang. : smiley:

Komit 296291cd menghasilkan loop -EINTR tak terbatas dalam mm/filemap.c:generic_perform_write , yang tidak dapat ditoleransi oleh fs/aufs/xino.c:do_xino_fwrite() :

static ssize_t do_xino_fwrite(vfs_writef_t func, struct file *file, void *kbuf,
                  size_t size, loff_t *pos)
{
..
    do {
         /* cannot escape from this loop 
            when func returns -EINTR infinitely! */
        err = func(file, buf.u, size, pos);
    } while (err == -EAGAIN || err == -EINTR);
..
}

Karena do_xino_fwrite() berulang tanpa batas, zap_pid_ns_processes() (dieksekusi di LWP lain) tidak dapat kembali dari schedule() saat dijalankan pada satu prosesor.
Itulah mengapa kami terkena bug.

@ gilles-dubosc
Anda terkena bug karena Canonical awalnya mem-backport komit 296291cd ke pohon kernel 3.19: http://kernel.ubuntu.com/git/ubuntu/ubuntu-vivid.git/commit/?id=6b08592b8acc677d5b9bb7986343fdd6e0ad3303

@AkihiroSuda wow, terima kasih telah menemukan! Apa langkah selanjutnya? Haruskah tambalan itu dikembalikan, atau adakah cara untuk memperbaiki tambalan itu? Apakah Anda mempertimbangkan untuk mengirim tambalan ke kernel upstream?

@AkihiroSuda , perbaikan Anda berfungsi seperti pesona. Terima kasih!

@tokopedia

Itu bukanlah pertanyaan yang mudah.
Tanpa commit 296291cd, sendfile(2) dapat terbunuh.
Saya takut sendfile dapat dibunuh ini dapat menyebabkan masalah keamanan (yaitu, proses serangan kelelahan oleh pengguna anonim) di beberapa lingkungan tertentu.

Saya mencoba untuk meningkatkan commit 296291cd, tapi mungkin butuh beberapa saat.

Bagaimanapun, saya melaporkan bug ini ke bugzilla kernel: https://bugzilla.kernel.org/show_bug.cgi?id=109971

Saya juga membuat container Docker akihirosuda/test18180 untuk kemudahan debugging: 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, baiklah, sepertinya ada masalah, ya. Terima kasih banyak atas repro-container dan penelitiannya; setidaknya ada tugas yang sangat spesifik untuk dikerjakan, semoga orang lain akan bergabung, mencoba membantu mencari solusi. Terima kasih banyak atas kerja bagus Anda sejauh ini.

Saya terkena OS X El Capitan Darwin Kernel Version 15.2.0
Docker versi 1.9.1, build d12ea79c9de6d144ce6bc7ccfe41c507cca6fd35
boot2docker 1.9.1

Downgrade ke boot2docker 1.9.0 dengan perintah di bawah ini berhasil untuk saya:

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

@tokopedia
AUFS akan mendukung 296291cd.
http://article.gmane.org/gmane.linux.file-systems.aufs.user/5343

Jadi langkah selanjutnya adalah menunggu update AUFS.

Anda seorang pahlawan, @AkihiroSuda! Terima kasih telah bekerja dengan upstream untuk menyelesaikannya! :jantung:

Jika ada yang ingin menerapkan perbaikan @AkihiroSuda , ini berfungsi seperti pesona:

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

Bagi siapa pun di Ubuntu 14.04, menurunkan versi ke kernel 3.13.0-71 atau lebih lama akan menyelesaikan masalah. 296291cd di-backport setelah itu .

@ebpitts terima kasih atas tipnya, berikut adalah langkah-langkah yang agak relatif untuk menurunkan versi kernel Ubuntu 14.04 menjadi 3.13.0-71 dengan Docker 1.9.1 diinstal.

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

Pada titik ini Anda harus memiliki dua kernel untuk dipilih selama bootloading. Namun, saya menjalankan di kotak Vagrant jarak jauh melalui SSH, jadi tidak ada bootloader GRUB untuk saya ... jadi saya menghapus kernel default yang lebih baru (3.13.0-74 dalam kasus saya) sebagai opsi boot:

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

Output dari perintah memiliki beberapa hal tentang Grub yang diperbarui, sehingga Anda dapat memeriksa /boot/grub/grub.cfg dan melihat apa opsi boot default akan dimulai ulang. Saya tampaknya harus melakukan ini untuk menghapus / menambahkan kembali header, tetapi setelah file grub.cfg terlihat bagus ( 3.13.0-71-generic adalah satu-satunya dan opsi boot pertama) kemudian lanjutkan dan reboot:

sudo reboot

Dan, kemudian, kembalikan SSH ke kotak saya:

$ uname -r
3.13.0-71-generic

Tapi sekarang sepertinya buruh pelabuhan tidak bekerja. Jadi, instal ulang penuh harus dihapus terlebih dahulu:

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

Dan, sejujurnya, kemudian upaya saya berikutnya untuk menjalankan docker build pada wadah yang sama yang tergantung pada judul OP ("Menyiapkan ca-certificate-java"), _still_ mati dan mengunci mesin saya kali ini , tetapi sekarang saya tidak memiliki akses SSH, saya akan pulang dan menunggu hingga 2016 untuk mencoba melihat apakah orang lain memiliki perbaikan yang lebih baik saat itu = /

Jadi ... Saya tidak dapat menegaskan bahwa bahkan setelah menurunkan kernel ke 3.13.0-71 setelah mengenai masalah ini di Ubuntu 14.04 + Docker 1.9.1 bahkan efektif. Yuck.

Ya, hanya untuk konfirmasi ganda, saya menjalankan $ docker run -it --rm akihirosuda/test18180 dan masih hang.

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

Ini setelah menurunkan Ubuntu 14.04 ke versi kernel 3.13.0-71 dengan AUFS

$ docker info
Containers: 3
Images: 18
Server Version: 1.9.1
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 24
 Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-71-generic
Operating System: Ubuntu 14.04.3 LTS
CPUs: 1
Total Memory: 490 MiB
Name: myrunner
ID: MLBL:bla:blah

@ebpitts apakah Anda yakin bahwa penurunan versi kernel di Ubuntu benar-benar telah diperbaiki?

Menarik, bahkan ketika saya mengatur driver penyimpanan secara eksplisit devicemapper dalam /var/default/docker :

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

dan restart layanan buruh pelabuhan, menjalankan docker info :

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

Saya masih bertahan di gambar percobaan akihirosuda/test18180:latest .

Saya menurunkan versi ke Docker 1.8.3 (tidak semudah tanpa apt-get ) di kotak Ubuntu 14 saya menggunakan biner mentah, berikut adalah langkah-langkahnya ... untuk orang lain ... Saya kembali berbisnis (tolong perhatikan saya juga menurunkan kernel menjadi 3.13.0-71-generic sebelumnya juga, lihat di atas)

Saya menginstal biner 1.8.3 dari https://get.docker.com/builds/Linux/x86_64/docker-1.8.3 , lalu memindahkannya ke /usr/bin/docker , memberinya izin yang dapat dieksekusi sudo chmod +x /usr/bin/docker .

Kemudian, saya mengambil skrip mentah sysvinit-debian , mengomentari tubuh check_init() dan menggantinya dengan echo '' dan menjatuhkannya ke /etc/init.d . Kemudian saya mengaturnya untuk berjalan saat boot startup sebagai root dengan ln -s /etc/init.d/docker /etc/rc2.d/S99docker , dan menjalankan sudo reboot . Setelah itu, saya kembali menjalankan layanan buruh pelabuhan 1.8.3 saat boot dari instalasi biner. Saya tidak tahu mengapa langkah-langkah ini tidak benar-benar didokumentasikan di halaman instal-biner di situs buruh pelabuhan. Pokoknya.

$ 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

Terlihat bagus di sini - Saya dapat menjalankan $ docker run -it hello-world dengan benar. Menjalankan akihirosuda/test18180 sebenarnya masih hang (???) tetapi saya dapat membangun dan menjalankan container asli saya tanpa macet di Setting up ca-certificates-java , yang membawa saya ke sini.

Untuk referensi, saya menggunakan Ubuntu 15.04 vivid, Linux 3.19.0-42-generic. Juga terpengaruh.

Karena saya tidak dapat menggunakan overlay (saya memerlukan tamu RHEL), saya membuat partisi btrfs pada drive cadangan, dan memasangnya ke / var / lib / buruh pelabuhan (hentikan daemon buruh pelabuhan sebelumnya). Docker sekarang menggunakan btrfs dengan senang hati, namun image @akihirosuda masih hang di cek kedua (aneh).

@tokopedia
Terima kasih telah menguji gambar test18180 .

Hasilnya tidak aneh.
Cek kedua ( Checking whether sendfile(2) is killable. ) ditutup di kernel lama.
Anda membutuhkan kernel yang lebih baru dengan 296291cd untuk lolos pemeriksaan kedua.

| AUFS? | Kernel mencakup 296291cd? | Hasil yang Diharapkan |
| --- | --- | --- |
| Y | Y | Hang (Cek pertama: Checking whether hitting docker#18180. ) |
| Y | N | Hang (Cek ke-2: Checking whether sendfile(2) is killable. ) |
| N | Y | Lulus |
| N | N | Hang (Cek ke-2: Checking whether sendfile(2) is killable. ) |

@cfstras Terima kasih, saya akan memeriksanya.

@cfstras , dapat direproduksi, dan saya membuka # 19073.

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

EDIT:
Sebelumnya saya salah tentang mengapa buruh pelabuhan tidak berfungsi setelah mengubah versi kernel, tetapi saya dapat mengonfirmasi menginstal paket tambahan untuk kernel saya dan kemudian menginstal ulang buruh pelabuhan menyelesaikan masalah ini untuk saya:

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

@lwcolton menarik, linux-image-extra-3.13.0-71-generic bukanlah paket yang saya pikir akan saya instal (tetapi saya menginstal paket tambahan generik sesudahnya, seperti yang disebutkan) .... tapi tetap saja, saya mendapat kesan bahwa modul AUFS jauh lebih tua daripada hanya kernel 3.13.0-71 relatif baru. Terlepas dari itu, menurunkan versi ke Docker 1.8.3 juga tidak terlalu menyakitkan, dan jika saya harus melalui proses lagi, saya lebih suka menurunkan versi Docker daripada menurunkan versi kernel linux setiap hari dalam seminggu.

@dschep Catatan untuk orang lain yang beralih ke OverlayFS membutuhkan versi kernel 3.18 + di Linux, dan seperti dikutip di halaman Docker, _Seperti yang menjanjikan seperti OverlayFS, ini masih relatif muda.

@ mikeatlas Saya rasa ini adalah batasan terbesar sejauh ini di OverlayFS: "_Karena itu, menggunakan yum di dalam container di host Docker menggunakan driver penyimpanan overlay tidak mungkin berfungsi tanpa menerapkan solusi._".

@brunoborges yum saat ini sedang ditambal untuk bekerja pada overlayfs, jadi, segera, versi yum yang lebih baru seharusnya dapat bekerja pada overlayfs (masih akan ada beberapa masalah, jadi itu tergantung pada kasus penggunaan / situasi Anda mengalami mereka). Penggunaan inode yang berlebihan bisa menjadi masalah lain.

Saya yakin saya juga mengalami masalah ini. Pelacakan panggilan menyebutkan apparmor, tetapi menonaktifkan apparmor tidak ada bedanya. Menggunakan devicemapper membuat masalah hilang.

dmesg:

[ 2761.400178] INFO: task flake8:4231 blocked for more than 120 seconds.
[ 2761.403014]       Not tainted 3.13.0-74-generic #118-Ubuntu
[ 2761.405419] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 2761.408741] flake8          D ffff8807707d3180     0  4231   1798 0x00000000
[ 2761.408745]  ffff8806bcb07c70 0000000000000082 ffff880035b34800 ffff8806bcb07fd8
[ 2761.408748]  0000000000013180 0000000000013180 ffff880035b34800 ffff8806b95054f8
[ 2761.408750]  ffff8806b95054fc ffff880035b34800 00000000ffffffff ffff8806b9505500
[ 2761.408752] Call Trace:
[ 2761.408759]  [<ffffffff81729499>] schedule_preempt_disabled+0x29/0x70
[ 2761.408762]  [<ffffffff8172b305>] __mutex_lock_slowpath+0x135/0x1b0
[ 2761.408765]  [<ffffffff811c903e>] ? lookup_fast+0x14e/0x2c0
[ 2761.408767]  [<ffffffff8172b39f>] mutex_lock+0x1f/0x2f
[ 2761.408770]  [<ffffffff811ca9cd>] do_last+0x2bd/0x1200
[ 2761.408772]  [<ffffffff8131666b>] ? apparmor_file_alloc_security+0x5b/0x180
[ 2761.408776]  [<ffffffff812d8c86>] ? security_file_alloc+0x16/0x20
[ 2761.408779]  [<ffffffff811cde8b>] path_openat+0xbb/0x640
[ 2761.408782]  [<ffffffff8109ac3a>] ? try_to_wake_up+0x1fa/0x2c0
[ 2761.408785]  [<ffffffff811ce4af>] ? getname_flags+0x4f/0x190
[ 2761.408787]  [<ffffffff811cf27a>] do_filp_open+0x3a/0x90
[ 2761.408790]  [<ffffffff811dc0d7>] ? __alloc_fd+0xa7/0x130
[ 2761.408793]  [<ffffffff811bd839>] do_sys_open+0x129/0x280
[ 2761.408795]  [<ffffffff811bd9ae>] SyS_open+0x1e/0x20
[ 2761.408798]  [<ffffffff8173575d>] system_call_fastpath+0x1a/0x1f

root# docker info
Containers: 14
Images: 565
Server Version: 1.9.1
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 593
 Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-74-generic
Operating System: Ubuntu 14.04.2 LTS
CPUs: 16
Total Memory: 29.44 GiB
Name: ...
ID: ...
Username: ...
Registry: https://index.docker.io/v1/
WARNING: No swap limit support

ps auxfg:

9013       4195  0.0  0.0 175808 24012 ?        Ssl  Jan08   0:01  \_ /usr/local/bin/python3.4 /usr/local/bin/flake8 .
9013       4224 99.9  0.0      0     0 ?        Zl   Jan08 1042:10  |   \_ [flake8] <defunct>
9013       4230  0.0  0.0      0     0 ?        Z    Jan08   0:00  |   \_ [flake8] <defunct>
root      14058  0.0  0.0 171780 21960 ?        Ssl  03:33   0:00  \_ /usr/local/bin/python3.5 /usr/local/bin/flake8 .
root      14148 99.9  0.0      0     0 ?        Zl   03:33 639:25      \_ [flake8] <defunct>

Ini telah diperbaiki di AUFS upstream - boot2docker telah diperbarui untuk menyertakan perbaikan (yang akan keluar dengan rilis berikutnya), dan pengguna non-boot2docker yang terpengaruh harus menerapkan rilis AUFS yang diperbarui. : +1:

@ Tianon apakah Anda memiliki referensi tentang bug upstream?

http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/5345 adalah pengumuman rilis upstream - tidak yakin apakah ada diskusi lebih dari itu

http://comments.gmane.org/gmane.linux.file-systems.aufs.user/5337 memiliki lebih banyak latar belakang diskusi untuk masalah ini

Terima kasih!

Ini telah diperbaiki di AUFS upstream - boot2docker telah diperbarui untuk menyertakan perbaikan (yang akan keluar dengan rilis berikutnya), dan pengguna non-boot2docker yang terpengaruh harus menerapkan rilis AUFS yang diperbarui. : +1:

Bagus.

Apakah AUFS versi buggy digunakan di Docker Hub?

@tianon "Terapkan rilis AUFS yang diperbarui" artinya untuk pengguna non-boot2docker (semua orang yang menjalankan mesin buruh pelabuhan _not_ dalam pengembangan di Mac OS X, yang utamanya dibuat untuk b2d) bahwa mereka harus menunggu pembaruan kernel Linux dengan patch AUFS ini ... Atau ... dengan mempertimbangkan berapa banyak instalasi / orang yang tampaknya terpengaruh, dapatkah instruksi yang disederhanakan / minimal diberikan oleh siapa saja tentang cara menambal AUFS ke 4.1.13+? Panduan untuk 4.1.13+ jelas tidak sepele untuk dibaca; menambal kernel linux sendiri untuk perbaikan khusus ini tidak tepat untuk menjadi lemah hati.

Supaya saya mengerti jika saya membuat boot2docker.iso dan memasukkannya ke dalam ~/.docker/machine/cache dan membuat VM baru dengan docker-machine bahwa VM akan menggunakan salinan baru boot2docker .

Supaya saya mengerti jika saya membangun boot2docker.iso ini dan meletakkannya di ~ / .docker / machine / cache dan membuat VM baru dengan mesin-galangan bahwa VM akan menggunakan salinan baru boot2docker ini.

Secara teknis ya, itu akan berhasil, tetapi opsi yang lebih baik mungkin menggunakan --virtualbox-boot2docker-url , misalnya:

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

Ah, oke, terima kasih sudah klarifikasi. Nah, ini sepertinya berhasil.

Mengirim permintaan untuk memperbarui AUFS ke Canonical: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043

Apakah akan ada rilis baru boot2docker, karena 1.9.1 sepertinya tidak memiliki perbaikan di dalamnya?

edit. dengan image boot2docker @AkihiroSuda, saya bisa melanjutkan. Terimakasih semuanya!

Ya, perbaikan ini setelah 1.9.1. @tianon mengatakan rilis telah direncanakan. Biasanya, ini keluar pada saat yang sama docker keluar untuk rilis. Karena mereka cenderung mengikuti siklus 2 minggu pada rilis, saya berharap rilis sudah dekat. Untuk sementara, @AkihiroSuda membuat perbaikan yang bisa Anda gunakan atau Anda buat sendiri, yang sangat mudah, hanya butuh waktu.

Terima kasih @AkihiroSuda untuk gambarnya, berhasil! :)

+1 Debian Wheezy dan Ubuntu 15.04

Rilis @jakirkham adalah siklus 2 bulan, tetapi kami segera merilis 1.10-rc1, boot2docker akan memiliki versi rc1 untuk itu juga.

Oh, maaf, pasti tercampur. Terima kasih telah meluruskan saya, @tiborvass. Apakah Anda mengerti, @shusso?

@jakirkham saya lakukan, terima kasih: +1:

Saya dapat membuat kotak virtual host mesin galangan menggunakan perbaikan ini:

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

Saat ini, host mesin galangan yang saya buat di mesin komputasi google, dengan opsi - driver google, tampaknya mengalami masalah ini. Tidak ada opsi dengan driver google untuk menentukan .iso yang berbeda, jadi saya tidak dapat menggunakan perbaikan di atas pada google compute.

Apakah ada yang tahu solusinya? atau memang jika google mengetahui masalah tersebut, atau di mana saya harus mengajukan laporan bug untuk mereka.

Apakah driver mesin galangan google dipelihara oleh buruh pelabuhan, atau oleh google?

Pengemudi dapat ditemukan di sini; https://github.com/docker/machine/tree/master/drivers/google

Saya pikir gambar VM yang dijalankan di Google Compute harus seperti ini di sini:

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

Itu adalah:

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

Memindai melalui hal-hal di atas, solusi potensial sepertinya adalah yang disarankan oleh @nathanleclaire

$ docker-machine buat -d hamparan overlay google --engine-storage-driver

Tampaknya juga ada opsi "--google-machine-image" yang tersedia untuk driver google untuk docker-machine. Perintah:

$ gcloud compute images list

Mencantumkan gambar publik yang tersedia. Saya perhatikan bahwa ubuntu baru dengan cerdik baru-baru ini telah dipasang.

Hanya mengkonfirmasi:

$ docker-machine buat -d hamparan overlay google --engine-storage-driver

Bekerja. Saya juga akan menyelidiki pembuatan image mesin kustom menggunakan boot2docker tetap, dan mencoba menghubungkannya dengan docker-machine.

Kepada siapa pun yang melakukan ini di boot2docker, berikan RC di
https://github.com/tianon/boot2docker-legacy/releases/tag/v1.10.0-rc1 a
tembakan. : +1:

@tianon saya mengujinya dengan gambar trecloux / docker-java-zombie berikut
Dan itu terlihat bagus .... tapi masih tergantung dengan gambar akihirosuda / test18180

Kerja yang sangat mengesankan @AkihiroSuda Kamu salah satu bug zapper yang gigih !!

@trecloux Apakah Anda menggunakan btrfs dan mulai menunggu untuk sendfile?
Jika demikian, ini adalah masalah yang diketahui: https://github.com/docker/docker/issues/19073

@AkihiroSuda Saya menggunakan image boot2docker v1.10.0-rc1 dengan aufs:

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

Berikut adalah keluaran dari gambar uji Anda:

$ 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 Ini perilaku yang diharapkan. Tidak ada yang menutup telepon.

@AkihiroSuda Ok, maaf. Dan terima kasih atas usaha Anda :-)
Jadi @tianon : 1.10.0-rc1 terlihat bagus.

Masalah yang sama disini. Bertahan saat menyiapkan sertifikat-ca, CPU menjadi kacau ...

$ 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

menjalankan MacOSX 10.11.2

@sgoendoer coba gunakan gambar @AkihiroSuda dengan docker-machine create --driver virtualbox --virtualbox-boot2docker-url="file:/path_to_the_image" nameofmachine

untuk pengguna non boot2docker, tahu versi kernel mana ini akan diperbaiki? 3.13.0-71 sepertinya berfungsi, 3.13.0-74 dan 3.13.0-76 sepertinya rusak ...

Masalah yang sama di sini; Jadi tidak ada perbaikan yang mudah untuk ini?
Apakah ini diperbaiki dalam versi RC? Mencoba yang itu sekarang. Meskipun itu mungkin menyebabkan masalah lain.

SOLUSI CEPAT TERBARU (Pembaruan: 21 Jan 15:33 UTC)

| Distro | Solusi |
| --- | --- |
| Umum | Gunakan devicemapper / overlay / btrfs (tetapi ini dapat menyebabkan masalah lain ..) |
| Boot2Docker | : white_check_mark: Tingkatkan ke v1.10.0-rc1 |
| Ubuntu 14.04LTS | : arrow_down: Downgrade kernel ke 3.13.0-71 atau lebih lama |
| Ubuntu 15.04 | : arrow_down: Downgrade kernel ke 3.19.0-39 atau yang lebih lama (: peringatan: tidak diuji) |
| Ubuntu 15.10 | : arrow_down: Downgrade kernel ke 4.2.0-18 atau lebih lama |
| Debian 7/8 | : arrow_down: Downgrade kernel ke versi 3.16.7-ckt11 dari rilis 3.16.0 ( apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 ) atau lebih lama |
| Debian 9 | : white_check_mark: (tidak mendukung AUFS sejak kernel 3.18-1 ~ exp1) |
| Gentoo | : white_check_mark: Tingkatkan ke yang terbaru (: peringatan: tidak diuji) |
| RHEL / CentOS | : white_check_mark: (tidak mendukung AUFS) |
| openSUSE | : white_check_mark: (tidak mendukung AUFS) |

Distributor Terbitkan Tiket

| Distro | Status | Masalah URL |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: Ditutup | https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | : white_medium_square: Sedang Berlangsung | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | Belum dikonfirmasi | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

@AkihiroSuda v1.10.0-rc1 tidak memperbaiki zombie untuk saya, siapa juga yang mendapat masalah?

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)   

Setelah memulai proses yang mati setelah beberapa waktu ini muncul, tetapi setelah ini zombie masih ada:

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>

Kali ini tidak dapat diakses melalui strace lagi, saya kira masih terpasang meskipun tidak.
: ~ # strace -p 23810

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

@tokopedia
Bisakah Anda mendapatkan tumpukan LWP seperti di https://github.com/docker/docker/issues/18180#issuecomment -166186061?
juga, apa cmdline dan versi phantomjs Anda?

Oke, versi 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

Dan juga tumpukan tugas:

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

Juga untuk menambahkan informasi Sistem:

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 Apakah Anda menggunakan Docker (bukan Boot2Docker) v1.10.0-rc1 di Debian?
Itu tidak berfungsi karena masalahnya adalah bug kernel daripada Docker.

Saya mencari kernel Debian dan saya akan memperbarui daftar https://github.com/docker/docker/issues/18180#issuecomment -173436661.

@AkihiroSuda y langsung di debian. Saya telah mengawasi poin debian di daftar Anda, terima kasih telah menunjukkan :)

Untuk debian, kita sebaiknya tidak menggunakan kernel berbasis 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 Saya memperbarui daftar, harap gunakan kernel ckt11.

@AkihiroSuda : FWIW, saya yakin rekomendasi untuk menurunkan versi ke v3.16.7-ckt11 menempatkan Anda pada risiko CVE-2016-0728, yang memiliki eskalasi root publik yang diketahui. Saya baru saja melakukan ping ke https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 , tetapi FYI sebelum Anda menurunkan versi.

@zmerlynn Terima kasih telah menunjukkannya!

SOLUSI CEPAT TERBARU (Pembaruan: 26 Jan 1:49 UTC)

| Distro | Solusi |
| --- | --- |
| Umum | Gunakan devicemapper / overlay / btrfs (tetapi ini dapat menyebabkan masalah lain ..).
Jika Anda dapat memutakhirkan AUFS dan membangun kernel secara manual, Anda juga dapat menggunakan AUFS v20160111 atau yang lebih baru. |
| Boot2Docker | : white_check_mark: Tingkatkan ke v1.10.0-rc1 |
| Ubuntu 14.04LTS | : arrow_down: Downgrade kernel ke 3.13.0-71 atau lebih lama |
| Ubuntu 15.04 | : arrow_down: Downgrade kernel ke 3.19.0-39 atau yang lebih lama (: peringatan: tidak diuji) |
| Ubuntu 15.10 | : arrow_down: Downgrade kernel ke 4.2.0-18 atau lebih lama |
| Debian 7/8 | : arrow_down: Downgrade kernel ke versi 3.16.7-ckt11 dari rilis 3.16.0 ( apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 ) atau lebih lama |
| Debian 9 | : white_check_mark: (tidak mendukung AUFS sejak kernel 3.18-1 ~ exp1) |
| Gentoo | : white_check_mark: Tingkatkan ke yang terbaru (: peringatan: tidak diuji) |
| RHEL / CentOS | : white_check_mark: (tidak mendukung AUFS) |
| openSUSE | : white_check_mark: (tidak mendukung AUFS) |

: peringatan: Menurunkan kernel bisa menjadi risiko keamanan (misalnya, CVE-2016-0728)

Distributor Terbitkan Tiket

| Distro | Status | Masalah URL |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: Ditutup | https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | : white_medium_square: Sedang Berlangsung | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | : white_medium_square: Sedang Berlangsung | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

Kami juga menemui masalah ini, mongod terjebak dalam status R yang berjalan dengan 100% CPU.

Inilah trik sebenarnya untuk mendapatkan pelacakan tumpukan yang benar yang membawa saya ke sini:

echo "l"> / proc / sysrq-trigger

dari sana, Anda dapat melihat CPU 2 terjebak dalam loop inifinity oleh 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

mencari dengan do_xino_fwrite membawa saya ke sini!

Saya tampaknya mengalami masalah ini juga di Debian Stretch di mana hal itu tergantung pada pengaturan sertifikat.

Berikut pesan kesalahannya: https://gist.github.com/clball/738feb46094802a1bcf7
Berikut info versinya: https://gist.github.com/clball/494fe8598dd0cdfd6d10
Inilah dockerfile: https://gist.github.com/8778f8db143478d6c8ab

Jadi apa solusi untuk OSX disini, apakah sudah ada update docker?

Belum, tapi sudah ada calon rilis. (https://github.com/tianon/boot2docker-legacy/releases/tag/v1.10.0-rc2)

Solusi bagi saya adalah mengubah backend penyimpanan.

Tambahkan baris ke / etc / default / docker
¡¡HATI-HATI Anda akan kehilangan data container Anda !!

DOCKER_OPTS="--storage-driver=devicemapper"

Saya merekomendasikan hentikan layanan buruh pelabuhan, hapus folder buruh pelabuhan di / var / lib dan kemudian tambahkan baris dan mulai ulang layanan buruh pelabuhan.

@ referup-tarantegui hanya sebagai pendahuluan, driver devicemapper dianggap sangat buruk untuk kinerja kecuali dipasang langsung ke disk fisik yang sebenarnya. Lihat
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
dan
https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/ "Kinerja Device Mapper dan Docker"

Ada versi B untuk kandidat rilis2

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

Memperbarui tabel tentang Ubuntu.

SOLUSI CEPAT TERBARU (Pembaruan: 3 Feb 6:30 UTC)

| Distro | Solusi |
| --- | --- |
| Umum | Gunakan devicemapper / overlay / btrfs (tetapi ini dapat menyebabkan masalah lain ..).
Jika Anda dapat memutakhirkan AUFS dan membangun kernel secara manual, Anda juga dapat menggunakan AUFS v20160111 atau yang lebih baru. |
| Boot2Docker | : white_check_mark: Tingkatkan ke v1.10.0-rc3 |
| Ubuntu 14.04LTS | : white_check_mark: Tingkatkan kernel ke 3.13.0-77.121hf1533043v20160201b1 (PPA) |
| Ubuntu 15.04 | : white_check_mark: Tingkatkan kernel ke 3.19.0-49.55hf1533043v20160201b1 (PPA) |
| Ubuntu 15.10 | : white_check_mark: Tingkatkan kernel ke 4.2.0-27.32hf1533043v20160201b1 (PPA) |
| Debian 7/8 | : arrow_down: Downgrade kernel ke versi 3.16.7-ckt11 dari rilis 3.16.0 ( apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 ) atau lebih lama |
| Debian 9 | : white_check_mark: (tidak mendukung AUFS sejak kernel 3.18-1 ~ exp1) |
| Gentoo | : white_check_mark: Tingkatkan ke yang terbaru (: peringatan: tidak diuji) |
| RHEL / CentOS | : white_check_mark: (tidak mendukung AUFS) |
| openSUSE | : white_check_mark: (tidak mendukung AUFS) |

Distributor Terbitkan Tiket

| Distro | Status | Masalah URL |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: Ditutup | https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | : white_medium_square: Sedang Berlangsung (ETA: 20 Feb) | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | : white_medium_square: Sedang Berlangsung | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

@AkihiroSuda , saya pikir yang Anda maksud adalah v1.10.0-rc2 untuk boot2docker atau mungkin tautannya seharusnya masuk ke sini (https://github.com/boot2docker/boot2docker/releases/tag/v1.10.0-rc3).

@jakirkham Terima kasih, sudah perbaiki linknya.

rc3 ada di repo resmi, bukan di fork saya:
https://github.com/boot2docker/boot2docker/releases/tag/v1.10.0-rc3

Kami menyelidiki utang teknologi yang memaksa kami menggunakan garpu saya dan menemukan itu
itu telah diperbaiki sejak galangan-mesin 0,5, jadi kami bergerak maju dan
ke atas. :tersenyum:

btw, bagi mereka yang ingin mengganti kernel ke versi yang ditambal chiluk yang tercantum di atas untuk PPA Ubuntu. Misalnya, untuk Ubuntu 14.04, linux-image-3.13.0-77-generic , langkah Anda adalah:

$ 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

Kemudian Anda harus memperbarui konfigurasi /etc/default/grub , kemudian menjalankan sudo update-grub , lalu reboot ke dalam pembuatan kernel baru yang telah ditambal. Jika Anda belum pernah melakukan ini sebelumnya, berikut adalah panduan tentang cara menyetel kernel default yang berbeda di grub .

Saya dapat mengonfirmasi bahwa masalah ini tidak ada di Docker 1.10.0, yang memperbaiki situasi saya di OS X 10.11 juga. Jika tidak, saya akan menurunkan versi ke 1.9.0.

Saya masih mendapatkan masalah java kontainer / proses digantung pada buruh pelabuhan 1.10:

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

@AkihiroSuda Saya mencoba Solusi Cepat Anda (terima kasih!) Tetapi saya tidak dapat menginstal kernel lama di server Debian 8 (jessie) saya, saya mendapatkan:

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

Ketika saya mencoba saran @mikeatlas (btw harus sudo apt-get install software-properties-common untuk mendapatkan sudo add-apt-repository ppa:chiluk/1533043 untuk bekerja) Saya mendapatkan pembaruan gagal, yang menurut saya mengapa penginstalan tidak berfungsi

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

Info buruh pelabuhan saya:

$ 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 terima kasih atas tip tentang membutuhkan software-properties-common , saya memperbarui posting saya di atas.

@jamshid : Setelah Anda menambahkan PPA dan melakukan apt-get update , periksa dan lihat kernel apa yang tersedia untuk mesin Anda ... Sepertinya ada versi yang lebih baru ( 3.13.0-78 ) tetapi saya tidak melihat itu tersedia setelah menjalankan pembaruan sendiri di sini. Namun, inilah cara Anda _dapat_ mengetahui kernel apa yang tersedia untuk dipasang:

$ 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

Jika Anda tidak melihat sesuatu di sepanjang baris linux-image-3.13.0-77-generic atau lebih tinggi, pasti ada hal lain yang salah.

Oh, @jamshid Anda menjalankan Debian 8? Catatan di atas: Downgrade kernel to version 3.16.7-ckt11 of release 3.16.0 (apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3) or older

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

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

Satu jam googlening aktif untuk menemukan paket ckt11 tidak membantu.
Tolong, ada saran bagaimana cara downgrade kernel Debian 8 terbaru?

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 Anda dapat menemukan paket yang diinstal sebelumnya di /var/cache/apt/archives . Anda seharusnya dapat menurunkan versi dengan dpkg -i <old_package>.deb .

Dikonfirmasi bahwa menginstal kernel baru dari PPA telah memperbaiki masalah saya (Ubuntu 14.04.3 / Kernel 3.13.0-78-generic / Docker 1.9.1)
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043

Adakah yang mendapatkan instruksi penurunan versi untuk bekerja dengan Debian (bukan Ubuntu)? Saya bertanya-tanya apakah alasan apt-get update gagal dengan kesalahan di bawah ini (setelah menambahkan repo ppa):

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

apakah hanya paket ubuntu yang tersedia di https://launchpad.net/~chiluk/+archive/ubuntu/1533043? Hmm saya bingung, saya pikir Ubuntu berbasis Debian.

@jamshid Ubuntu ppa tidak mendukung Debian.

Jika 3.16.7-ckt11-1 + deb8u3 sayangnya tidak lagi tersedia, Anda dapat menambal kernel terbaru: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207#47

(Saya dapat mengunggah paket deb, jika seseorang membutuhkannya)

Jika seseorang membutuhkan kernel, saya telah mengunggahnya di sini, ini sedikit lebih baru dari deb8u3, tetapi sepertinya kernel tidak memiliki bug, setidaknya saya tidak menemukannya menjalankan ini cukup lama, tetapi menambal kernel terbaru mungkin merupakan solusi yang lebih baik. Namun jika Anda membutuhkannya:
https://wizardtales.com/linux-image-3.16.0-0.bpo.4-amd64_3.16.7-ckt11-1+deb8u6~bpo70+1_amd64.deb

@wzrdtales : +1:

Bagi mereka seperti saya yang masih berjuang untuk menyelesaikannya, saya ingin menunjukkan kepada Anda TINI sebagai solusi yang bagus:
https://github.com/krallin/tini

dengan beberapa baris di dockerfile saya mendapat proses init yang layak yang mampu menghapus zombie.
Ini akan memungkinkan untuk menghindari transisi ke devicemapper.

Bersulang,
Francesco

Jadi, saya menggunakan tini. Namun, itu tidak membantu saya di sini karena masalah yang saya temui adalah ketika gambar sedang dibuat.

Juga, saat menjalankan wadah, saya menggunakan tini, tetapi ini masih memengaruhi saya.

@tokopedia
Terima kasih atas informasinya, tetapi masalah zombie yang dapat diselesaikan oleh tini tampaknya berbeda dari masalah ini.
https://github.com/docker/docker/issues/18180#issuecomment -167042078

Sebenarnya dengan tini pun kita bisa mendapatkan zombie:

FROM java:7
ENV TINI_VERSION v0.9.0
ADD https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini /tini
RUN chmod +x /tini
ENTRYPOINT ["/tini", "--"]
CMD ["taskset", "0x1", "java"]

$ docker build -t foobar .
$ docker run -it --rm foobar
Usage: java [-options] class [args...]
           (to execute a class)
...
See http://www.oracle.com/technetwork/java/javase/documentation/index.html for more details.
(hangs up here and becomes a zombie)

@AkihiroSuda @jakirkham Saya lupa menyebutkan bahwa kami tidak mengalami masalah ini saat membuat gambar. Kami membuat gambar yang sangat dasar dan kemudian logika penyediaan didelegasikan ke sekumpulan skrip yang memungkinkan. Selama pemberian, salah satu proses (kafka) digunakan untuk menggantung. TINI sejauh ini tampaknya telah meringankan masalah itu.
Saya akui ini mungkin bukan solusi untuk Anda, memang saya menyarankan untuk menurunkannya dari solusi ke plasebo :)
Semoga kita bisa segera disortir.

Saya memiliki masalah yang sama menjalankan Docker 1.9.1 di OSX 10.11.3:

$ docker -v
Docker version 1.9.1, build a34a1d5

Mengupgrade ke rilis Docker Toolbox terbaru diperbaiki:

$ docker -v
Docker version 1.10.1, build 9e83765

Untuk informasi, saya membuat daftar beberapa masalah dan solusi yang terkait dengan AUFS / Overlay / BtrFS / ZFS / devicemapper driver penyimpanan: https://github.com/AkihiroSuda/docker-issues/

Semoga ini bisa membantu mereka yang tertarik dengan # 18180 dan lainnya ..

@AkihiroSuda Saya mencoba mengikuti tautan https://launchpad.net/%7Echiluk/+archive/ubuntu/1533043/+packages tetapi saya tidak diizinkan untuk melihat halaman.

Lihat juga: https://github.com/docker/toolbox/issues/318#issuecomment -184143546

@ rizky_dwi
Saya juga tidak dapat mengakses halaman.
Saya pikir chiluk sedang membuat ulang paket. Anda dapat bertanya kepadanya di https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043

Untuk orang-orang yang mengalami masalah dengan ini, berikut ini cara menyelesaikan masalah di Ubuntu 14.04 menggunakan kernel yang diusulkan . Ini tentu saja tidak akan relevan setelah kernel berpindah ke cabang utama.

Sebelum memulai, kami dapat mengonfirmasi bahwa kami menjalankan kernel yang terpengaruh dengan menjalankan (yaitu <3.19.0-50 di Ubuntu 14.04):

$ uname -r
3.19.0-49-generic

Karena kita tahu, ini, pertama-tama kita perlu Mengaktifkan paket yang

$ 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

Setelah itu selesai, mari instal kernel yang diperbarui:

$ 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

Dan mari kita reboot

$ sudo shutdown -r now

Setelah reboot, kami dapat mengonfirmasi bahwa yang terbaru sekarang berjalan di kernel terbaru:

$ uname -r
3.19.0-50-generic

Terima kasih @vpetersson saya mencoba untuk mencari tahu apa yang akan terjadi ketika versi kernel ini dirilis, apakah itu hanya akan menimpa instalasi yang diusulkan atau apakah Anda harus melakukan sesuatu untuk kembali normal?

@IainColledge Ya, menurut saya memang begitu, tapi saya tidak sepenuhnya yakin.

Memperbarui tabel tentang Ubuntu dan Debian.

SOLUSI CEPAT TERBARU

| Distro | Solusi |
| --- | --- |
| Umum | Gunakan devicemapper / overlay / btrfs (tetapi ini dapat menyebabkan masalah lain ..).
Jika Anda dapat memutakhirkan AUFS dan membangun kernel secara manual, Anda juga dapat menggunakan AUFS v20160111 atau yang lebih baru. |
| Boot2Docker | : white_check_mark: Tingkatkan ke v1.10.0 atau lebih baru |
| Ubuntu 14.04LTS | : white_check_mark: Upgrade kernel ke 3.13.0-79.123 atau lebih baru |
| Ubuntu 15.04 | : white_check_mark: Upgrade kernel ke 3.19.0-51.57 atau lebih baru |
| Ubuntu 15.10 | : white_check_mark: Upgrade kernel ke 4.2.0-30.35 atau lebih baru |
| Debian 7/8 | : arrow_down: Downgrade kernel ke versi 3.16.7-ckt11 dari rilis 3.16.0 atau yang lebih lama ( arsip dpkg oleh @wzrdtales) |
| Debian 9 | : white_check_mark: (tidak mendukung AUFS sejak kernel 3.18-1 ~ exp1) |
| Gentoo | : white_check_mark: Tingkatkan ke yang terbaru (: peringatan: tidak diuji) |
| RHEL / CentOS | : white_check_mark: (tidak mendukung AUFS) |
| openSUSE | : white_check_mark: (tidak mendukung AUFS) |

Distributor Terbitkan Tiket

| Distro | Status | Masalah URL |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: Ditutup | https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | : white_check_mark: Ditutup | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | : white_medium_square: Sedang Berlangsung | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

Satu hal lagi; Saya membuat daftar beberapa bug yang diketahui tentang driver penyimpanan: https://github.com/AkihiroSuda/docker-issues

Untuk berjaga-jaga jika seseorang ingin memiliki kernel debian "linux_3.16.7-ckt20-1 + deb8u3" terbaru dengan tambalan, yang disebutkan sebelumnya - Saya telah membuatnya secara manual, dan ada di https://fxposter.org/linux-image-3.16 .0-4-amd64_3.16.7-ckt20-1 + deb8u3a ~ test_amd64.deb.

luar biasa! Saya telah mengalami masalah ini selama beberapa minggu sekarang, dan saya kira perbaikan untuk Ubuntu baru saja dirilis kemarin: P.

Mengkonfirmasi bahwa pembaruan kernel 14.04LTS terbaru ke 3.19.0-51 mengakhiri zombie java saya. Terima kasih!

Debian mendukung masalah ini.

SOLUSI CEPAT TERBARU

| Distro | Solusi |
| --- | --- |
| Umum | Gunakan devicemapper / overlay / btrfs (tetapi ini dapat menyebabkan masalah lain ..).
Jika Anda dapat memutakhirkan AUFS dan membangun kernel secara manual, Anda juga dapat menggunakan AUFS v20160111 atau yang lebih baru. |
| Boot2Docker | : white_check_mark: Tingkatkan ke v1.10.0 atau lebih baru |
| Ubuntu 14.04LTS | : white_check_mark: Upgrade kernel ke 3.13.0-79.123 atau lebih baru |
| Ubuntu 15.04 | : white_check_mark: Upgrade kernel ke 3.19.0-51.57 atau lebih baru |
| Ubuntu 15.10 | : white_check_mark: Upgrade kernel ke 4.2.0-30.35 atau lebih baru |
| Debian 7 | : white_check_mark: Upgrade kernel ke 3.2.73-2 + deb7u3 (dari paket linux-image-3.2.0-4-amd64) atau yang lebih baru |
| Debian 8 | : white_check_mark: Upgrade kernel ke 3.16.7-ckt20-1 + deb8u4 (dari paket linux-image-3.16.0-4-amd64) atau yang lebih baru |
| Debian 9 | : white_check_mark: (tidak mendukung AUFS sejak kernel 3.18-1 ~ exp1) |
| Gentoo | : white_check_mark: Tingkatkan ke yang terbaru (: peringatan: tidak diuji) |
| RHEL / CentOS | : white_check_mark: (tidak mendukung AUFS) |
| openSUSE | : white_check_mark: (tidak mendukung AUFS) |

Distributor Terbitkan Tiket

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

memutakhirkan kernel 14.04LTS berhasil untuk saya: +1:

Saya menggunakan OSX pada Boot2Docker versi 1.10.2, build master: 611be10, Docker versi 1.10.2, build c3959b1 dan pertama kali mendapatkannya dari 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).

Kemudian mencoba docker kill 38e1e2590dfa tetapi proses macet selamanya. 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"

Hanya sebagai catatan (saya tahu ini ditutup tetapi tidak yakin apakah masuk akal untuk membuka sebagai terbitan baru). Saya mengalami masalah yang sama pada versi yang lebih baru sampai saya beralih ke 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 Masalah telah diperbaiki di kernel 3.13.0-79.123 (yang Anda tampaknya 3.13.0-77)

Dapatkah masalah ini benar-benar diselesaikan dengan peningkatan Kernel? Kami mengalami masalah yang sama dengan Docker 1.9.1 di Ubuntu 14.04 dengan Kernel 3.13.0-83-generic.

Client:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   a34a1d5
 Built:        Fri Nov 20 13:12:04 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   a34a1d5
 Built:        Fri Nov 20 13:12:04 UTC 2015
 OS/Arch:      linux/amd64

@ martinm82 ya, masalah ini adalah masalah kernel. Mungkin saja hal lain dapat mengakibatkan perilaku serupa, atau jika ada regresi di kernel. Namun, silakan buka masalah baru jika Anda mengalami masalah pada rilis saat ini; perlu diingat bahwa buruh pelabuhan 1.9.1 adalah EOL, jadi tidak akan menerima pembaruan lagi.

Saya mengunci diskusi tentang masalah ini, karena masalah asli di sini telah diselesaikan, dan saya ingin mencegah masalah ini mengumpulkan masalah yang mungkin tidak terkait. Lihat komentar ini; https://github.com/docker/docker/issues/18180#issuecomment -193708192 untuk versi kernel yang diperlukan untuk memperbaiki masalah ini