У меня такая же проблема. Я расследую.

Мы сталкиваемся с той же проблемой.

Да, это проблема в докере 1.9. Я перешел на 1.8.3, и все проблемы решены. Теперь я исследую обходной путь. выложу здесь! Tks

У меня такая же проблема с докером 1.9.1a

У меня есть докер 1.8.3, так что, возможно, установка другой версии докера исправит ситуацию. @bsao.

имея ту же проблему с докером версии 1.9.1, создайте a34a1d5

Вы видите это только на boot2docker?

Я не могу выполнить репо на стандартной Ubuntu с aufs или на своей машине. позвольте мне попробовать с помощью boot2docker, чтобы посмотреть, смогу ли я там сделать репо.

+1 в Docker 1.9.1 для ubuntu: 14.10 с использованием OSX

Это проблема, которая начала появляться после того, как я включил VPN для работы. Даже после того, как я отключил VPN и перезапустил докер-машину на OSX, эта проблема продолжалась. Я переустановил Docker 1.9.1, а затем 1.8.3, но проблема не исчезла. Запрещает мне использовать большинство, если не все мои докеры на Mac.

+1 в Docker 1.9.1 для ubuntu 12.04 с использованием OS X 10.11

Разработчики в моем офисе тоже случайно столкнулись с этим.

Эта версия / сборка работала : Docker версии 1.9.0, сборка 76d6bc9

Эта версия / сборка зависла : Docker версии 1.9.1, сборка a34a1d5

@crosbymichael Я, к сожалению, не пробовал его ни в какой другой среде, кроме Boot2Docker.

Кто-то с ноу-хау git-bisecting и docker может использовать идентификаторы сборки, предоставленные @ chico1198!

У меня возникла такая же проблема с 1.9.1 на OSX El Capitan, переход на 1.9.0 не помог.

Такая же проблема здесь в OSX 10.9.3 с:
Докер версии 1.9.1, сборка a34a1d5
Докер версии 1.9.0, сборка 76d6bc9

@crosbymichael Я ps auxf , вот что я увидел:

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

+1 с докером 1.9.1 на OSX 10.11 с попыткой собрать образ из ubuntu 14.04

+1
используйте DockerToolbox-1.9.1a.pkg

docker version                                                                                      2 master?
Client:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.3
 Git commit:   a34a1d5
 Built:        Fri Nov 20 17:56:04 UTC 2015
 OS/Arch:      darwin/amd64

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

Переход на Docker 1.8.3 - это мое временное решение. Вот target я использую в своем Makefile .

downgrade-docker:
  docker-machine ssh $(DOCKER_MACHINE_NAME) sudo /etc/init.d/docker stop
  docker-machine ssh $(DOCKER_MACHINE_NAME) "while sudo /etc/init.d/docker status ; do sleep 1; done"
  docker-machine ssh $(DOCKER_MACHINE_NAME) "sudo curl 'https://get.docker.com/builds/Linux/x86_64/docker-1.8.3' -o /usr/local/bin/docker-1.8.3"
  docker-machine ssh $(DOCKER_MACHINE_NAME) "sudo ln -sf /usr/local/bin/docker-1.8.3 /usr/local/bin/docker"
  # FIXME: Starting machine is not enough; always fails with message like "Need TLS certs for 127.0.0.1,10.0.2.15,192.168.99.100"
  #docker-machine ssh $(DOCKER_MACHINE_NAME) sudo /etc/init.d/docker start
  docker-machine stop $(DOCKER_MACHINE_NAME) 
  docker-machine start $(DOCKER_MACHINE_NAME) 

Я не мог воспроизвести это. Всегда ли зависает на "настройке сертификатов"? Вы пытались отправить ^D чтобы закрыть какой-то канал? Можете ли вы также попробовать отправить демону SIGUSR1 и вставить сюда трассировку стека, если он завис?

+1 с докером 1.9.1 на OS X 10.10

Я попытался перейти на версию 1.8.3, используя Makefile

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

Протестировал, выполнив различные установки openjdk внутри debian: jessie и ubuntu
OSX 10.11.1, boot2docker 1.9.1: зависает
OSX 10.11.1, boot2docker 1.9.0: работает
Ubuntu 14.04 с докером 1.9.1: работает

Виртуальные машины boot2docker были созданы с помощью:
docker-machine создать -d virtualbox --virtualbox-boot2docker-url = https://github.com/boot2docker/boot2docker/releases/download/v1.9.0/boot2docker.iso
и
docker-machine создать -d virtualbox --virtualbox-boot2docker-url = https://github.com/boot2docker/boot2docker/releases/download/v1.9.1/boot2docker.iso

В Ubuntu 14.04 докер был установлен в соответствии с документацией на https://docs.docker.com/engine/installation/ubuntulinux/

+1, запущен docker 1.9.1 build a34a1d5 на OSX Yosemite 10.10.5.

Я не могу воспроизвести это.

Здесь та же проблема.
Есть ли способ перейти на более раннюю версию Windows?

Нашел сам.
https://github.com/docker/docker/releases

+1, докер 1.9.1 @ Эль Капитан

+1, Docker 1.9.1 в OS X 10.11.1

+1, Докер 1.9.1a, OS X 10.10.5

+1, Docker 1.9.1 сборка a34a1d5, Windows 10

+1, Docker 1.9.1, сборка a34a1d5, OS X 10.11.1, Docker-Machine 0.5.1, сборка 7e8e38e

+1

То же самое на Docker-машине на OSX 10.11.1
Докер версии 1.9.1, сборка a34a1d5
docker-machine версия 0.5.1 (HEAD)

Я могу воспроизвести это на докер-машине, OS X 10.10.5, так что это может быть связано с boot2docker. docker top также дает мне <defunct> для процесса Java;

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

/ cc @tianon @nathanleclaire @jeffdm возможно, у кого-то из вас есть идея, где искать или что отлаживать, я действительно ничего не нашел

Сколько оперативной памяти у вашей виртуальной машины? Может быть OOM, учитывая, что это похоже на
процесс неожиданно умирает. :расстроен:

Похоже, проблема не в памяти, однако процесс <defunct> потребляет 100% ЦП;

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

Контейнер, похоже, тоже застрял, и мне пришлось перезагрузить виртуальную машину, чтобы ее убить

+1 Докер версии 1.9.1, сборка a34a1d5, Win 7.

Я столкнулся с аналогичными проблемами, которые оказались OOM, хотя команда stats показывает доступную для контейнера память. Проблема возникла вскоре после того, как диспетчер задач показал 0 свободной физической памяти, в то время как статистика продолжала показывать <100%.

Странно то, что процесс продолжал работать, поэтому его не убили. Я могу повторить попытку с помощью -m, однако странно, что это происходит на 1.9.x, но (после этого обсуждения) не на 1.8. Кроме того, удалось запустить то же самое на капле DigitalOcean объемом 1 ГБ (также 1.9.1). Возможно, тот, кто использует своп, должен проверить, что

На самом деле это продолжалось со мной после того, как я удалил 1.9.1 и установил 1.8.3. Похоже, что удаление было не очень тщательным, хотя на Mac, потому что запуск оболочки происходил без задержки в 1.8.3, в отличие от обычного первого запуска, когда он устанавливает ключи ssh и прочее.

_ПОЛЬЗОВАТЕЛЬСКИЙ ОПРОС_

_Лучший способ получать уведомления об изменениях в этом обсуждении - это нажать кнопку «Подписаться» в правом верхнем углу. _

Перечисленные ниже люди оценили ваше содержательное обсуждение случайным +1:

@mattes

31 участник по этому вопросу, и их количество продолжает расти.

@ bean5, пожалуйста,

@thaJeztah Я не хотел обидеть или разрушить. Я хочу привлечь внимание к тому факту, что github показывает количество участников ... и я понял, что @GordonTheTurtle хотел составить список людей, которые сделали +1. Может быть, меня смутило то, что он имел в виду. В любом случае я с нетерпением наблюдаю за этой проблемой, поскольку за последние недели она неоднократно затрагивала меня. Я рад, что у нас есть информация от разных пользователей.

Я могу продублировать эту проблему в своей настройке (используя Docker Machine на Mac).

Вот мои выводы.

Как отмечали другие авторы, самый простой способ скопировать это - использовать ISO-образ boot2docker 1.9.1 с AUFS. Этот Dockerfile должен минимально воспроизвести проблему довольно быстро:

FROM debian:jessie

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

Глядя на dmesg , я вижу некоторые ошибки AUFS после попытки такой сборки, но я не уверен на 100%, что они связаны:

docker<strong i="13">@default</strong>:~$ dmesg | tail
aufs au_opts_verify:1597:docker[14186]: dirperm1 breaks the protection by the permission bits on the lower branch
aufs au_opts_verify:1597:docker[14186]: dirperm1 breaks the protection by the permission bits on the lower branch
aufs au_opts_verify:1597:docker[14186]: dirperm1 breaks the protection by the permission bits on the lower branch
device veth955cc15 entered promiscuous mode
IPv6: ADDRCONF(NETDEV_UP): veth955cc15: link is not ready
eth0: renamed from vethc63e038
IPv6: ADDRCONF(NETDEV_CHANGE): veth955cc15: link becomes ready
docker0: port 2(veth955cc15) entered forwarding state
docker0: port 2(veth955cc15) entered forwarding state
docker0: port 2(veth955cc15) entered forwarding state

Если я создам машину Docker 1.9.1, которая использует overlay в качестве драйвера хранилища:

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

Процесс НЕ зависает, и эта строка успешно выполняется! Похоже, проблема в AUFS и / или ядре.

boot2docker / boot2docker _did_ bump обе версии ядра и фиксация AUFS для выпуска 1.9.1, так что это оба фактора, которые необходимо исключить или изучить дополнительно:

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

В настоящее время пробует 1.9.0 ISO с двоичным файлом 1.9.1, чтобы увидеть, можно ли еще уменьшить площадь потенциальной области ошибки.

Dockerfile будет нормально собираться и не зависает на ISO-образе boot2docker 1.9.0 с двоичным файлом Docker 1.9.1. Проблема, похоже, не в Docker 1.9.1, а в среде, в которой он выполняется.

Я использую версию 1.9.1 без проблем с aufs, но у меня значительно больше ЦП / ОЗУ / хранилища, чем в конфигурации машины по умолчанию.

Я просто попытался увеличить объем памяти для моей виртуальной машины до 4 ГБ, но все еще могу воспроизвести

@ cpuguy83 AUFS на boot2docker 1.9.1?

Как отмечалось выше, b2d связывает очень специфическую версию AUFS.

Ага

Containers: 13
Images: 191
Server Version: 1.9.1
Storage Driver: aufs
 Root Dir: /mnt/sda1/var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 221
 Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.1.13-boot2docker
Operating System: Boot2Docker 1.9.1 (TCL 6.4.1); master : cef800b - Fri Nov 20 19:33:59 UTC 2015
CPUs: 1
Total Memory: 3.859 GiB
Name: default
ID: XMQH:4YAW:ZDSA:OWC7:GAPC:US5P:YQ4M:SVMQ:VXNL:RRZC:YNHT:ZBHE
Debug mode (server): true
 File Descriptors: 12
 Goroutines: 19
 System Time: 2015-12-01T23:05:28.760107918Z
 EventsListeners: 0
 Init SHA1:
 Init Path: /usr/local/bin/docker
 Docker Root Dir: /mnt/sda1/var/lib/docker
Labels:
 provider=virtualbox

Я также вижу, что некоторые процессы Java перестают функционировать в контейнере. Я могу воспроизвести эту проблему, выполнив следующие действия.
запустить контейнер:

docker run --rm -it myJavaContainerFromCentos7 bash

создайте Foo.java со следующим:

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

скомпилировать и запустить это приведет к несуществующему процессу java с 1 ядром, использующим 100% процессор:
javac Foo.java && java Foo

однако ... если после println добавляется System.exit(0); все в порядке:

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

информация о версии:
osx 10.10.3
докер 1.9.1
boot2docker версии 1.9.1 uname -a это «linux ci 4.1.13-boot2docker»
numproc = 1

вывод strace с помощью System.exit (0);

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

вывод strace _without_ System.exit (0);

open("/usr/java/jdk1.7.0_75/jre/lib/amd64/jvm.cfg", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=677, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fac9a490000
read(3, "# Copyright (c) 2003, Oracle and"..., 4096) = 677
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0x7fac9a490000, 4096)            = 0
stat("/usr/java/jdk1.7.0_75/jre/lib/amd64/server/libjvm.so", {st_mode=S_IFREG|0755, st_size=15224066, ...}) = 0
futex(0x7fac99e3d0d0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
open("/usr/java/jdk1.7.0_75/jre/lib/amd64/server/libjvm.so", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240\245\36\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=15224066, ...}) = 0
mmap(NULL, 15167976, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fac98a01000
mprotect(0x7fac99574000, 2097152, PROT_NONE) = 0
mmap(0x7fac99774000, 802816, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xb73000) = 0x7fac99774000
mmap(0x7fac99838000, 262632, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fac99838000
close(3)                                = 0
open("/usr/java/jdk1.7.0_75/bin/../lib/amd64/jli/libm.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=11922, ...}) = 0
mmap(NULL, 11922, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fac9a48e000
close(3)                                = 0
open("/lib64/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260T\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1141552, ...}) = 0
mmap(NULL, 3150168, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fac986ff000
mprotect(0x7fac98800000, 2093056, PROT_NONE) = 0
mmap(0x7fac989ff000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x100000) = 0x7fac989ff000
close(3)                                = 0
mprotect(0x7fac989ff000, 4096, PROT_READ) = 0
munmap(0x7fac9a48e000, 11922)           = 0
mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7fac9a389000
mprotect(0x7fac9a389000, 4096, PROT_NONE) = 0
clone(child_stack=0x7fac9a488fb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7fac9a4899d0, tls=0x7fac9a489700, child_tidptr=0x7fac9a4899d0) = 142
futex(0x7fac9a4899d0, FUTEX_WAIT, 142, NULLhellowerld
) = 0
exit_group(0)                           = ?

теперь процесс завис, но вы можете войти в контейнер:

docker exec -it myContainer bash

и увидите следующее:

ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 23:47 ?        00:00:00 bash
root       138     1  0 23:51 ?        00:00:00 strace java Foo
root       141   138 24 23:51 ?        00:01:21 [java] <defunct>
root       151     0  1 23:57 ?        00:00:00 bash
root       167   151  0 23:57 ?        00:00:00 ps -ef

беглый взгляд на статистику:

CONTAINER           CPU %               MEM USAGE / LIMIT     MEM %               NET I/O               BLOCK I/O
myContainer                  24.72%              64.18 MB / 8.365 GB   0.77%               11.09 MB / 202.6 kB   8.192 kB / 14.99

В 1.8.3 все работает нормально.

+1, Docker версии 1.9.1, сборка a34a1d5, OS X

+1, версия Docker 1.9.1, сборка a34a1d5, OS X 10.10.5, версия Docker Machine: 0.5.1 (HEAD)

+1

Докер версии 1.9.1, сборка a34a1d5 , OS X 10.11.1 (15B42)

+1

Докер версии 1.9.1, сборка a34a1d5 на OS X 10.11.1

Это действительно довольно странный вопрос. Если я strace неудачная команда apt-get , конец вывода будет следующим:

stat("/etc/apt/sources.list", {st_mode=S_IFREG|0644, st_size=161, ...}) = 0
open("/etc/apt/sources.list", O_RDONLY) = 5
read(5, "deb http://httpredir.debian.org/"..., 8191) = 161
pipe([6, 7])                            = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fc6fc88aa10) = 14
close(7)                                = 0
fcntl(6, F_GETFL)                       = 0 (flags O_RDONLY)
fstat(6, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc6fc892000
lseek(6, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
read(6, Process 14 attached
 <unfinished ...>
[pid    14] rt_sigaction(SIGPIPE, {SIG_DFL, [PIPE], SA_RESTORER|SA_RESTART, 0x7fc6fb531180}, {SIG_IGN, [PIPE], SA_RESTORER|SA_RESTART, 0x7fc6fb531180}, 8) = 0
[pid    14] rt_sigaction(SIGQUIT, {SIG_DFL, [QUIT], SA_RESTORER|SA_RESTART, 0x7fc6fb531180}, {SIG_DFL, [], 0}, 8) = 0
[pid    14] rt_sigaction(SIGINT, {SIG_DFL, [INT], SA_RESTORER|SA_RESTART, 0x7fc6fb531180}, {SIG_DFL, [], 0}, 8) = 0
[pid    14] rt_sigaction(SIGWINCH, {SIG_DFL, [WINCH], SA_RESTORER|SA_RESTART, 0x7fc6fb531180}, {0x7fc6fc0e5750, [WINCH], SA_RESTORER|SA_RESTART, 0x7fc6fb531180}, 8) = 0
[pid    14] rt_sigaction(SIGCONT, {SIG_DFL, [CONT], SA_RESTORER|SA_RESTART, 0x7fc6fb531180}, {SIG_DFL, [], 0}, 8) = 0
[pid    14] rt_sigaction(SIGTSTP, {SIG_DFL, [TSTP], SA_RESTORER|SA_RESTART, 0x7fc6fb531180}, {SIG_DFL, [], 0}, 8) = 0
[pid    14] getrlimit(RLIMIT_NOFILE, {rlim_cur=1024*1024, rlim_max=1024*1024}) = 0
[pid    14] fcntl(3, F_SETFD, FD_CLOEXEC) = 0
[pid    14] getrlimit(RLIMIT_NOFILE, {rlim_cur=1024*1024, rlim_max=1024*1024}) = 0
[pid    14] fcntl(4, F_SETFD, FD_CLOEXEC) = 0
[pid    14] getrlimit(RLIMIT_NOFILE, {rlim_cur=1024*1024, rlim_max=1024*1024}) = 0
[pid    14] fcntl(5, F_SETFD, FD_CLOEXEC) = 0
[pid    14] getrlimit(RLIMIT_NOFILE, {rlim_cur=1024*1024, rlim_max=1024*1024}) = 0
[pid    14] fcntl(6, F_SETFD, FD_CLOEXEC) = 0
[pid    14] getrlimit(RLIMIT_NOFILE, {rlim_cur=1024*1024, rlim_max=1024*1024}) = 0
[pid    14] fcntl(7, F_SETFD, FD_CLOEXEC) = 0
[pid    14] getrlimit(RLIMIT_NOFILE, {rlim_cur=1024*1024, rlim_max=1024*1024}) = 0
[pid    14] fcntl(8, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad file descriptor)
[pid    14] getrlimit(RLIMIT_NOFILE, {rlim_cur=1024*1024, rlim_max=1024*1024}) = 0
[pid    14] fcntl(9, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad file descriptor)
[pid    14] getrlimit(RLIMIT_NOFILE, {rlim_cur=1024*1024, rlim_max=1024*1024}) = 0
[pid    14] fcntl(10, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad file descriptor)
[pid    14] getrlimit(RLIMIT_NOFILE, {rlim_cur=1024*1024, rlim_max=1024*1024}) = 0
[pid    14] fcntl(11, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad file descriptor)

Где эти (Плохой дескриптор файла) ошибки продолжают повторяться бесконечно.

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

SIGPIPE дает сбой? это может соответствовать моему предыдущему сообщению, где я видел java "hello world", вызывающий зомби-процессы без явного "System.exit (0);" - а может, это совсем другой вопрос. если так извините за шум.

что происходит с вашим процессором при бесконечном цикле?

@andrewgdavis Это на 100%

java "hello world" вызывает зомби-процессы без явного "System.exit (0);"

Это определенно похоже на проблему, возникшую здесь.

Я могу определенно подтвердить проблему с b2d (даже сделал пополам, чтобы отследить ее наиболее положительно до удара ядра 4.1.13). Еще могу воспроизвести на 4.2.6 с b2d.

В качестве дополнительного излома мой хост Gentoo в настоящее время также использует патчи 4.1.13 + AUFS, и я вижу ту же самую проблему, поэтому мы определенно исключили что-либо, специфичное для b2d.

Думаю, стоит пролистать коммиты между 4.1.12 и 4.1.13, чтобы увидеть, не выпрыгивает ли что-нибудь, что может быть связано с этим.

(например, https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.1.13)

Ага, что-то ломается из ядра 4.1.12 => 4.1.13. Я могу подтвердить, что запекание ISO-образа boot2docker для первого не устраняет эту ошибку, в отличие от первого.

Итак, это не связано конкретно с boot2docker, но, похоже, связано с версией ядра, взаимодействующей с AUFS.

или, возможно, конкретный способ взаимодействия драйвера AUFS в Docker с
более новое ядро ​​- TBD, вероятно, с Linux-стабильным git bisect между 4.1.12
и 4.1.13: cry:

у меня есть теория волос с мозгом ...

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

приведенная выше фиксация изменяет файл filemap.c на generic_perform_write (struct file * file, struct iov_iter * i, loff_t pos)

Ниже приведен фрагмент кода, который я лично хочу протестировать, потому что комментарий описывает условия гонки как тупиковой, так и живой блокировки, и я вижу, что ЦП привязан к 100%. но это только я и мой коврик для поспешных выводов.

4.1.13 мм / filemap.c # l_2448

...
 2448 again:
 2449       /*
 2450        * Bring in the user page that we will copy from _first_.
 2451        * Otherwise there's a nasty deadlock on copying from the
 2452        * same page as we're writing to, without it being marked
 2453        * up-to-date.
 2454        *
 2455        * Not only is this an optimisation, but it is also required
 2456        * to check that the address is actually valid, when atomic
 2457        * usercopies are used, below.
 2458        */
 2459       if (unlikely(iov_iter_fault_in_readable(i, bytes))) {
 2460           status = -EFAULT;
 2461           break;
 2462       }
 2463 
 2464       if (fatal_signal_pending(current)) {
 2465           status = -EINTR;
 2466           break;
 2467       }
 2468 
 2469       status = a_ops->write_begin(file, mapping, pos, bytes, flags,
 2470                       &page, &fsdata);
 2471       if (unlikely(status < 0))
 2472           break;
 2473 
 2474       if (mapping_writably_mapped(mapping))
 2475           flush_dcache_page(page);
 2476 
 2477       copied = iov_iter_copy_from_user_atomic(page, i, offset, bytes);
 2478       flush_dcache_page(page);
 2479 
 2480       status = a_ops->write_end(file, mapping, pos, bytes, copied,
 2481                       page, fsdata);
 2482       if (unlikely(status < 0))
 2483           break;
 2484       copied = status;
 2485 
 2486       cond_resched();
 2487 
 2488       iov_iter_advance(i, copied);
 2489       if (unlikely(copied == 0)) {
 2490           /*
 2491            * If we were unable to copy any data at all, we must
 2492            * fall back to a single segment length write.
 2493            *
 2494            * If we didn't fallback here, we could livelock
 2495            * because not all segments in the iov can be copied at
 2496            * once without a pagefault.
 2497            */
 2498           bytes = min_t(unsigned long, PAGE_CACHE_SIZE - offset,
 2499                       iov_iter_single_seg_count(i));
 2500           goto again;
 2501       }
 2502       pos += copied;
 2503       written += copied;
 2504 
 2505       balance_dirty_pages_ratelimited(mapping);
 2506   } while (iov_iter_count(i));

@andrewgdavis можно использовать этот коммит во время git bisect как конкретную точку тестирования!

Увидеть подобное зависание при выключении mongodb . Определенно присутствует в 1.9.x. Отсутствует в 1.8.x.

Я смог решить эту проблему для себя, увеличив память виртуальной машины докер-машины с 1024 до 2048 МБ и назначив 2 процессора вместо 1.

Работает:

ВМ: Ubuntu 14.04 (оперативная память 2 ГБ)
Движок Докера: 1.9.1
Базовый образ Docker: ubuntu: latest

Не работает:

ВМ: Ubuntu 15.10 (2 ГБ оперативной памяти)
Движок Докера: 1.9.1,1.9.0,1.8.3
Базовый образ Docker: ubuntu: latest , ubuntu: 14.04

@marsinvasion Если возможно, вы можете распечатать вывод uname -a на обеих протестированных системах?

ВМ: Ubuntu 14.04
Linux ubuntu 3.19.0-25-generic # 26 ~ 14.04.1-Ubuntu SMP Пт 24 июля 21:16:20 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux

ВМ: Ubuntu 15.10
Linux ubuntu 4.2.0-19-generic # 23-Ubuntu SMP среда, 11 ноября, 11:39:30 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux

+1
Докер версии 1.9.1, сборка a34a1d5 на OS X 10.11.1

Встречается на OS X 10.9.5 с докером 1.9.1.

Вдохновленный @marsinvasion , я

Ой, скоро поговорим. Он перестал работать после изменения Dockerfile, над которым я работаю, и повторного запуска сборки.

Также вижу эту адскую ошибку (docker-machine boot2docker 1.9.1 в OS X) из ранее созданного образа

Я думал, что https://github.com/docker-library/java/issues/19 был связан, но, возможно, нет, здесь у нас зависание, там они получили ошибку о том, что не нашли «java».

В качестве временного решения переключил мой сервер на оверлей. До этого он также создал кучу контейнеров с зомби.

Докер версии 1.9.1, сборка a34a1d5 на OS X 10.11.1

Кто-нибудь знает, что нужно для переноса существующей системы boot2docker.iso на https://docs.docker.com/engine/userguide/storagedriver/overlayfs-driver/ или проще сделать полную перестройку? На этой странице есть зловещие предупреждения о сборках образов CentOS - каковы обходные пути "yum", связано ли это с https://github.com/docker/docker/issues/10180?

Это исправлено в 1.9.1a - установите это, если вы используете OSX - https://github.com/docker/toolbox/releases/download/v1.9.1a/DockerToolbox-1.9.1a.pkg

Определенно не исправлено Docker Toolbox 1.9.1a. Страдает от этой ошибки с этой версией. Оглядываясь назад на комментарии, похоже, что я не единственный.

нет, все еще не строит

Мне пришлось удалить виртуальную машину в виртуальном боксе и начать с нуля, чтобы она заработала.

Кроме того, несколько раз безуспешно пытались удалить и создать новую виртуальную машину.

Установил 1.9.1a, сделал docker-machine rm default и использовал терминал быстрого запуска Docker для восстановления машины по умолчанию. Восстановленные изображения (производные от java:7-jre ) и запущенные, по-прежнему не работают. Продолжает нормально работать с оверлейной машиной, построенной, как предложено выше:

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

^ спасибо! Я могу подтвердить, что оверлейный аппарат работает.

Использование overlay в качестве драйвера хранилища движка также помогло исправить зависание при завершении работы MongoDB.

Вы можете обойти ошибку сборки Dockerfile, установив Oracle java вместо 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

Но я недооценил масштаб проблемы, boot2docker 1.9.1 приводит к зомби-процессам java, даже в контейнерах CentOS, где openjdk устанавливается нормально.
root 322 11.1 0.0 0 0 ? Zsl 18:43 29:48 [java] <defunct>

Я не могу настроить свой докер-сервер с помощью --engine-storage-driver overlay потому что я создаю образы на основе CentOS, а overlayfs несовместимо с yum (https://github.com/ docker / docker / issues / 10180).

Я уверен, что люди, работающие с Docker, _не_ рекомендуют это, но я решил избавиться от этой проблемы с блокировкой, создав boot2docker.iso, который использует docker 1.9.1 с немного более старой AUFS. Инструкции в https://github.com/boot2docker/boot2docker/issues/1099#issuecomment -163052066.

пробовал oracle jdk1.7.0_75 и jdk1.8.0_65; оба зависают и создают несуществующий java-процесс.

ОТ: https://github.com/docker/docker/issues/10589
@ Neverfox здесь точно такая же проблема, с тем же изображением +1

~ docker version
Client:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.5.1
 Git commit:   a34a1d5
 Built:        Sat Nov 21 00:49:19 UTC 2015
 OS/Arch:      darwin/amd64

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


~ docker-machine inspect default
{
    "ConfigVersion": 3,
    "Driver": {
        "Driver": {
            "VBoxManager": {},
            "IPAddress": "192.168.99.100",
            "MachineName": "default",
            "SSHUser": "docker",
            "SSHPort": 61012,
            "SSHKeyPath": "/Users/myuser/.docker/machine/machines/default/id_rsa",
            "StorePath": "/Users/myuser/.docker/machine",
            "SwarmMaster": false,
            "SwarmHost": "tcp://0.0.0.0:3376",
            "SwarmDiscovery": "",
            "CPU": 1,
            "Memory": 4096,
            "DiskSize": 20000,
            "Boot2DockerURL": "",
            "Boot2DockerImportVM": "",
            "HostOnlyCIDR": "192.168.99.1/24",
            "HostOnlyNicType": "82540EM",
            "HostOnlyPromiscMode": "deny",
            "NoShare": false
        },
        "Locker": {}
    },
    "DriverName": "virtualbox",
    "HostOptions": {
        "Driver": "",
        "Memory": 0,
        "Disk": 0,
        "EngineOptions": {
            "ArbitraryFlags": [],
            "Dns": null,
            "GraphDir": "",
            "Env": [],
            "Ipv6": false,
            "InsecureRegistry": [],
            "Labels": [],
            "LogLevel": "",
            "StorageDriver": "",
            "SelinuxEnabled": false,
            "TlsVerify": true,
            "RegistryMirror": [],
            "InstallURL": "https://get.docker.com"
        },
        "SwarmOptions": {
            "IsSwarm": false,
            "Address": "",
            "Discovery": "",
            "Master": false,
            "Host": "tcp://0.0.0.0:3376",
            "Image": "swarm:latest",
            "Strategy": "spread",
            "Heartbeat": 0,
            "Overcommit": 0,
            "ArbitraryFlags": [],
            "Env": null
        },
        "AuthOptions": {
            "CertDir": "/Users/myuser/.docker/machine/certs",
            "CaCertPath": "/Users/myuser/.docker/machine/certs/ca.pem",
            "CaPrivateKeyPath": "/Users/myuser/.docker/machine/certs/ca-key.pem",
            "CaCertRemotePath": "",
            "ServerCertPath": "/Users/myuser/.docker/machine/machines/default/server.pem",
            "ServerKeyPath": "/Users/myuser/.docker/machine/machines/default/server-key.pem",
            "ClientKeyPath": "/Users/myuser/.docker/machine/certs/key.pem",
            "ServerCertRemotePath": "",
            "ServerKeyRemotePath": "",
            "ClientCertPath": "/Users/myuser/.docker/machine/certs/cert.pem",
            "StorePath": "/Users/myuser/.docker/machine/machines/default"
        }
    },
    "Name": "default",
    "RawDriver": "eyJWQm94TWFuYWdlciI6e30sIklQQWRkcmVzcyI6IjE5Mi4xNjguOTkuMTAwIiwiTWFjaGluZU5hbWUiOiJkZWZhdWx0IiwiU1NIVXNlciI6ImRvY2tlciIsIlNTSFBvcnQiOjYxMDEyLCJTU0hLZXlQYXRoIjoiL1VzZXJzL2RhdmlkZnJhbmNvZXVyLy5kb2NrZXIvbWFjaGluZS9tYWNoaW5lcy9kZWZhdWx0L2lkX3JzYSIsIlN0b3JlUGF0aCI6Ii9Vc2Vycy9kYXZpZGZyYW5jb2V1ci8uZG9ja2VyL21hY2hpbmUiLCJTd2FybU1hc3RlciI6ZmFsc2UsIlN3YXJtSG9zdCI6InRjcDovLzAuMC4wLjA6MzM3NiIsIlN3YXJtRGlzY292ZXJ5IjoiIiwiQ1BVIjoxLCJNZW1vcnkiOjQwOTYsIkRpc2tTaXplIjoyMDAwMCwiQm9vdDJEb2NrZXJVUkwiOiIiLCJCb290MkRvY2tlckltcG9ydFZNIjoiIiwiSG9zdE9ubHlDSURSIjoiMTkyLjE2OC45OS4xLzI0IiwiSG9zdE9ubHlOaWNUeXBlIjoiODI1NDBFTSIsIkhvc3RPbmx5UHJvbWlzY01vZGUiOiJkZW55IiwiTm9TaGFyZSI6ZmFsc2V9"
}
➜  ~  docker inspect 74
[
{
    "Id": "7471b734d7e7e47270511453a04d903c974cba77a2a0d259255355a653f95e04",
    "Created": "2015-11-27T13:23:11.515987776Z",
    "Path": "/docker-entrypoint.sh",
    "Args": [
        "cassandra",
        "-f"
    ],
    "State": {
        "Status": "running",
        "Running": true,
        "Paused": false,
        "Restarting": false,
        "OOMKilled": false,
        "Dead": false,
        "Pid": 1263,
        "ExitCode": 0,
        "Error": "",
        "StartedAt": "2015-11-27T13:23:11.612899257Z",
        "FinishedAt": "0001-01-01T00:00:00Z"
    },
    "Image": "338a92b912e4d5a84c4f399a9475a1476f8226eff85c2592c8e80ba58b13d225",
    "ResolvConfPath": "/mnt/sda1/var/lib/docker/containers/7471b734d7e7e47270511453a04d903c974cba77a2a0d259255355a653f95e04/resolv.conf",
    "HostnamePath": "/mnt/sda1/var/lib/docker/containers/7471b734d7e7e47270511453a04d903c974cba77a2a0d259255355a653f95e04/hostname",
    "HostsPath": "/mnt/sda1/var/lib/docker/containers/7471b734d7e7e47270511453a04d903c974cba77a2a0d259255355a653f95e04/hosts",
    "LogPath": "/mnt/sda1/var/lib/docker/containers/7471b734d7e7e47270511453a04d903c974cba77a2a0d259255355a653f95e04/7471b734d7e7e47270511453a04d903c974cba77a2a0d259255355a653f95e04-json.log",
    "Name": "/pensive_kalam",
    "RestartCount": 0,
    "Driver": "aufs",
    "ExecDriver": "native-0.2",
    "MountLabel": "",
    "ProcessLabel": "",
    "AppArmorProfile": "",
    "ExecIDs": null,
    "HostConfig": {
        "Binds": null,
        "ContainerIDFile": "",
        "LxcConf": [],
        "Memory": 0,
        "MemoryReservation": 0,
        "MemorySwap": 0,
        "KernelMemory": 0,
        "CpuShares": 0,
        "CpuPeriod": 0,
        "CpusetCpus": "",
        "CpusetMems": "",
        "CpuQuota": 0,
        "BlkioWeight": 0,
        "OomKillDisable": false,
        "MemorySwappiness": -1,
        "Privileged": false,
        "PortBindings": {},
        "Links": null,
        "PublishAllPorts": false,
        "Dns": [],
        "DnsOptions": [],
        "DnsSearch": [],
        "ExtraHosts": null,
        "VolumesFrom": null,
        "Devices": [],
        "NetworkMode": "default",
        "IpcMode": "",
        "PidMode": "",
        "UTSMode": "",
        "CapAdd": null,
        "CapDrop": null,
        "GroupAdd": null,
        "RestartPolicy": {
            "Name": "no",
            "MaximumRetryCount": 0
        },
        "SecurityOpt": null,
        "ReadonlyRootfs": false,
        "Ulimits": null,
        "LogConfig": {
            "Type": "json-file",
            "Config": {}
        },
        "CgroupParent": "",
        "ConsoleSize": [
            0,
            0
        ],
        "VolumeDriver": ""
    },
    "GraphDriver": {
        "Name": "aufs",
        "Data": null
    },
    "Mounts": [
        {
            "Name": "2249b03f9a598e5ac3f306983877292baa299c4499c9db77eb9bfcb88fd2f541",
            "Source": "/mnt/sda1/var/lib/docker/volumes/2249b03f9a598e5ac3f306983877292baa299c4499c9db77eb9bfcb88fd2f541/_data",
            "Destination": "/var/lib/cassandra",
            "Driver": "local",
            "Mode": "",
            "RW": true
        }
    ],
    "Config": {
        "Hostname": "7471b734d7e7",
        "Domainname": "",
        "User": "",
        "AttachStdin": false,
        "AttachStdout": true,
        "AttachStderr": true,
        "ExposedPorts": {
            "7000/tcp": {},
            "7001/tcp": {},
            "7199/tcp": {},
            "9042/tcp": {},
            "9160/tcp": {}
        },
        "Tty": false,
        "OpenStdin": false,
        "StdinOnce": false,
        "Env": [
            "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
            "CASSANDRA_VERSION=2.1.11",
            "CASSANDRA_CONFIG=/etc/cassandra"
        ],
        "Cmd": [
            "cassandra",
            "-f"
        ],
        "Image": "cassandra:2.1.11",
        "Volumes": {
            "/var/lib/cassandra": {}
        },
        "WorkingDir": "",
        "Entrypoint": [
            "/docker-entrypoint.sh"
        ],
        "OnBuild": null,
        "Labels": {},
        "StopSignal": "SIGTERM"
    },
    "NetworkSettings": {
        "Bridge": "",
        "SandboxID": "e2f074e4b10e67cd7ac22d6e73d50304fc3f0a68d67c7fee6d7f8d647c9eb9b1",
        "HairpinMode": false,
        "LinkLocalIPv6Address": "",
        "LinkLocalIPv6PrefixLen": 0,
        "Ports": {
            "7000/tcp": null,
            "7001/tcp": null,
            "7199/tcp": null,
            "9042/tcp": null,
            "9160/tcp": null
        },
        "SandboxKey": "/var/run/docker/netns/e2f074e4b10e",
        "SecondaryIPAddresses": null,
        "SecondaryIPv6Addresses": null,
        "EndpointID": "63596aa5ec20516d477921fec4197d086b4dd4f1ad25014b5ddf027b82891966",
        "Gateway": "172.17.0.1",
        "GlobalIPv6Address": "",
        "GlobalIPv6PrefixLen": 0,
        "IPAddress": "172.17.0.2",
        "IPPrefixLen": 16,
        "IPv6Gateway": "",
        "MacAddress": "02:42:ac:11:00:02",
        "Networks": {
            "bridge": {
                "EndpointID": "63596aa5ec20516d477921fec4197d086b4dd4f1ad25014b5ddf027b82891966",
                "Gateway": "172.17.0.1",
                "IPAddress": "172.17.0.2",
                "IPPrefixLen": 16,
                "IPv6Gateway": "",
                "GlobalIPv6Address": "",
                "GlobalIPv6PrefixLen": 0,
                "MacAddress": "02:42:ac:11:00:02"
            }
        }
    }
}
]

Я просто запустил docker run -it cassandra:2.1.11 и ваш терминал зависнет, контейнер невозможно остановить. Вы должны остановить всю виртуальную машину.

+1

Сегодня удалось дублировать проблему в Docker 1.9.1 под управлением Mac OSX 10.11.1 (15B42)

Смог обойти это, установив Docker 1.9.0

_Приносим извинения за отсутствие информации на моем рабочем компьютере ранее в течение дня - обновленную информацию предоставлю позже _

: +1:

То же самое и с Docker 1.9.1 и OS X 10.11.

Для людей с этой проблемой

Мы до сих пор сузили это до не ошибки _docker_, а проблемы ядра в сочетании с AUFS в ядре, которое используется в текущей версии boot2docker; см. https://github.com/docker/docker/issues/18180#issuecomment -161832035

• Если вы хотите быть в курсе прогресса, используйте кнопку подписки на этой странице. не комментируйте, если у вас нет новой информации, которая может помочь решить эту проблему.
• если вы хотите помочь решить эту проблему, выполнение git-bissect ядра может помочь https://github.com/docker/docker/issues/18180#issuecomment -161834068
• помните, что каждый комментарий отправит подписчикам более 2000 писем, и бесчисленное количество щенков умрут: smile:

Только что протестировал Storage Driver: devicemapper (с Server Version: 1.9.1 и ядром 4.2.6), и ошибка _не_ воспроизводится, поэтому мы все еще находимся в "странном взаимодействии между некоторыми изменениями в новом ядре и патчами AUFS". " земля. :расстроен:

Протестировано, и ошибка все еще присутствует в свежем ядре 4.1.14 , поэтому мы все еще сидим в каком-то коммите, который был перенесен на 4.1.13, странно взаимодействующий с патчами AUFS (и нам не повезло, что он уже исправлен промежуточный).

Я решил попробовать себя в старом колледже и клонировал репозиторий boot2docker; затем изменил фиксацию aufs в файле докеров до предыдущей версии. Итак, docker 1.9.1 kernel 4.1.13 + предыдущая версия AUFS, которая поставлялась до 1.9.1. Компиляция на моей машине идет медленно ... есть ли установка docker swarm, которую я могу запустить вместе с git bisect и агрегировать результаты? это было бы мило.

в любом случае, я опубликую свои результаты в ближайшее время, если это сработает ...

Обновить:
4.1.13 + этот коммит AUFS по-прежнему обнаруживает проблему.
ENV AUFS_COMMIT 1724fe65683d126a92c6baeea0b3c7d0306c63ef

Я не знаю какой-либо простой настройки для агрегирования результатов, хотя ее можно было бы построить.

FWIW, https://sources.debian.net/src/ca-certificates-java/jessie/debian/postinst.in/ - это точный сценарий, который работает в этом пакете, а https://sources.debian.net/src /ca-certificates-java/jessie/src/main/java/org/debian/security/UpdateCertificates.java/ - это точный источник Java, который выполняется, когда мы получаем зависший + несуществующий + привязанный ЦП.

Сегодня возникла связанная с этим проблема (Java-процесс зависает).

Среда хоста: Linux lenovo 4.2.0-19-generic # 23-Ubuntu SMP среда, 11 ноября, 11:39:30 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux
Дистрибутив: Ubuntu 15.10
Движок Докера: 1.9.1
Докер-машина: 0.5.0 (04cfa58)

Я следую руководству по сети с несколькими хостами . Единственная разница в том, что я играю с образом oracle / nosql . Этот образ основан на Oracle Linux и использует OpenJDK.

@brunoborges да, это может быть та же проблема, см. https://github.com/docker/docker/issues/18500#issuecomment -163334612

@brunoborges просто проверить boot2docker.iso версию - если 1.9.1 можно попробовать понизить до 1.9.0 и восстановить свои машины и тянуть изображения еще раз.
Если вы пойдете этим путем, не могли бы вы написать здесь небольшой отчет?

Поэтому мне стало интересно, почему это происходит только на java, а не на каких-либо других языках. В одном из моих предыдущих постов я смог подробно описать самые простые репродукции, просто скомпилировав и запустив

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

для случая сбоя, который привел к неработающему процессу Java
а потом

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

для ожидаемого (не несуществующего) случая.

Затем я попытался воспроизвести нечто подобное с помощью Python. У меня не получилось, но я попытался. Для тех, кто заинтересован, я пытался показать последний вывод strace exit_group(0) = ? который был замечен в java-процессе зомби. (Эта ссылка предоставила мне много информации о потоках python / seccomp / etc http://stackoverflow.com/questions/25678139/how-do-you-cleanly-exit-after-enpting-seccomp-in-python)

Итак, перейдем к ядру: после пересборки iso boot2docker, возня с версиями aufs и версиями ядра (ничего из этого не имело никакого значения) мне надоело, насколько медленным был процесс компиляции с использованием numproc = 1. Поэтому я изменил его на 6. ==> Обратите внимание, что больше нет 1 процессора (у кого сейчас только 1 процессор в день?). Вдруг случай провала

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

начал работать.

Очевидно, следующим шагом было понизить его до 1 процессора. ==> ОТКАЗ. вернуться к несуществующему процессу Java.

Итак, я хотел больше узнать о том, как закрывается Java. Это не очень хорошо определено. но с одним процессором этот java-процесс смог успешно запуститься: (пожалуйста, не высмеивайте мою ужасную java.)

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

class Foo {

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

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

Может ли кто-нибудь еще подтвердить это поведение? << вопрос теперь спорный

Обновление: даже с более чем одним ядром может возникнуть несуществующий процесс Java. (Я запускал cassandra-cli, и это случилось.)

докер-машина 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

Имея ту же проблему зависания при создании битбакет-сервера - update-ca-Certificates работает нормально, но posthook jdk зависает навсегда. Только проблема при использовании 1.9.1 boot2docker. Перешел на образ RancherOS и проблем не было. OSX 10.10.

С El Capitan, Docker 1.9.1 и Ubuntu 14.04.1 я получаю: Настройка ca-сертификатов-java, которая бесконечно зависает.

@stremlenye откатился на 1.9.0. Все еще зависает.

@brunoborges docker 1.9.0 или boot2docker.iso 1.9.0?

@stremlenye Docker

@brunoborges Ознакомьтесь с этим комментарием выше:

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

carsten-ulrich-saitow-ag объясняет, как создать новую докер-машину с iso 1.9.0, используя флаг --virtualbox-boot2docker-url. Этот совет спас мой бекон! Как только я это сделал, я снова смог установить JRE RPM в свои контейнеры.

@ mobsy74 @stremlenye пробовал с boot2docker 1.9.0, иногда он зависает.

@brunoborges Спасибо, что попробовали. Поэтому я буду придерживаться 1.8.3, пока не исправлю эту ошибку.

@stremlenye you mean boot2docker 1.8.3 ?

@brunoborges да

Привет,
Я была такая же проблема.
проблема решена при понижении версии инструментов Docker с 1.9.1 до 1.9.0
https://github.com/docker/toolbox/releases/download/v1.9.0/DockerToolbox-1.9.0.pkg

Включение нескольких процессоров (в докере) решило эту проблему для меня.

--virtualbox-cpu-count=4

@heiths, не могли бы вы поделиться версиями инструментов для

imho, boot2docker должен отойти от aufs к одному из других доступных драйверов хранилища. Есть веская причина, по которой aufs так и не попал в ядро ​​Linux.

@robvanmieghem у каждого драйвера есть свои ограничения. Aufs в целом довольно стабилен, а overlayfs имеет некоторые проблемы с блокировкой (в зависимости от использования)

@brunoborges DockerToolbox-1.9.1c - это сработало для меня в Windows и OSX.

@thaJeztah никогда не говорил, что overlayfs - идеальное решение. Я действительно думаю, что btrfs - хороший вариант для boot2docker, хотя boot2docker предназначен для запуска контейнеров докеров, и, помимо того факта, что btrfs полностью поддерживается в ядре Linux, очень легко просмотреть содержимое.

По этому поводу существует столько же мнений, сколько существует комбинаций дистрибутива и файловой системы :) Ни одно решение не будет идеальным для всех случаев использования, поэтому в духе открытого исходного кода и Linux я думаю, что лучшее решение - предоставить лучшее поддержка нескольких вариантов дистрибутива. У нас уже есть выбор Boot2Docker или RancherOS, и я считаю, что была проделана некоторая работа по пересборке boot2docker на базе дистрибутива debian. docker-machine будет поддерживать ubuntu в облаке и на голом железе, поэтому я уверен, что ISO-образ виртуальной машины на основе ubuntu не составит труда собрать вместе, а также другие, такие как один, построенный на alpine или CoreOS и т. д. Затем для каждого из них есть выбор файловой системы - опять же, RancherOS теперь предлагает ZFS в качестве дополнительной установки, в то время как CoreOS использовала BTRFS по умолчанию, и я считаю, что это все еще вариант, и начиная с ядра 3.19 Ubuntu поддерживает OverlayFS из коробки - любой, кто хочет использовать Snappy Core на основе изображение b2d? ;)

Теперь, если бы мы только могли стандартизировать именование параметров docker-machine и удалить ссылки на 'boot2docker', чтобы уменьшить путаницу - использование параметра boot2docker-url для установки RancherOS несколько неинтуитивно;)

@ дальний синий +1

@heiths +1. Это решило это и для меня на OSX с 1.9.1c

Установка CPU на> 1 позволяет избежать этой проблемы. 1.9.1c не помогло.

@heiths @fredriksvensson На самом деле, у меня эта проблема случайным образом появлялась в среде с несколькими контейнерами, и я также пытался увеличить количество процессоров (также памяти, но это не имеет значения). Пара циклов stop <all> / start <all> показали, что проблема не исчезла. Я бы порекомендовал вам таким же образом проверить свою среду, чтобы убедиться, что решение стабильно для вас.
/ cc @timechanter

О, это точно не пропало. Но 10% -ный шанс зависания по сравнению со 100% -ным, по крайней мере, управляемый в краткосрочной перспективе.

@heiths --virtualbox-cpu-count=4 также работал у меня.

@timechanter +1 Установка CPU на> 1 позволила мне хотя бы один раз избежать этой проблемы; на данный момент выглядит как эффективное решение.

OSX 10.10.5

Неустановленный набор инструментов Docker 1.9.1. У меня сработал переход на панель инструментов Docker 1.9.0.

Та же проблема на El Capitan MacOSX

@heiths --virtualbox-cpu-count=4 у меня тоже работает.

Произошло у меня в Windows 7 с Docker Toolbox 1.9.1b и 1.9.1e.

«Настройка ca-сертификатов-java (20130815ubuntu1) ...» - El Capitan MacOSX. Помогите, ребята !!! Я не могу это исправить

@ troian88 перейти на boot2docker.iso 1.9.0 или 1.8.3.

@ troian88 , используйте докер-машину с несколькими процессорами.

Можно подтвердить, что --virtualbox-cpu-count=2 - это временное решение проблемы зависания Setting up ca-certificates-java с Docker 1.9.1.

Для людей с этой проблемой

Мы до сих пор сузили это до не ошибки _docker_, а проблемы ядра в сочетании с AUFS в ядре, которое используется в текущей версии boot2docker; см. https://github.com/docker/docker/issues/18180#issuecomment -161832035

• Если вы хотите быть в курсе прогресса, используйте кнопку подписки на этой странице. не комментируйте, если у вас нет новой информации, которая может помочь решить эту проблему.
• если вы хотите помочь решить эту проблему, выполнение git-bissect ядра может помочь https://github.com/docker/docker/issues/18180#issuecomment -161834068
• помните, что каждый комментарий отправит подписчикам более 2000 писем, и бесчисленное количество щенков умрут: smile:

@externl @stremlenye Thanks.

Глядя на стеки LWP, я обнаружил, что ошибка вызвана aufs_destroy_inode .

Я займусь этим дальше.

Похоже, это тупик, связанный с inode-> i_mutex .

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

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

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

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



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

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

Запись

Люди говорят, что ошибки можно избежать при работе на нескольких процессорах.
Тем не менее, я все еще могу найти ошибку в своем физическом блоке с 4 процессорами. (хотя вероятность <1%.)
Таким образом, --virtualbox-cpu-count=2 _НЕ_ гарантирует, что вы сможете избежать ошибки.

Обратите внимание, что количество процессоров все еще имеет значение.
Я могу детерминированно найти ошибку, когда запускаю taskset 0x1 java . ( taskset назначает процессу определенные процессоры).

@AkihiroSuda большое спасибо, что

Обратите внимание, что эта проблема также возникает в Windows 7 при использовании Docker 1.8.3.

Мы видим то же самое (точно такие же трассировки стека, что и в комментарии AkihiroSuda выше) на старых ядрах:
Linux 3.19.0-42-generic #48~14.04.1-Ubuntu SMP x86_64 с Docker version 1.9.1, build a34a1d5

Я могу подтвердить утверждение @AkihiroSuda о нескольких процессорах - я также использовал это на моем хосте, который имеет 8 ядер.

Эта отладка AUFS выглядит действительно интересно - возможно, стоит зарегистрировать проблему с AUFS и посмотреть, могут ли разработчики AUFS помочь в отладке? Возможно, им было бы полезно, если бы мы могли воспроизводить только с помощью AUFS (без Docker), но это не совсем тривиально. :улыбка:

@tianon Я сделал сообщение на aufs-users: http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/5335

@AkihiroSuda , я видел это зависание в случае использования, отличного от Java. А именно пытается выключить разветвленный демон MongoDB. Это не происходит при запуске или регулярном использовании MongoDB, но надежно происходит при завершении работы.

@jakirkham Спасибо, похоже, что для запуска ошибки требуется определенная конфигурация потока (обычно появляется в Java, MongoDB и, возможно, в других вещах).

Кстати, если подумать, возможно, зависание AUFS - это «результат» ошибки, а не «причина» ошибки.
Заглядываю в эту тему: http://www.serverphorums.com/read.php?12 , 673905
(Я не заметил, что zap_pid_ns_processes() тоже зависает два дня назад, потому что в то время я использовал bash в качестве процесса инициализации. Https://github.com/docker/docker/issues/18180#issuecomment- 166186061)

https://github.com/docker/docker/issues/18180#issuecomment -161843456
@andrewgdavis , вы совершенно правы!

Ошибка кажется регрессией, вызванной фиксацией 296291cd в ядре Linux ( mm/filemap.c ).

Я создал ISO-образ Boot2Docker ( boot2docker-v1.9.1-fix1.iso ), в котором отсутствует фиксация 296291cd: https://github.com/AkihiroSuda/boot2docker/releases/tag/v1.9.1-fix1

Надеюсь, это сработает для всех. : смайлик:

Коммит 296291cd создает бесконечный цикл -EINTR в mm/filemap.c:generic_perform_write , который fs/aufs/xino.c:do_xino_fwrite() не может терпеть:

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

Поскольку do_xino_fwrite() зацикливается бесконечно, zap_pid_ns_processes() (выполняется в другом LWP) не может вернуться из schedule() при работе на одном процессоре.
Вот почему мы попадаем в ошибку.

@ gilles-duboscq
Вы столкнулись с ошибкой, потому что Canonical изначально перенесла фиксацию 296291cd в дерево ядра 3.19: http://kernel.ubuntu.com/git/ubuntu/ubuntu-vivid.git/commit/?id=6b08592b8acc677d5b9bb7986343fdd6e0ad3303

@AkihiroSuda вау, спасибо, что нашли! Что делать дальше? Следует ли отменить этот патч или есть способ его улучшить? Вы рассматриваете возможность отправки патча в апстрим ядра?

@AkihiroSuda , ваше исправление работает как шарм. благодаря!

@thaJeztah

Это непростой вопрос.
Без фиксации 296291cd sendfile(2) может быть неубиваемым.
Я опасаюсь, что этот неубиваемый sendfile может вызвать проблемы с безопасностью (например, атаку исчерпания процесса анонимным пользователем) в некоторых определенных средах.

Я пытаюсь улучшить commit 296291cd, но это может занять некоторое время.

Во всяком случае, я сообщил об этой ошибке в bugzilla ядра: https://bugzilla.kernel.org/show_bug.cgi?id=109971

Я также сделал контейнер Docker akihirosuda/test18180 для простоты отладки: https://github.com/AkihiroSuda/test18180/tree/v0.0.1

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

@AkihiroSuda хм, ладно, похоже на проблему, да. Большое спасибо за репро-контейнер и исследования; по крайней мере, есть очень конкретная задача, над которой нужно работать, надеюсь, другие люди присоединятся к ней, пытаясь помочь найти решение. Огромное спасибо за вашу отличную работу.

Я был поражен OS X El Capitan Darwin Kernel Version 15.2.0
Докер версии 1.9.1, сборка d12ea79c9de6d144ce6bc7ccfe41c507cca6fd35
boot2docker 1.9.1

У меня сработал переход на boot2docker 1.9.0 с помощью следующих команд:

docker-machine rm default
docker-machine create -d virtualbox --virtualbox-boot2docker-url=https://github.com/boot2docker/boot2docker/releases/download/v1.9.0/boot2docker.iso default

@thaJeztah
AUFS будет поддерживать 296291cd.
http://article.gmane.org/gmane.linux.file-systems.aufs.user/5343

Итак, следующий шаг - дождаться обновления AUFS.

Ты герой, @AkihiroSuda! Спасибо за работу с апстримом, чтобы разобраться в этом! :сердце:

Если кто-то хочет применить исправление @AkihiroSuda , это работает как шарм:

docker-machine rm default
docker-machine create -d virtualbox --virtualbox-boot2docker-url=https://github.com/AkihiroSuda/boot2docker/releases/download/v1.9.1-fix1/boot2docker-v1.9.1-fix1.iso default

Для всех, кто пользуется Ubuntu 14.04, переход на ядро ​​3.13.0-71 или старше должен решить проблему. 296291cd был портированном после этого .

@ebpitts, спасибо за совет, вот несколько относительных шагов по понижению версии ядра Ubuntu 14.04 до 3.13.0-71 с установленным Docker 1.9.1.

sudo apt-get install linux-image-3.13.0-71-generic
sudo apt-get install linux-generic linux-headers-generic linux-image-generic
sudo reboot

На этом этапе у вас должно быть два ядра для выбора во время загрузки. Однако я работал в удаленном ящике Vagrant через SSH, поэтому для меня не было загрузчика GRUB ... поэтому я удалил более новое ядро ​​по умолчанию (3.13.0-74 в моем случае) в качестве варианта загрузки:

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

В выводе команды было кое-что об обновлении Grub, поэтому вы можете проверить /boot/grub/grub.cfg и увидеть, какой вариант загрузки по умолчанию будет при перезапуске. Кажется, мне пришлось сделать это удаление / повторное добавление заголовков, но как только файл grub.cfg выглядел хорошо ( 3.13.0-71-generic был единственным и первым вариантом загрузки), продолжайте и перезагружайтесь:

sudo reboot

А затем верните SSH в мой ящик:

$ uname -r
3.13.0-71-generic

Но теперь казалось, что докер не работает. Итак, полная переустановка требует сначала удаления:

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

И, честно говоря, тогда моя следующая попытка запустить docker build в том же контейнере, который висел на заголовке OP («Настройка ca-сертификатов-java»), он все еще умер и на этот раз заблокировал мою машину , но теперь, когда у меня нет доступа по SSH, я пойду домой и подожду до 2016 года, чтобы попробовать посмотреть, есть ли к тому времени у кого-нибудь более подходящее решение = /

Итак ... Я не могу утверждать, что даже после понижения версии ядра до 3.13.0-71 после решения этой проблемы в Ubuntu 14.04 + Docker 1.9.1 даже эффективен. Фу.

Да, просто чтобы дважды подтвердить, я запустил $ docker run -it --rm akihirosuda/test18180 и он все еще зависает.

[INFO] Checking whether hitting docker#18180.
........................................................................................
[INFO] OK. not hitting docker#18180.
[INFO] Checking whether sendfile(2) is killable.
[INFO] If the container hangs up here, you are still 
       facing the bug that linux<strong i="7">@296291cd</strong> tried to fix.

Это после понижения Ubuntu 14.04 до версии ядра 3.13.0-71 с 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 , вы уверены, что раннюю версию ядра Ubuntu - это действительно исправление?

Интересно, даже когда я явно установил драйвер хранилища на devicemapper в /var/default/docker :

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

и перезапустите службу докеров, запустив docker info :

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

У меня до сих пор висит тестовый образ akihirosuda/test18180:latest .

Я перешел на Docker 1.8.3 (не так просто без apt-get ) на моем компьютере с Ubuntu 14, используя необработанный двоичный файл, вот шаги ... для всех остальных ... Я снова в деле (пожалуйста обратите внимание, я также ранее понижал версию ядра до 3.13.0-71-generic , см. выше)

Я установил двоичный файл 1.8.3 из https://get.docker.com/builds/Linux/x86_64/docker-1.8.3 , затем переместил его в /usr/bin/docker , дал ему права на исполняемый файл sudo chmod +x /usr/bin/docker .

Затем я взял необработанный сценарий sysvinit-debian , закомментировал тело check_init() заменил его просто echo '' и поместил в /etc/init.d . Затем я установил его для запуска при загрузке как root с ln -s /etc/init.d/docker /etc/rc2.d/S99docker и запустил sudo reboot . После этого я снова запускаю службу docker 1.8.3 при загрузке из двоичной установки. Я не знаю, почему эти шаги на самом деле не документированы на странице двоичной установки на веб-сайте Docker. В любом случае.

$ service docker status
 * Docker is running

$ docker version
Client:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   f4bf5c7
 Built:        Mon Oct 12 18:01:15 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   f4bf5c7
 Built:        Mon Oct 12 18:01:15 UTC 2015
 OS/Arch:      linux/amd64

$ docker info
Containers: 4
Images: 38
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 46
 Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-71-generic
Operating System: Ubuntu 14.04.3 LTS
CPUs: 1
Total Memory: 490 MiB
Name: runner
ID: BLAH

Здесь все хорошо - я могу правильно запустить $ docker run -it hello-world . Запуск akihirosuda/test18180 все еще зависает (???), но я могу собрать и запустить свой исходный контейнер, не застревая на Setting up ca-certificates-java , что и привело меня сюда.

Для справки, я использую Ubuntu 15.04 vivid, Linux 3.19.0-42-generic. Также пострадали.

Поскольку я не могу использовать оверлей (мне нужны гости RHEL), я создал раздел btrfs на запасном диске и смонтировал его в / var / lib / docker (до этого остановите демон docker). Docker теперь успешно использует btrfs, но

@mikeatlas
Спасибо за тестирование моего изображения test18180 .

Результат не странный.
Вторая проверка ( Checking whether sendfile(2) is killable. ) зависает в старых ядрах.
Вам нужно более новое ядро ​​с 296291cd, чтобы пройти вторую проверку.

| AUFS? | Ядро включает 296291cd? | Ожидаемый результат |
| --- | --- | --- |
| Y | Y | Зависает (1-я проверка: Checking whether hitting docker#18180. ) |
| Y | N | Зависает (2-я проверка: Checking whether sendfile(2) is killable. ) |
| N | Y | Пройти |
| N | N | Зависает (2-я проверка: Checking whether sendfile(2) is killable. ) |

@cfstras Спасибо, я займусь этим.

@cfstras , это воспроизводимо, и я открыл # 19073.

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

РЕДАКТИРОВАТЬ:
Раньше я ошибался в том, почему докер не работал после изменения версии ядра, но я могу подтвердить, что установка дополнительного пакета для моего ядра, а затем повторная установка докера решила эту проблему для меня:

sudo apt-get удалить docker-engine
sudo apt-get install linux-image-extra-3.13.0-71-generic
curl -sSL https://get.docker.com/ | ш

@lwcolton интересно, linux-image-extra-3.13.0-71-generic - это не пакет, который я собирался установить (но, как уже отмечалось, я установил общие дополнительные пакеты позже) .... но все же у меня сложилось впечатление, что модуль AUFS намного старше, чем просто относительно недавнее ядро 3.13.0-71 . Тем не менее, переход на Docker 1.8.3 не был слишком болезненным, и если бы мне пришлось пройти через этот процесс снова, я бы предпочел понижение версии Docker, а не понижение уровня ядра Linux в любой день недели.

@dschep Обратите внимание на то, что для перехода на OverlayFS требуется версия ядра 3.18 + в Linux, и, как указано на странице Docker, _Как бы многообещающей ни была OverlayFS, она все еще относительно молода.

@mikeatlas Я полагаю, что это самое большое ограничение на данный момент для OverlayFS: «_Таким образом, использование yum внутри контейнера на хосте Docker с использованием драйвера хранилища оверлея вряд ли сработает без реализации обходных путей.

@brunoborges yum в настоящее время исправляется для работы с overlayfs, поэтому вскоре новые версии yum должны иметь возможность работать с overlayfs (хотя некоторые проблемы все равно будут, так что это зависит от вашего варианта использования / ситуации, с которой вы столкнетесь их). Другой проблемой может быть чрезмерное использование inode.

Думаю, я тоже столкнулся с этой проблемой. В трассировке вызовов упоминается apparmor, но отключение apparmor не имеет значения. Использование devicemapper решило проблему.

dmesg:

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

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

пс auxfg:

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

Это было исправлено в апстриме AUFS - boot2docker был обновлен, чтобы включить исправление (которое выйдет в следующем выпуске), и все затронутые пользователи, не использующие boot2docker, должны применить обновленный выпуск AUFS. : +1:

@tianon , есть ли у вас какие-либо ссылки на ошибки в

http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/5345 - это объявление о выпуске апстрима - не уверен, есть ли еще обсуждения, чем это

http://comments.gmane.org/gmane.linux.file-systems.aufs.user/5337 содержит более подробное обсуждение вопроса

благодарю вас!

Это было исправлено в апстриме AUFS - boot2docker был обновлен, чтобы включить исправление (которое выйдет в следующем выпуске), и все затронутые пользователи, не использующие boot2docker, должны применить обновленный выпуск AUFS. : +1:

Ницца.

Использовалась ли версия AUFS с ошибками в Docker Hub?

@tianon «Применить обновленную версию AUFS» означает для пользователей, не использующих boot2docker (все, кто запускает движок докеров _не_ в разработке в Mac OS X, для которой b2d создан, в первую очередь), что им придется дождаться обновления ядра Linux с этот патч AUFS ... Или ... учитывая, сколько установок / людей, похоже, затронуты, может ли кто-нибудь предоставить упрощенные / минимальные инструкции о том, как исправить AUFS до 4.1.13+? Руководство для 4.1.13+ определенно нетривиально для чтения; Самостоятельно исправлять ядро ​​Linux для этого конкретного исправления не совсем для слабонервных.

Я так понимаю, если я построю этот boot2docker.iso поместю его в ~/.docker/machine/cache и создам новую виртуальную машину с docker-machine эта виртуальная машина будет использовать эту новую копию boot2docker .

Я так понимаю, если я создам этот boot2docker.iso и помещу его в ~ / .docker / machine / cache и создам новую виртуальную машину с докер-машиной, эта виртуальная машина будет использовать эту новую копию boot2docker.

Технически да, это сработает, но лучшим вариантом может быть использование --virtualbox-boot2docker-url , например:

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

Ах, хорошо, спасибо за разъяснения. Что ж, значит, это работает.

Отправил запрос на обновление AUFS до Canonical: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043

Будет ли новый выпуск boot2docker, так как 1.9.1 , похоже, не содержит исправления?

редактировать. с изображением @AkihiroSuda boot2docker я смог продолжить. Спасибо всем!

Да, это исправление после 1.9.1. @tianon сказал, что релиз планируется. Обычно он выключается одновременно с выходом docker для выпуска. Поскольку они, как правило, придерживаются двухнедельного цикла выпуска релизов, я ожидаю, что релиз неизбежен. Тем временем @AkihiroSuda разработала исправление, которое вы можете использовать или создать свое собственное, что действительно просто и требует времени.

Спасибо @AkihiroSuda за изображение, работает! :)

+1 Debian Wheezy и Ubuntu 15.04

Релиз @jakirkham - двухмесячный цикл, но мы очень скоро выпускаем 1.10-rc1, для этого у boot2docker будет версия rc1.

Ой, извините, должно быть, перепутали. Спасибо, что поправили меня, @tiborvass. Ты понял это, @shusso?

@jakirkham Да , спасибо: +1:

Мне удалось создать виртуальный ящик хоста докер-машины, используя это исправление:

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

В настоящее время хосты докер-машин, которые я создаю на вычислительном движке Google, с параметром --driver google, похоже, имеют эту проблему. В драйвере Google нет возможности указать другой .iso, поэтому я не могу использовать исправление выше в вычислениях Google.

Кто-нибудь знает обходной путь? или действительно, если Google знает об этой проблеме, или где я должен отправить для них отчет об ошибке.

Драйвер докер-машины Google поддерживается докером или Google?

Драйвер можно найти здесь; https://github.com/docker/machine/tree/master/drivers/google

Я думаю, что образ виртуальной машины, который запускается в Google Compute, должен быть вот таким:

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

То есть:

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

Просматривая вышесказанное, потенциальный обходной путь выглядит так, как будто он может быть предложен @nathanleclaire

$ docker-machine create -d google - оверлей для драйвера-хранилища двигателя

Также, похоже, есть опция "--google-machine-image" для драйвера Google для docker-machine. Команда:

Список изображений $ gcloud compute

Перечисляет доступные общедоступные изображения. Замечу, что недавно поставили новую убунту хитрость.

Просто чтобы подтвердить:

$ docker-machine create -d google - оверлей для драйвера-хранилища двигателя

Работал. Я также исследую создание пользовательского образа машины с помощью фиксированного boot2docker и попытку связать его с docker-machine.

Всем, кто использует это в boot2docker, отправьте RC по адресу
https://github.com/tianon/boot2docker-legacy/releases/tag/v1.10.0-rc1 а
выстрел. : +1:

@tianon Я тестирую это следующим образом trecloux / docker-java-zombie
И выглядит неплохо .... но все равно зависает с образом akihirosuda / test18180

Серьезно впечатляющая работа @AkihiroSuda Ты один постоянный

@trecloux вы используете btrfs и зависаете для sendfile?
Если да, то это известная проблема: https://github.com/docker/docker/issues/19073

@AkihiroSuda Я использую образ boot2docker v1.10.0-rc1 с aufs:

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

Вот результат вашего тестового изображения:

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

@trecloux Это ожидаемое поведение. Ничего не вешает.

@AkihiroSuda Хорошо, извините. И спасибо за ваши усилия :-)
Итак, @tianon : 1.10.0-rc1 выглядит неплохо.

такая же проблема здесь. Зависает при настройке ca-сертификатов, ЦП сходит с ума ...

$ docker version
Client:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.3
 Git commit:   a34a1d5
 Built:        Fri Nov 20 17:56:04 UTC 2015
 OS/Arch:      darwin/amd64

под управлением MacOSX 10.11.2

@sgoendoer пытается использовать изображение @AkihiroSuda с docker-machine create --driver virtualbox --virtualbox-boot2docker-url="file:/path_to_the_image" nameofmachine

для пользователей, отличных от boot2docker, есть идеи, с какой версией ядра это будет исправлено? 3.13.0-71 вроде работает, 3.13.0-74 и 3.13.0-76 вроде битые ...

Та же проблема здесь; Значит, для этого нет простого решения?
Это исправлено в версии RC? Пробую сейчас. Хотя это, вероятно, вызывает другие проблемы.

ПОСЛЕДНИЕ БЫСТРЫЕ РЕШЕНИЯ (Обновление: 21 января, 15:33 UTC)

| Distro | Обходной путь |
| --- | --- |
| Общие | Используйте devicemapper / overlay / btrfs (но это может вызвать другую проблему ..) |
| Boot2Docker | : white_check_mark: Обновите до v1.10.0-rc1 |
| Ubuntu 14.04LTS | : arrow_down: Понизить версию ядра до версии 3.13.0-71 или более ранней |
| Ubuntu 15.04 | : arrow_down: Понизить версию ядра до версии 3.19.0-39 или старше (: предупреждение: не тестировалось) |
| Ubuntu 15.10 | : arrow_down: Понизить версию ядра до версии 4.2.0-18 или старше |
| Debian 7/8 | : arrow_down: Понизить версию ядра до версии 3.16.7-ckt11 выпуска 3.16.0 ( apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 ) или более ранней |
| Debian 9 | : white_check_mark: (не поддерживает AUFS, начиная с ядра 3.18-1 ~ exp1) |
| Gentoo | : white_check_mark: Обновить до недавних (: предупреждение: не проверено) |
| RHEL / CentOS | : white_check_mark: (не поддерживает AUFS) |
| openSUSE | : white_check_mark: (не поддерживает AUFS) |

Дистрибьюторы выпускают билеты

| Distro | Статус | URL проблемы |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: Закрыто | https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | : white_medium_square: Выполняется | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | Еще не подтверждено | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

@AkihiroSuda v1.10.0 -rc1 не исправляет зомби для меня, у кого-нибудь тоже была проблема?

root     21996  0.0  0.0      0     0 ?        Ss   08:47   0:00  \_ [bash]
root     23810 99.7  0.0      0     0 ?        Zl   08:50   7:42  |   \_ [phantomjs] <defunct>

wait4(-1, 
[{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 469
wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 28
rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7f60c9ec3d40}, {0x4438a0, [], SA_RESTORER, 0x7f60c9ec3d40}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
close(3)                                = -1 EBADF (Bad file descriptor)
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
wait4(-1, 0x7ffc5ec19e58, WNOHANG, NULL) = -1 ECHILD (No child processes)
rt_sigreturn(0xffffffffffffffff)        = 0
read(0, "", 1)                          = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
exit_group(0)   

После запуска strace в несуществующем процессе через некоторое время это появилось, но после этого зомби все еще существует:

root     21996  0.0  0.0      0     0 ?        Ss   08:47   0:00  \_ [bash]
root     23810 99.9  0.0      0     0 ?        Zl   08:50  26:06      \_ [phantomjs] <defunct>

На этот раз он больше не доступен через strace, я думаю, он все еще прикреплен, даже если это не так.
: ~ # strace -p 23810

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

@wzrdtales
Не могли бы вы получить стеки LWP, как в https://github.com/docker/docker/issues/18180#issuecomment -166186061?
также, какова ваша командная строка и версия phantomjs?

Конечно, версия phantomjs: 1.9

cmdline

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

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

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

А также стек задач:

:~# cat /proc/23810/task/23839/stack 
[<ffffffff8114ef6a>] __generic_file_write_iter+0x14a/0x360
[<ffffffff8114f1ca>] generic_file_write_iter+0x4a/0xd0
[<ffffffff811bd0ec>] new_sync_write+0x6c/0xb0
[<ffffffff811bd080>] new_sync_write+0x0/0xb0
[<ffffffff811bd0fb>] new_sync_write+0x7b/0xb0
[<ffffffffa050c377>] xino_fwrite.part.28+0x67/0xb0 [aufs]
[<ffffffffa050c4b5>] xino_fwrite+0x75/0x90 [aufs]
[<ffffffff811fa97a>] fsnotify_clear_marks_by_inode+0x2a/0x110
[<ffffffff811d84b8>] iput+0x48/0x1b0
[<ffffffffa052b780>] au_xigen_inc+0x50/0xa0 [aufs]
[<ffffffffa050d33d>] au_xino_delete_inode+0x1ad/0x220 [aufs]
[<ffffffff811e5143>] __inode_wait_for_writeback+0x63/0xc0
[<ffffffffa051f485>] au_iinfo_fin+0xc5/0x1d0 [aufs]
[<ffffffffa0507cae>] aufs_destroy_inode+0xe/0x30 [aufs]
[<ffffffff811cab10>] do_unlinkat+0x170/0x2c0
[<ffffffff8108d4f1>] task_work_run+0xa1/0xc0
[<ffffffff81015025>] do_notify_resume+0xb5/0xc0
[<ffffffff8154e50d>] system_call_fast_compare_end+0x10/0x15
[<ffffffffffffffff>] 0xffffffffffffffff

Также, чтобы добавить информацию о системе:

uname -a
Linux mg_build_server_12 3.16.0-0.bpo.4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u2~bpo70+1 (2016-01-03) x86_64 GNU/Linux

:~# docker info
Containers: 34
 Running: 9
 Paused: 0
 Stopped: 25
Images: 1058
Server Version: 1.10.0-rc1
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 1197
 Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Plugins: 
 Volume: local
 Network: null host bridge
Kernel Version: 3.16.0-0.bpo.4-amd64
Operating System: Debian GNU/Linux 7 (wheezy)
OSType: linux
Architecture: x86_64
CPUs: 16
Total Memory: 23.58 GiB

@wzrdtales Вы используете Docker (не Boot2Docker) v1.10.0-rc1 на Debian?
Это не работает, потому что проблема связана с ошибкой ядра, а не Docker.

Я изучаю ядра Debian и обновляю список https://github.com/docker/docker/issues/18180#issuecomment -173436661.

@AkihiroSuda y, это прямо на debian. Я наблюдал за точкой debian в вашем списке, спасибо за указание :)

Для debian мы не должны использовать ядра на основе v3.16.7-ckt20
http://kernel.ubuntu.com/git/ubuntu/linux.git/tag/?h=linux-3.16.y&id=v3.16.7-ckt20
http://kernel.ubuntu.com/git/ubuntu/linux.git/commit/?h=linux-3.16.y&id=475a23000dd8d2f264bab9d6eb71a2a6b9d4de72

@wzrdtales Я обновил список, используйте ядро ​​ckt11.

@AkihiroSuda : FWIW, я считаю, что рекомендация о понижении до v3.16.7-ckt11 ставит вас под угрозу CVE-2016-0728, которая имеет известную публичную эскалацию корневого каталога. Я только что пингулировал https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 , но к вашему сведению, прежде чем вы переходите на более раннюю версию.

@zmerlynn Спасибо, что указали на это!

ПОСЛЕДНИЕ БЫСТРЫЕ РЕШЕНИЯ (Обновление: 26 января, 1:49 UTC)

| Distro | Обходной путь |
| --- | --- |
| Общие | Используйте devicemapper / overlay / btrfs (но это может вызвать другую проблему ..).
Если вы можете обновить AUFS и собрать ядро ​​вручную, вы также можете использовать AUFS v20160111 или новее. |
| Boot2Docker | : white_check_mark: Обновите до v1.10.0-rc1 |
| Ubuntu 14.04LTS | : arrow_down: Понизить версию ядра до версии 3.13.0-71 или более ранней |
| Ubuntu 15.04 | : arrow_down: Понизить версию ядра до версии 3.19.0-39 или старше (: предупреждение: не тестировалось) |
| Ubuntu 15.10 | : arrow_down: Понизить версию ядра до версии 4.2.0-18 или старше |
| Debian 7/8 | : arrow_down: Понизить версию ядра до версии 3.16.7-ckt11 выпуска 3.16.0 ( apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 ) или более ранней |
| Debian 9 | : white_check_mark: (не поддерживает AUFS, начиная с ядра 3.18-1 ~ exp1) |
| Gentoo | : white_check_mark: Обновить до недавних (: предупреждение: не проверено) |
| RHEL / CentOS | : white_check_mark: (не поддерживает AUFS) |
| openSUSE | : white_check_mark: (не поддерживает AUFS) |

: warning: Понижение версии ядра может представлять угрозу безопасности (например, CVE-2016-0728)

Дистрибьюторы выпускают билеты

| Distro | Статус | URL проблемы |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: Закрыто | https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | : white_medium_square: Выполняется | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | : white_medium_square: Выполняется | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

Мы также столкнулись с этой проблемой, mongod застрял в состоянии R, работающем со 100% ЦП.

Вот настоящий трюк для получения правильной трассировки стека, который приводит меня сюда:

эхо "л"> / proc / sysrq-trigger

оттуда вы можете увидеть, что процессор 2 застрял в цикле бесконечности AUFS

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

поиск по do_xino_fwrite приводит меня прямо сюда!

Кажется, я также сталкиваюсь с этой проблемой в Debian Stretch, где она зависает при настройке сертификатов.

Вот сообщение об ошибке: https://gist.github.com/clball/738feb46094802a1bcf7
Вот информация о версии: https://gist.github.com/clball/494fe8598dd0cdfd6d10
Вот файл докеров: https://gist.github.com/8778f8db143478d6c8ab

Итак, какое здесь решение для OSX, есть ли уже обновление докера?

Пока нет, но есть релиз-кандидат. (https://github.com/tianon/boot2docker-legacy/releases/tag/v1.10.0-rc2)

Решением для меня было изменение серверной части хранилища.

Добавьте строку в / etc / default / docker
¡¡БУДЬТЕ ОСТОРОЖНЫ, вы потеряете данные контейнера !!

DOCKER_OPTS="--storage-driver=devicemapper"

Я рекомендую остановить службу докеров, стереть папку докеров в / var / lib, а затем добавить строку и перезапустить службу докеров.

@Referenceup-tarantegui: драйвер devicemapper считается ужасно плохим с точки зрения производительности, если он не установлен непосредственно на реальные физические диски. Видеть
https://jpetazzo.github.io/assets/2015-03-03-not-so-deep-dive-into-docker-storage-drivers.html#43 https://jpetazzo.github.io/assets/2015 -03-03-not-so-deep-dive-into-docker-storage-drivers.html # 44
и
https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/ «Производительность Device Mapper и Docker»

Есть версия B для релиз-кандидата2

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

Обновил таблицу про Ubuntu.

ПОСЛЕДНИЕ БЫСТРЫЕ РЕШЕНИЯ (Обновление: 3 февраля, 6:30 UTC)

| Distro | Обходной путь |
| --- | --- |
| Общие | Используйте devicemapper / overlay / btrfs (но это может вызвать другую проблему ..).
Если вы можете обновить AUFS и собрать ядро ​​вручную, вы также можете использовать AUFS v20160111 или новее. |
| Boot2Docker | : white_check_mark: Обновитесь до v1.10.0-rc3 |
| Ubuntu 14.04LTS | : white_check_mark: Обновить ядро ​​до 3.13.0-77.121hf1533043v20160201b1 (PPA) |
| Ubuntu 15.04 | : white_check_mark: Обновить ядро ​​до 3.19.0-49.55hf1533043v20160201b1 (PPA) |
| Ubuntu 15.10 | : white_check_mark: Обновить ядро ​​до версии 4.2.0-27.32hf1533043v20160201b1 (PPA) |
| Debian 7/8 | : arrow_down: Понизить версию ядра до версии 3.16.7-ckt11 выпуска 3.16.0 ( apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 ) или более ранней |
| Debian 9 | : white_check_mark: (не поддерживает AUFS, начиная с ядра 3.18-1 ~ exp1) |
| Gentoo | : white_check_mark: Обновить до недавних (: предупреждение: не проверено) |
| RHEL / CentOS | : white_check_mark: (не поддерживает AUFS) |
| openSUSE | : white_check_mark: (не поддерживает AUFS) |

Дистрибьюторы выпускают билеты

| Distro | Статус | URL проблемы |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: Закрыто | https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | : white_medium_square: В процессе (расчетное время прибытия: 20 февраля) | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | : white_medium_square: Выполняется | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

@AkihiroSuda , я думаю, вы имели в виду v1.10.0-rc2 для boot2docker или, возможно, ссылка должна была идти сюда (https://github.com/boot2docker/boot2docker/releases/tag/v1.10.0-rc3).

@jakirkham Спасибо, исправил ссылку.

rc3 находится в официальном репо вместо моей вилки:
https://github.com/boot2docker/boot2docker/releases/tag/v1.10.0-rc3

Мы исследовали технический долг, который заставил нас использовать мою вилку, и обнаружили, что
это было исправлено, начиная с версии docker-machine 0.5, поэтому мы идем дальше и
вверх. :улыбка:

Кстати, для тех, кто хочет переключить ядра на версии с патчем chiluk, перечисленные выше для Ubuntu PPA. Например, для Ubuntu 14.04, linux-image-3.13.0-77-generic , ваши шаги будут такими:

$ sudo apt-get update
$ sudo apt-get install software-properties-common -y
$ sudo add-apt-repository ppa:chiluk/1533043
$ sudo apt-get update
$ sudo apt-get install linux-image-3.13.0-77-generic \
                       linux-image-extra-3.13.0-77-generic -y

Затем вам нужно будет обновить конфигурацию /etc/default/grub , затем запустить sudo update-grub , а затем перезагрузиться в исправленную новую сборку ядра. Если вы не делали этого раньше, вот руководство о том, как установить другое ядро ​​по умолчанию в grub .

Я могу подтвердить, что этой проблемы нет в Docker 1.10.0, что также исправило мою ситуацию в OS X 10.11. В противном случае я собирался перейти на 1.9.0.

У меня все еще возникает проблема с контейнером / процессом java в докере 1.10:

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

@AkihiroSuda Я пробую ваши быстрые обходные пути (спасибо!), Но я не могу установить старое ядро ​​на свой сервер Debian 8 (jessie), я получаю:

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

Когда я пробую предложения @mikeatlas (кстати, нужно было sudo apt-get install software-properties-common чтобы заставить sudo add-apt-repository ppa:chiluk/1533043 работать), я получаю ошибку обновления, что, я думаю, является причиной того, что установка не работает

$ sudo add-apt-repository ppa:chiluk/1533043
You are about to add the following PPA to your system:
 This ppa contains the proposed fix for 1533043, and I would appreciate testing and results reported back to  LP#1533043.

Thank you,
 More info: https://launchpad.net/~chiluk/+archive/ubuntu/1533043
Press [ENTER] to continue or ctrl-c to cancel adding it

gpg: keyring `/tmp/tmp_j6e2_s5/secring.gpg' created
gpg: keyring `/tmp/tmp_j6e2_s5/pubring.gpg' created
gpg: requesting key E2B6D4A9 from hkp server keyserver.ubuntu.com
gpg: /tmp/tmp_j6e2_s5/trustdb.gpg: trustdb created
gpg: key E2B6D4A9: public key "Launchpad PPA for Dave Chiluk" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
OK
$ sudo apt-get update
Ign http://ftp.us.debian.org jessie InRelease
Hit http://security.debian.org jessie/updates InRelease
...
Get:15 https://apt.dockerproject.org debian-jessie/main Translation-en [454 B]
Ign https://apt.dockerproject.org debian-jessie/main Translation-en
Err http://ppa.launchpad.net jessie/main amd64 Packages
  404  Not Found
Ign http://ppa.launchpad.net jessie/main Translation-en_US
Ign http://ppa.launchpad.net jessie/main Translation-en
Fetched 8,877 B in 3s (2,935 B/s)
W: Failed to fetch http://ppa.launchpad.net/chiluk/1533043/ubuntu/dists/jessie/main/binary-amd64/Packages  404  Not Found

E: Some index files failed to download. They have been ignored, or old ones used instead.

$ sudo apt-get install linux-image-3.13.0-77-generic \
>                        linux-image-extra-3.13.0-77-generic -y
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package linux-image-3.13.0-77-generic
E: Couldn't find any package by regex 'linux-image-3.13.0-77-generic'
E: Unable to locate package linux-image-extra-3.13.0-77-generic
E: Couldn't find any package by regex 'linux-image-extra-3.13.0-77-generic'

Моя информация о докере:

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

@jamshid спасибо за подсказку о необходимости software-properties-common , я обновил свой пост выше.

@jamshid : После добавления PPA и выполнения apt-get update проверьте и посмотрите, какие ядра доступны для вашей машины ... Похоже, есть более новая сборка ( 3.13.0-78 ), но я не вижу он доступен после запуска обновления здесь. Однако вот как вы _ можете_ выяснить, какие ядра доступны для установки:

$ apt-cache search linux-image-3.13.0-7
[... snip older builds ...]
linux-image-3.13.0-77-generic - Linux kernel image for version 3.13.0 on 64 bit x86 SMP

Если вы не видите что-то вроде linux-image-3.13.0-77-generic или выше, значит, что-то еще не так.

О, @jamshid, вы используете Debian 8? Примечание выше: Downgrade kernel to version 3.16.7-ckt11 of release 3.16.0 (apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3) or older

apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 в Debian 8 дает

Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Version '3.16.7-ckt11-1+deb8u3' for 'linux-image-3.16.0-4-amd64' was not found

Час активного поиска в Google пакета ckt11 не помог.
Пожалуйста, какие-нибудь предложения, как понизить последнюю версию ядра Debian 8?

apt-cache policy linux-image-3.16.0-4-amd64
linux-image-3.16.0-4-amd64:
  Installed: 3.16.7-ckt20-1+deb8u3
  Candidate: 3.16.7-ckt20-1+deb8u3
  Version table:
 *** 3.16.7-ckt20-1+deb8u3 0
        500 http://security.debian.org/ jessie/updates/main amd64 Packages
        100 /var/lib/dpkg/status
     3.16.7-ckt20-1+deb8u2 0
        500 http://ftp.debian.org/debian/ jessie/main amd64 Packages
        500 http://httpredir.debian.org/debian/ jessie/main amd64 Packages

@davojan Вы можете найти ранее установленные пакеты в /var/cache/apt/archives . Вы сможете перейти на более раннюю версию с помощью dpkg -i <old_package>.deb .

Подтверждено, что установка нового ядра из PPA устранила проблему для меня (Ubuntu 14.04.3 / Kernel 3.13.0-78-generic / Docker 1.9.1)
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043

Кто-нибудь получил инструкции по переходу на более раннюю версию для работы с Debian (не Ubuntu)? Мне интересно, не работает ли мой apt-get update с ошибкой ниже (после добавления репозитория ppa):

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

Это что только пакеты ubuntu доступны на https://launchpad.net/~chiluk/+archive/ubuntu/1533043? Хм, я сбит с толку, я думал, что Ubuntu основан на Debian.

@jamshid Ubuntu

Если 3.16.7-ckt11-1 + deb8u3, к сожалению, больше не доступен, вы можете исправить последнее ядро: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207#47

(Могу загрузить пакет deb, если он кому-то нужен)

Если кому-то понадобится ядро, я загрузил его сюда, оно немного новее, чем deb8u3, но не похоже, что в нем есть ошибка, по крайней мере, я не сталкивался с ним, работая с этим довольно долго, но исправляя последнее ядро, вероятно, лучшее решение. Однако, если вам это нужно:
https://wizardtales.com/linux-image-3.16.0-0.bpo.4-amd64_3.16.7-ckt11-1+deb8u6~bpo70+1_amd64.deb

@wzrdtales : +1:

Для таких, как я, все еще изо всех сил, чтобы разобраться с этим, я хотел бы указать вам на TINI как на хороший обходной путь:
https://github.com/krallin/tini

с помощью нескольких строк в файле докеров я получил приличный процесс инициализации, способный удалять зомби.
Это позволит избежать перехода на devicemapper.

Привет,
Франческо

Итак, я использую тини. Однако здесь мне это не помогло, так как проблема, с которой я столкнулся, была во время создания образа.

Также при запуске контейнера я использую tini, но меня это все равно коснулось.

@fflatorre
Спасибо за информацию, но проблема с зомби, которую может решить tini, кажется, отличается от этой проблемы.
https://github.com/docker/docker/issues/18180#issuecomment -167042078

Собственно, даже с тини можно получить зомби:

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 Я забыл упомянуть, что мы не сталкиваемся с этой проблемой при создании изображения. Мы создаем очень простой образ, а затем логика подготовки делегируется кучке доступных сценариев. Во время подготовки один из процессов (кафка) зависал. TINI, похоже, решил эту проблему.
Я признаю, что это может быть не решение для вас, на самом деле я бы предложил понизить его с обходного пути до плацебо :)
Надеюсь, что мы сможем получить, скоро будут разобраны.

У меня была такая же проблема с запуском Docker 1.9.1 на OSX 10.11.3:

$ docker -v
Docker version 1.9.1, build a34a1d5

Исправлено обновление до последней версии Docker Toolbox:

$ docker -v
Docker version 1.10.1, build 9e83765

Для информации я перечислил некоторые проблемы и обходные пути, связанные с драйверами хранилища AUFS / Overlay / BtrFS / ZFS / devicemapper: https://github.com/AkihiroSuda/docker-issues/

Надеюсь, это поможет тем, кто интересуется # 18180 и другими ..

@AkihiroSuda Я попытался перейти по ссылке https://launchpad.net/%7Echiluk/+archive/ubuntu/1533043/+packages, но мне не разрешено просматривать страницу.

См. Также: https://github.com/docker/toolbox/issues/318#issuecomment -184143546

@ schmunk42
Я тоже не мог получить доступ к странице.
Думаю чилук переделывает пакеты. Вы можете спросить его на https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043

Для людей, у которых возникают проблемы с этим, вот как решить проблему в Ubuntu 14.04 с использованием предложенного ядра . Это, конечно, не будет иметь значения, когда ядро ​​перейдет в основную ветвь.

Прежде чем мы начнем, мы можем подтвердить, что мы работаем с затронутым ядром, запустив (например, <3.19.0-50 в Ubuntu 14.04):

$ uname -r
3.19.0-49-generic

Поскольку мы это знаем, нам сначала нужно включить предлагаемые пакеты, запустив:

$ echo "deb http://archive.ubuntu.com/ubuntu/ trusty-proposed restricted main multiverse universe" | sudo tee -a /etc/apt/sources.list
$ echo -e "Package: *\nPin: release a=trusty-proposed\nPin-Priority: 400" | sudo tee -a  /etc/apt/preferences.d/proposed-updates

После этого давайте установим обновленное ядро:

$ sudo apt-get update
$ sudo apt-get install linux-image-3.19.0-50-generic/trusty-proposed linux-image-extra-3.19.0-50-generic/trusty-proposed

И давайте перезагрузимся

$ sudo shutdown -r now

После перезагрузки мы можем подтвердить, что последняя версия теперь работает на последней версии ядра:

$ uname -r
3.19.0-50-generic

Спасибо @vpetersson. Я пытаюсь выяснить, что произойдет, когда эта версия ядра будет выпущена, она просто перезапишет предложенную установку или вам нужно что-то сделать, чтобы вернуться к нормальной работе, пожалуйста?

@IainColledge Да, я мог бы предположить, что это так, но я не совсем уверен.

Обновлена ​​таблица об Ubuntu и Debian.

ПОСЛЕДНИЕ БЫСТРЫЕ РЕШЕНИЯ

| Distro | Обходной путь |
| --- | --- |
| Общие | Используйте devicemapper / overlay / btrfs (но это может вызвать другую проблему ..).
Если вы можете обновить AUFS и собрать ядро ​​вручную, вы также можете использовать AUFS v20160111 или новее. |
| Boot2Docker | : white_check_mark: Обновите до v1.10.0 или новее |
| Ubuntu 14.04LTS | : white_check_mark: Обновите ядро ​​до 3.13.0-79.123 или новее |
| Ubuntu 15.04 | : white_check_mark: Обновите ядро ​​до 3.19.0-51.57 или новее |
| Ubuntu 15.10 | : white_check_mark: Обновите ядро ​​до версии 4.2.0-30.35 или новее |
| Debian 7/8 | : arrow_down: Понизить версию ядра до версии 3.16.7-ckt11 выпуска 3.16.0 или более ранней ( архив dpkg от @wzrdtales) |
| Debian 9 | : white_check_mark: (не поддерживает AUFS, начиная с ядра 3.18-1 ~ exp1) |
| Gentoo | : white_check_mark: Обновить до недавних (: предупреждение: не проверено) |
| RHEL / CentOS | : white_check_mark: (не поддерживает AUFS) |
| openSUSE | : white_check_mark: (не поддерживает AUFS) |

Дистрибьюторы выпускают билеты

| Distro | Статус | URL проблемы |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: Закрыто | https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | : white_check_mark: Закрыто | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | : white_medium_square: Выполняется | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

Еще кое-что; Я перечислил некоторые известные ошибки в драйверах хранилища: https://github.com/AkihiroSuda/docker-issues

На всякий случай, если кто-то захочет иметь последнее ядро ​​debian "linux_3.16.7-ckt20-1 + deb8u3" с патчами, упомянутыми ранее - я собрал его вручную, и он находится по адресу https://fxposter.org/linux-image-3.16 .0-4-amd64_3.16.7-ckt20-1 + deb8u3a ~ test_amd64.deb.

удивительный! У меня эта проблема уже несколько недель, и я думаю, что исправление для Ubuntu было выпущено только вчера: P

Подтверждаю, что последнее обновление ядра 14.04LTS до 3.19.0-51 положило конец моим зомби-Java. Благодаря!

Debian поддерживал эту проблему.

ПОСЛЕДНИЕ БЫСТРЫЕ РЕШЕНИЯ

| Distro | Обходной путь |
| --- | --- |
| Общие | Используйте devicemapper / overlay / btrfs (но это может вызвать другую проблему ..).
Если вы можете обновить AUFS и собрать ядро ​​вручную, вы также можете использовать AUFS v20160111 или новее. |
| Boot2Docker | : white_check_mark: Обновите до v1.10.0 или новее |
| Ubuntu 14.04LTS | : white_check_mark: Обновите ядро ​​до 3.13.0-79.123 или новее |
| Ubuntu 15.04 | : white_check_mark: Обновите ядро ​​до 3.19.0-51.57 или новее |
| Ubuntu 15.10 | : white_check_mark: Обновите ядро ​​до версии 4.2.0-30.35 или новее |
| Debian 7 | : white_check_mark: Обновите ядро ​​до 3.2.73-2 + deb7u3 (из пакета linux-image-3.2.0-4-amd64) или более поздней версии |
| Debian 8 | : white_check_mark: Обновите ядро ​​до 3.16.7-ckt20-1 + deb8u4 (из пакета linux-image-3.16.0-4-amd64) или более поздней версии |
| Debian 9 | : white_check_mark: (не поддерживает AUFS, начиная с ядра 3.18-1 ~ exp1) |
| Gentoo | : white_check_mark: Обновить до недавних (: предупреждение: не проверено) |
| RHEL / CentOS | : white_check_mark: (не поддерживает AUFS) |
| openSUSE | : white_check_mark: (не поддерживает AUFS) |

Дистрибьюторы выпускают билеты

| Distro | Статус | URL проблемы |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: Закрыто | https://github.com/boot2docker/boot2docker/pull/1113 |
| Ubuntu | : white_check_mark: Закрыто | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| Debian | : white_check_mark: Закрыто | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

у меня сработало обновление ядра 14.04LTS: +1:

Я использую OSX на Boot2Docker версии 1.10.2, мастер сборки: 611be10, версия Docker 1.10.2, сборка c3959b1 и сначала получил это из docker-compose:

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

Затем попробовал docker kill 38e1e2590dfa но процесс зависает навсегда. docker.log:

time="2016-03-09T14:49:13.053004077Z" level=debug msg="Calling POST /v1.21/containers/38e1e2590dfa5d77482b8fbf6b14f01e8d5278622b8e5d7262cd2cdeb777690b/stop"
time="2016-03-09T14:49:13.053058084Z" level=debug msg="POST /v1.21/containers/38e1e2590dfa5d77482b8fbf6b14f01e8d5278622b8e5d7262cd2cdeb777690b/stop?t=10"
time="2016-03-09T14:49:13.053097711Z" level=debug msg="Sending 15 to 38e1e2590dfa5d77482b8fbf6b14f01e8d5278622b8e5d7262cd2cdeb777690b"
time="2016-03-09T14:49:23.053530062Z" level=info msg="Container 38e1e2590dfa5d77482b8fbf6b14f01e8d5278622b8e5d7262cd2cdeb777690b failed to exit within 10 seconds of SIGTERM - using the force"
time="2016-03-09T14:49:23.053720529Z" level=debug msg="Sending 9 to 38e1e2590dfa5d77482b8fbf6b14f01e8d5278622b8e5d7262cd2cdeb777690b"
time="2016-03-09T14:49:33.054082100Z" level=info msg="Container 38e1e2590dfa failed to exit within 10 seconds of kill - trying direct SIGKILL"
time="2016-03-09T14:49:34.254353402Z" level=debug msg="Calling GET /v1.22/containers/json"
time="2016-03-09T14:49:34.254413283Z" level=debug msg="GET /v1.22/containers/json"
time="2016-03-09T14:49:54.293708866Z" level=debug msg="Calling POST /v1.22/containers/38e1e2590dfa/kill"
time="2016-03-09T14:49:54.293752784Z" level=debug msg="POST /v1.22/containers/38e1e2590dfa/kill?signal=KILL"
time="2016-03-09T14:49:54.293802705Z" level=debug msg="Sending 9 to 38e1e2590dfa5d77482b8fbf6b14f01e8d5278622b8e5d7262cd2cdeb777690b"
time="2016-03-09T14:50:04.294276946Z" level=info msg="Container 38e1e2590dfa failed to exit within 10 seconds of kill - trying direct SIGKILL"
time="2016-03-09T14:50:26.678957119Z" level=debug msg="clean 3 unused exec commands"

Просто в качестве примечания (я знаю, что это закрыто, но не уверен, имеет ли смысл открывать как новый выпуск). У меня была такая же проблема в более поздней версии, пока я не переключился на devmapper.

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

@einhverfr Проблема исправлена ​​в ядре 3.13.0-79.123 (похоже, у вас 3.13.0-77)

Можно ли решить эту проблему с помощью обновления ядра? Мы сталкиваемся с той же проблемой с Docker 1.9.1 в Ubuntu 14.04 с 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 да, это проблема ядра. Возможно, что-то еще может привести к аналогичному поведению, или если в ядре есть регресс. Однако, пожалуйста, откройте новую проблему, если у вас возникли проблемы с текущей версией; имейте в виду, что docker 1.9.1 является EOL, поэтому больше не будет получать обновления.

Я блокирую обсуждение этой проблемы, потому что исходная проблема здесь была решена, и я хочу, чтобы эта проблема не собирала, возможно, не связанные проблемы. См. Этот комментарий; https://github.com/docker/docker/issues/18180#issuecomment -193708192 для версий ядра, необходимых для решения этой проблемы.