أواجه نفس المشكلة. أنا أحقق.

نحن نواجه نفس المشكلة أيضًا.

نعم ، إنها مشكلة في عامل الإرساء 1.9. لقد خفضت تصنيفي إلى 1.8.3 وتم حل جميع المشكلات. أنا الآن أقوم بالتحقيق في حل. سوف ينشر هنا! تكس

أواجه نفس المشكلة مع Docker 1.9.1a

لدي docker 1.8.3 ، لذلك ربما تؤدي عملية تثبيت إصدار مختلف من عامل الإرساء إلى إصلاح الموقف. تضمين التغريدة

وجود نفس المشكلة مع إصدار docker 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

واجه المطورون في مكتبي هذا عن طريق الصدفة أيضًا.

هذا الإصدار / بناء عمل: عامل الميناء النسخة 1.9.0، بناء 76d6bc9

هذا الإصدار / بناء معلقة: عامل الميناء النسخة 1.9.1، بناء a34a1d5

crosbymichael أنا للأسف لم

يمكن لأي شخص لديه معرفة كيفية استخدام git-bisecting و docker استخدام معرفات الإنشاء التي يوفرها @ chico1198!

لقد واجهت نفس المشكلة مع 1.9.1 على OSX El Capitan ، ولم يساعد الرجوع إلى 1.9.0.

نفس المشكلة هنا على OSX 10.9.3 مع:
إصدار Docker 1.9.1 ، بناء a34a1d5
إصدار Docker 1.9.0 ، بناء 76d6bc9

crosbymichael قمت بتسجيل الدخول إلى boot2docker وقمت بتشغيل ps auxf ، هذا ما رأيته:

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

+1 مع docker 1.9.1 على OSX 10.11 مع محاولة إنشاء صورة من أوبونتو 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 مع docker 1.9.1 على OS X 10.10

حاولت الرجوع إلى 1.8.3 باستخدام osterman 's Makefile وأيضًا واجهت مشاكل مع مفتاح SSH:

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

تم اختباره بإجراء تثبيتات openjdk مختلفة داخل دبيان : jessie و ubuntu
OSX 10.11.1 ، boot2docker 1.9.1: توقف
OSX 10.11.1 ، boot2docker 1.9.0: يعمل
Ubuntu 14.04 مع Docker 1.9.1: يعمل

تم إنشاء boot2docker vms باستخدام:
docker-machine create -d virtualbox --virtualbox-boot2docker-url = https://github.com/boot2docker/boot2docker/releases/download/v1.9.0/boot2docker.iso
و
docker-machine create -d virtualbox --virtualbox-boot2docker-url = https://github.com/boot2docker/boot2docker/releases/download/v1.9.1/boot2docker.iso

على Ubuntu 14.04 تم تثبيت docker باتباع التوثيق على https://docs.docker.com/engine/installation/ubuntulinux/

+1 ، تشغيل docker 1.9.1 بناء a34a1d5 على OSX Yosemite 10.10.5.

لا يمكنني إعادة إنتاج هذا.

نفس المشكلة هنا.
هل هناك أي طريقة للرجوع إلى إصدار سابق على Windows؟

وجدته بنفسي.
https://github.com/docker/docker/releases

+1، docker 1.9.1 @ El Capitan

+1 ، Docker 1.9.1 على OS X 10.11.1

+1 ، Docker 1.9.1a ، OS X 10.10.5

+1 ، Docker 1.9.1 build a34a1d5 ، Windows 10

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

+1

نفس الشيء على Docker-machine على OSX 10.11.1
إصدار Docker 1.9.1 ، بناء a34a1d5
إصدار آلة الإرساء 0.5.1 (رأس)

أنا قادر على إعادة إنتاج هذا على جهاز الإرساء ، OS X 10.10.5 ، لذلك قد يكون هذا شيئًا متعلقًا بـ boot2docker. يمنحني docker top أيضًا <defunct> لعملية جافا ؛

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

/ سم مكعبtianonnathanleclairejeffdm ربما أحدكم لديه فكرة أن ننظر فيها، أو ما إلى التصحيح، لم أجد حقا شيء

ما مقدار ذاكرة الوصول العشوائي التي يمتلكها جهاز VM الخاص بك؟ يمكن أن يكون 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

يبدو أن الحاوية عالقة أيضًا ، واضطررت إلى إعادة تشغيل جهاز vm لقتله

+1 إصدار Docker 1.9.1 ، بناء a34a1d5 ، Win 7.

لقد واجهت مشاكل مماثلة تبين أنها OOM ، على الرغم من أن أمر الإحصائيات يعرض الذاكرة المتاحة للحاوية. حدثت المشكلة بعد فترة وجيزة من إظهار مدير المهام عدم وجود ذاكرة فعلية خالية ، بينما استمرت الإحصائيات في الظهور <100٪.

الشيء الغريب هو أن العملية استمرت ، لذا لم يتم قتلها. يمكنني إعادة المحاولة باستخدام a -m ، ومع ذلك ، من الغريب أن يحدث هذا في 1.9.x ، ولكن (بعد هذه المناقشة) ليس في 1.8. أيضًا ، نجح تشغيل نفس الشيء على قطرة DigitalOcean سعة 1 جيجابايت (1.9.1 أيضًا). ربما هذا الشخص يستخدم المبادلة ، يجب التحقق من ذلك

لقد ظل يحدث لي بالفعل بعد أن قمت بإلغاء تثبيت 1.9.1 وتثبيت 1.8.3. يبدو أن إلغاء التثبيت لم يكن شاملاً للغاية على نظام Mac لأن تشغيل shell كان بدون تأخير عند 1.8.3 ، على عكس التشغيل الأول العادي حيث يقوم بإعداد مفاتيح ssh والأشياء.

_USER POLL_

_ إن أفضل طريقة للحصول على إشعار عند حدوث تغييرات في هذه المناقشة هي النقر فوق الزر "اشتراك" في الجزء العلوي الأيسر.

قدّر الأشخاص المدرجون أدناه مناقشتك الكاملة مع إجراء +1 عشوائي:

@ ماتيس

31 مشاركا في هذه المسألة والعدد في ازدياد.

@ bean5 يرجى إبقاء تعليقاتك بناءة

thaJeztah لم أقصد الإساءة أو التفكيك. أقصد لفت الانتباه إلى حقيقة أن github تُظهر عدد الأشخاص المشاركين ... وقد جمعت أن GordonTheTurtle أراد إنشاء قائمة بالأشخاص الذين أجروا +1. ربما كنت في حيرة من أمري لما قصده. على أي حال ، فإنني أشاهد هذا الموضوع بترقب كبير لأنه أثر علي في أكثر من مناسبة في الأسابيع الماضية. أنا سعيد لأن لدينا معلومات من مختلف المستخدمين.

أنا قادر على تكرار هذه المشكلة في الإعداد الخاص بي (باستخدام Docker Machine على Mac).

ها هي نتائجي حتى الآن.

كما لوحظ من قبل الملصقات الأخرى ، فإن أبسط طريقة لتكرار ذلك هي استخدام boot2docker 1.9.1 ISO مع AUFS. يجب أن يؤدي هذا Dockerfile إعادة إنتاج المشكلة إلى الحد الأدنى بسرعة إلى حد ما:

FROM debian:jessie

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

بالنظر إلى dmesg ، أرى بعض أخطاء AUFS بعد محاولة مثل هذا الإصدار ، لكنني لست متأكدًا بنسبة 100٪ من ارتباطها:

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

إذا قمت بإنشاء جهاز Docker 1.9.1 يستخدم overlay كبرنامج تشغيل التخزين:

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

العملية لا تتعطل وهذا الخط يعمل بنجاح! يبدو أن AUFS و / أو النواة هي المشكلة.

boot2docker / boot2docker _did_ bump كلاً من إصداري kernel و 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 بشكل جيد ولن يتم تعليقه على boot2docker 1.9.0 ISO مع Docker 1.9.1 ثنائي. لا يبدو أن المشكلة تكمن في Docker 1.9.1 ، بل تتعلق بالبيئة التي يتم تشغيلها فيها.

أنا أستخدم الإصدار 1.9.1 مع عدم وجود مشكلة في aufs ، ولكن لدي المزيد من وحدة المعالجة المركزية / ذاكرة الوصول العشوائي / التخزين من تكوين الجهاز الافتراضي.

لقد حاولت للتو رفع الذاكرة إلى 4 غيغابايت لجهاز VM الخاص بي ، لكن ما زلت قادرًا على التكاثر

@ 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

أرى أيضًا أن بعض عمليات جافا أصبحت معطلة في حاوية. أنا قادر على إعادة إظهار هذه المشكلة من خلال الخطوات التالية
قم بتشغيل الحاوية:

docker run --rm -it myJavaContainerFromCentos7 bash

أنشئ Foo.java بما يلي:

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

يؤدي تجميعها وتشغيلها إلى عملية جافا غير صالحة ، مع نواة واحدة باستخدام وحدة المعالجة المركزية بنسبة 100٪:
javac Foo.java && java Foo

ومع ذلك ... إذا تمت إضافة System.exit(0); بعد println كل شيء على ما يرام:

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

معلومات الإصدار:
OSX 10.10.3
عامل ميناء 1.9.1
boot2docker الإصدار 1.9.1 uname -a هو "linux ci 4.1.13-boot2docker"
numproc = 1

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 output _without_ System.exit (0) ؛

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

تم تعليق العملية الآن ولكن يمكنك الدخول إلى الحاوية:

docker exec -it myContainer bash

وانظر ما يلي:

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

نظرة سريعة على الإحصائيات:

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

كل شيء يعمل بشكل جيد في 1.8.3.

+1 ، Docker الإصدار 1.9.1 ، بناء a34a1d5 ، OS X

+1 ، إصدار Docker 1.9.1 ، بناء a34a1d5 ، OS X 10.10.5 ، إصدار آلة Docker: 0.5.1 (HEAD)

+1

إصدار Docker 1.9.1 ، الإصدار a34a1d5 ، OS X 10.11.1 (15B42)

+1

إصدار Docker 1.9.1 ، أنشئ 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٪

جافا "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)

نعم ، هناك شيء ما ينفصل عن kernel 4.1.12 => 4.1.13. أستطيع أن أؤكد أن خبز boot2docker ISO للأول لا يؤدي إلى هذا الخطأ ولكن السابق يفعل.

لذلك ، لا يتعلق الأمر بشكل خاص بـ boot2docker ، ولكن يبدو أنه مرتبط بإصدار kernel الذي يتفاعل مع AUFS.

أو ربما الطريقة المحددة التي يتفاعل بها سائق AUFS في Docker مع
نواة أحدث - TBD ، من المحتمل أن تكون مع بوابة مستقرة لينكس بين 4.1.12
4.1.13: صرخة:

لدي نظرية الشعر العقلي ...

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

يؤدي الالتزام أعلاه إلى إجراء تغيير على filemap.c إلى generic_perform_write (ملف هيكلي * ملف ، هيكل 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 ميجابايت وتعيين وحدتي CPU بدلاً من 1.

يعمل:

جهاز VM: Ubuntu 14.04 (2 جيجابايت رام)
محرك Docker: 1.9.1
صورة قاعدة Docker: ubuntu: الأحدث

لا يعمل:

VM: Ubuntu 15.10 (2 جيجا بايت رام)
محرك Docker: 1.9.1،1.9.0،1.8.3
صورة قاعدة Docker: ubuntu: الأحدث ، ubuntu: 14.04

marsinvasion إن أمكن ، هل يمكنك طباعة إخراج uname -a على كلا النظامين المختبرين؟

VM: أوبونتو 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

VM: أوبونتو 15.10
Linux ubuntu 4.2.0-19-generic # 23-Ubuntu SMP الأربعاء 11 نوفمبر 11 11:39:30 بالتوقيت العالمي المنسق 2015 x86_64 x86_64 x86_64 GNU / Linux

+1
إصدار Docker 1.9.1 ، أنشئ a34a1d5 على OS X 10.11.1

تمت مصادفته على OS X 10.9.5 مع Docker 1.9.1.

مستوحاة من marsinvasion ، حصلت على حل بديل ناجح من خلال إعطاء وحدتي CPU و 4096 ميغابايت من ذاكرة الوصول العشوائي.

عفوًا ، تحدثنا قريبًا. توقف عن العمل عند تغيير Dockerfile الذي أعمل عليه وأعيد تشغيل البنية.

نرى أيضًا هذا الخطأ الجسيم (docker-machine boot2docker 1.9.1 على OS X) ، من صورة ubuntu: 15.04 المبنية سابقًا. يبدو أنه يتطلب إعادة تشغيل خادم عامل الإرساء الخاص بي لإخراج حاويات الزومبي هذه.

اعتقدت أن https://github.com/docker-library/java/issues/19 كان مرتبطًا ولكن ربما لا ، ها نحن نتعطل ، فهناك خطأ في عدم العثور على "جافا".

بدلت الخادم الخاص بي إلى التراكب كحل بديل. قبل ذلك ، تم إنشاء مجموعة من حاويات الزومبي أيضًا.

إصدار Docker 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. يعاني من هذا الخطأ مع هذا الإصدار. بالنظر إلى التعليقات ، يبدو أنني لست الوحيد.

لا لا يزال لا يبني

اضطررت إلى حذف VM في Virtualbox والبدء من نقطة الصفر حتى يعمل.

أيضًا ، حاول حذف وإنشاء جهاز افتراضي جديد عدة مرات دون جدوى.

تم تثبيته 1.9.1a ، وقام باستخدام docker-machine rm default واستخدم Docker Quickstart Terminal لإعادة إنشاء الجهاز الافتراضي. الصور المعاد إنشاؤها (المشتقة من java:7-jre ) والتي تم تشغيلها ، لا تزال لا تعمل. يستمر في العمل بشكل جيد مع آلة التراكب المبنية على النحو المقترح أعلاه:

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

^ شكرا! أستطيع أن أؤكد أن آلة التراكب تعمل.

استخدام overlay كبرنامج تشغيل تخزين المحرك يعمل أيضًا على إصلاح تعليق إيقاف تشغيل MongoDB.

يمكنك حل مشكلة فشل إنشاء ملف 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 إلى عمليات zombie java ، حتى على حاويات CentOS حيث يتم تثبيت openjdk بشكل جيد.
root 322 11.1 0.0 0 0 ? Zsl 18:43 29:48 [java] <defunct>

لا يمكنني تكوين خادم Docker الخاص بي باستخدام --engine-storage-driver overlay لأنني أقوم بإنشاء صور تستند إلى CentOS ، و overlayfs غير متوافق مع yum (https://github.com/ عامل ميناء / عامل ميناء / قضايا / 10180).

أنا متأكد من أن مستخدمي Docker لن يوصوا بهذا ، ولكن الطريقة التي تجاوزت بها مشكلة الحظر هذه هي من خلال إنشاء boot2docker.iso الذي يستخدم عامل الإرساء 1.9.1 مع AUFS أقدم قليلاً. التعليمات في https://github.com/boot2docker/boot2docker/issues/1099#issuecomment -163052066.

حاول أوراكل jdk1.7.0_75 و jdk1.8.0_65 ؛ كلاهما تعليق وإنشاء عملية جافا البائد.

من: 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_ ولكن مشكلة في https://github.com/docker/docker/issues/18180#issuecomment -161832035

• إذا كنت ترغب في البقاء على اطلاع بالتقدم المحرز ، فاستخدم زر الاشتراك في هذه الصفحة. لا تعلق إذا لم يكن لديك معلومات جديدة قد تساعد في حل هذه المشكلة.
• إذا كنت تريد المساعدة في حل هذه المشكلة ، فقد يساعدك إجراء git-bissect للنواة https://github.com/docker/docker/issues/18180#issuecomment -161834068
• تذكر أن كل تعليق سيرسل أكثر من 2000 رسالة بريد إلكتروني للمشتركين ، وسوف يموت عدد لا يحصى من الجراء: ابتسم:

اختبرت للتو Storage Driver: devicemapper (مع Server Version: 1.9.1 و kernel 4.2.6) ، والخطأ _ لا _ يتكاثر ، لذلك ما زلنا في "تفاعل غريب بين بعض التغييرات في النواة الأحدث وتصحيحات AUFS " أرض. :خائب الامل:

تم اختباره ، ولا يزال الخطأ موجودًا في نواة 4.1.14 الجديدة ، لذلك ما زلنا نلتزم ببعض الالتزام الذي تم نقله إلى 4.1.13 وهو يتفاعل بشكل غريب مع تصحيحات AUFS (ولم يحالفنا الحظ في إصلاحه بالفعل في المؤقت).

قررت أن أجربها في الكلية القديمة واستنسخت الريبو boot2docker ؛ ثم قام بتعديل aufs الالتزام في dockerfile إلى الإصدار السابق. So docker 1.9.1 kernel 4.1.13 + إصدار AUFS السابق الذي تم شحنه قبل 1.9.1. التجميع بطيء على جهازي ... هل هناك إعداد سرب عامل التحميل يمكنني تشغيله جنبًا إلى جنب مع 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 الدقيق الذي يتم تنفيذه عندما نحصل على وحدة المعالجة المركزية hang + defunct + المربوطة.

حصلت في قضية ذات صلة (توقف عملية جافا) اليوم.

البيئة المضيفة: Linux lenovo 4.2.0-19-generic # 23-Ubuntu SMP Wed 11 Nov 11 11:39:30 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux
Distro: أوبونتو 15.10
محرك Docker: 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 وإعادة إنشاء جهازك وسحب الصور مرة أخرى.
إذا ذهبت بهذه الطريقة ، هل يمكنك كتابة تقرير قصير هنا؟

لذا فقد تساءلت عن سبب حدوث ذلك على جافا فقط ، وليس أي لغات أخرى. في إحدى مشاركاتي السابقة ، تمكنت من تفصيل أبسط النُسخ عن طريق التجميع والتشغيل

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

لحالة الفشل التي أدت إلى توقف عملية جافا
وثم

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

للحالة المتوقعة (غير المنحلة).

ثم حاولت إعادة إنتاج شيء مشابه باستخدام الثعبان. لم أنجح - لكنني حاولت. بالنسبة للمهتمين ، كنت أحاول عرض ناتج الدعامة الأخير exit_group(0) = ? الذي شوهد من عملية java zombie. (زودني هذا الرابط بالكثير من المعلومات حول خيوط بايثون / seccomp / إلخ http://stackoverflow.com/questions/25678139/how-do-you-cleanly-exit-after-enabled-seccomp-in-python)

لذا ، انتقل إلى kernel land: بعد إعادة بناء boot2docker iso ، العبث بإصدارات aufs وإصدارات kernel (لم يحدث أي اختلاف حقًا) سئمت من بطء عملية التجميع باستخدام numproc = 1. لذلك قمت بتغييره إلى 6. ==> لاحظ أنه لم يعد هناك وحدة معالجة مركزية واحدة (من لديه وحدة معالجة مركزية واحدة فقط الآن؟). فجأة حالة الفشل

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

بدأت بالعمل.

من الواضح أن الشيء التالي الذي يجب تجربته هو إعادة تشغيله إلى وحدة معالجة مركزية واحدة. ==> فشل. العودة إلى عملية جافا البائدة.

لذلك أردت بعد ذلك استكشاف المزيد حول كيفية إيقاف تشغيل جافا. لم يتم تعريفه بشكل جيد. ولكن باستخدام وحدة معالجة مركزية واحدة فقط ، كان من الممكن تشغيل عملية جافا هذه بنجاح: (من فضلك لا تسخر من جافا الخاصة بي الرهيبة.)

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

هل يمكن لأي شخص آخر الرجاء تأكيد هذا السلوك؟ << السؤال الآن موضع نقاش

تحديث: حتى مع وجود أكثر من نواة واحدة ، يمكن أن تحدث عملية جافا منتهية الصلاحية. (كنت أدير كاساندرا كلي وقد حدث ذلك).

عامل ميناء ssh myVM

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

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

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

وجود نفس المشكلة المعلقة في بناء خادم bitbucket - تحديث الشهادات يعمل بشكل جيد ولكن خطاف البريد jdk يتوقف إلى الأبد. فقط مشكلة عند استخدام 1.9.1 boot2docker. تحولت إلى صورة RancherOS ولم تواجه أية مشاكل. OSX 10.10.

مع El Capitan و Docker 1.9.1 و Ubuntu 14.04.1 ، أحصل على: إعداد شهادات ca- جافا التي تتوقف بلا حدود.

تراجعstremlenye إلى 1.9.0. لا يزال معلقًا.

brunoborges docker 1.9.0 أو boot2docker.iso 1.9.0؟

stremlenye Docker 1.9.0 ... ما هي التعليمات للحصول على boot2docker.iso 1.9.0 في نظامي؟

brunoborges تحقق من هذا التعليق أعلاه:

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

يشرح carsten-ulrich-saitow-ag كيفية إنشاء آلة إرساء جديدة باستخدام الإصدار 1.9.0 iso باستخدام علامة --virtualbox-boot2docker-url. أنقذت تلك النصيحة لحم الخنزير المقدد! بمجرد القيام بذلك ، يمكنني مرة أخرى تثبيت JRE RPM في حاوياتي.

@ mobsy74 حاول stremlenye مع boot2docker 1.9.0 ويتوقف أحيانًا.

brunoborges شكرا لمحاولة ذلك. لذلك سألتزم بـ 1.8.3 حتى يتم إصلاح هذا الخطأ.

stremlenye تقصد boot2docker 1.8.3؟

brunoborges نعم

مرحبا،
كان لي نفس القضية.
تم حل المشكلة عند تخفيض مستوى أدوات عامل الإرساء من 1.9.1 إلى 1.9.0
https://github.com/docker/toolbox/releases/download/v1.9.0/DockerToolbox-1.9.0.pkg

أدى تمكين cpus المتعددة (في جهاز عامل الإرساء) إلى حل هذا الأمر بالنسبة لي.

--virtualbox-cpu-count=4

heiths هل يمكنك مشاركة إصدارات أدوات عامل

يجب أن يبتعد imho و boot2docker عن aufs إلى أحد برامج تشغيل التخزين الأخرى المتاحة. هناك سبب وجيه لعدم وصول aufs إلى نواة لينكس.

robvanmieghem لكل سائق حدوده. Aufs مستقر تمامًا بشكل عام ، وتواجه التراكبات بعض مشكلات الحظر (حسب الاستخدام)

brunoborges DockerToolbox-1.9.1c - لقد نجح هذا الأمر بالنسبة لي على windows و osx.

thaJeztah لم

هناك العديد من الآراء حول هذا الأمر حيث توجد مجموعات من التوزيعة ونظام الملفات :) لن يكون حل واحد مثاليًا لجميع حالات الاستخدام ، لذا أعتقد أن أفضل قرار اتخاذه هو تقديم أفضل ، بروح المصدر المفتوح ولينكس دعم خيارات متعددة للتوزيعات. لدينا بالفعل خيار Boot2Docker أو RancherOS وأعتقد أن بعض العمل قد تم لإعادة بناء boot2docker على قاعدة توزيعة ديبيان. ستدعم docker-machine ubuntu على السحابة والمعدن العاري ، لذلك أنا متأكد من أن vm iso القائم على ubuntu لن يكون من الصعب تجميعه مع الآخرين مثل واحد مبني على جبال الألب أو CoreOS وما إلى ذلك. اختيار نظام الملفات - مرة أخرى ، يقدم RancherOS الآن ZFS كتثبيت اختياري بينما تستخدم CoreOS لاستخدام BTRFS افتراضيًا وأعتقد أنه لا يزال خيارًا ، وبدءًا من kernel 3.19 ، فإن Ubuntu يدعم OverlayFS خارج الصندوق - أي شخص مستعد لتطبيق Snappy Core صورة b2d؟ ؛)

الآن ، إذا تمكنا فقط من توحيد تسمية معلمة docker-machine وإزالة الإشارات إلى 'boot2docker' لتقليل الارتباك - فإن استخدام معلمة boot2docker-url لتثبيت RancherOS غير بديهي إلى حد ما ؛)

@ far-blue +1

heiths +1. هذا حل لي أيضًا على OSX مع 1.9.1c

يؤدي تعيين وحدة المعالجة المركزية إلى> 1 إلى تجنب المشكلة بالنسبة لي. 1.9.1c لم يساعد.

heithsfredriksvensson أنا حقيقة كان لي هذه المسألة تظهر بشكل عشوائي على البيئة حاويات متعددة وحاولت أيضا لزيادة كمية وحدات المعالجة المركزية (الذاكرة أيضا، ولكن هذا ليس نقطة واحدة). أظهرت دورتان من stop <all> / start <all> أن المشكلة لم تختف. أنصحك بالتحقق من بيئتك بنفس الطريقة للتأكد من أن الحل مستقر بالنسبة لك.
timechanter / cc

أوه ، بالتأكيد لم يذهب. لكن احتمال حدوث تعليق بنسبة 10٪ مقابل تعليق بنسبة 100٪ يمكن التحكم فيه على الأقل على المدى القصير.

عملتheiths --virtualbox-cpu-count=4 أيضًا بالنسبة لي.

timechanter +1

OSX 10.10.5

تم إلغاء تثبيت مربع أدوات Docker 1.9.1. خفضت إلى Docker toolbox 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_ ولكن مشكلة في https://github.com/docker/docker/issues/18180#issuecomment -161832035

• إذا كنت ترغب في البقاء على اطلاع بالتقدم المحرز ، فاستخدم زر الاشتراك في هذه الصفحة. لا تعلق إذا لم يكن لديك معلومات جديدة قد تساعد في حل هذه المشكلة.
• إذا كنت تريد المساعدة في حل هذه المشكلة ، فقد يساعدك إجراء git-bissect للنواة https://github.com/docker/docker/issues/18180#issuecomment -161834068
• تذكر أن كل تعليق سيرسل أكثر من 2000 رسالة بريد إلكتروني للمشتركين ، وسوف يموت عدد لا يحصى من الجراء: ابتسم:

externlstremlenye شكرا.

بالنظر إلى مكدسات 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-CPU الفعلي. (على الرغم من أن الاحتمال <1٪.)
لذا فإن --virtualbox-cpu-count=2 يضمن _NOT_ أنه يمكنك تجنب الخطأ.

لاحظ أن عدد وحدات المعالجة المركزية لا يزال مهمًا.
يمكنني أن أصيب الخلل بشكل حاسم عند تشغيل 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 كعملية init في ذلك الوقت. https://github.com/docker/docker/issues/18180#issuecomment- 166186061)

https://github.com/docker/docker/issues/18180#issuecomment -161843456
andrewgdavis ، أنت على حق تمامًا!

يبدو أن الخطأ هو انحدار ناتج عن الالتزام 296291cd بـ Linux kernel ( mm/filemap.c ).

لقد صنعت Boot2Docker ISO ( 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 إلى شجرة kernel 3.19: http://kernel.ubuntu.com/git/ubuntu/ubuntu-vivid.git/commit/؟id=6b08592b8acc677d5b9bb7986343fdd6e0ad3303

AkihiroSuda نجاح باهر ، شكرا لك على العثور! ما هي الخطوات التالية؟ هل ينبغي إعادة هذا التصحيح ، أم أن هناك طريقة لتحسين التصحيح؟ هل تفكر في إرسال تصحيح إلى kernel upstream؟

AkihiroSuda ، الإصلاح الخاص بك يعمل مثل السحر. شكر!

تضمين التغريدة

هذا ليس سؤالا سهلا.
بدون الالتزام 296291cd ، يمكن أن يكون sendfile(2) قابل للقتل.
أخشى أن يتسبب هذا sendfile القابل للقتل في مشكلة أمنية (على سبيل المثال ، هجوم استنفاد من قبل مستخدم مجهول) في بعض البيئات المعينة.

أحاول تحسين الالتزام 296291cd ، لكن الأمر قد يستغرق بعض الوقت.

على أي حال ، لقد أبلغت عن هذا الخطأ إلى kernel 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 hm ، حسنًا ، يبدو وكأنه مشكلة ، نعم. شكرًا جزيلاً على حاوية إعادة التحميل والبحث ؛ على الأقل هناك مهمة محددة للغاية للعمل عليها ، ونأمل أن ينضم إليها أشخاص آخرون ، في محاولة للمساعدة في إيجاد حل. شكرًا جزيلاً لك على عملك الممتاز حتى الآن.

لقد أصبت على OS X El Capitan Darwin Kernel الإصدار 15.2.0
إصدار Docker 1.9.1 ، الإصدار d12ea79c9de6d144ce6bc7ccfe41c507cca6fd35
boot2docker 1.9.1.1

عملت الرجوع إلى boot2docker 1.9.0 مع الأوامر أدناه بالنسبة لي:

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

تضمين التغريدة
AUFS سوف يدعم 296291cd.
http://article.gmane.org/gmane.linux.file-systems.aufs.user/5343

لذا فإن الخطوة التالية هي انتظار تحديث AUFS.

أنت بطل ،AkihiroSuda! شكرًا لك على العمل مع المنبع لإيجاد حل لهذه المشكلة! :قلب:

إذا أراد أي شخص تطبيق AkihiroSuda fix ، فهذا يعمل مثل السحر:

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 ، فإن الرجوع إلى إصدار kernel 3.13.0-71 أو أقدم يجب أن يحل المشكلة. تم backported 296291cd بعد ذلك .

بفضل ebpitts على النصيحة ، إليك الخطوات النسبية إلى حد ما لخفض إصدار Ubuntu 14.04 kernel إلى 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 ("Setting up ca -ificates-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 إلى إصدار kernel 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 هل أنت متأكد من أن تخفيض إصدار kernel على Ubuntu هو الحل؟

مثير للاهتمام ، حتى عند تعيين برنامج تشغيل التخزين على devicemapper صراحة /var/default/docker :

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

وأعد تشغيل خدمة Docker ، بتشغيل docker info :

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

ما زلت معلقة في صورة الاختبار akihirosuda/test18180:latest .

لقد رجعت إلى Docker 1.8.3 (ليس بالسهولة بدون apt-get ) في صندوق Ubuntu 14 الخاص بي باستخدام ثنائي خام ، إليك الخطوات ... لأي شخص آخر ... لقد عدت إلى العمل (من فضلك لاحظ أنني قمت أيضًا بخفض إصدار kernel إلى 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 . ثم قمت بتعيينه للتشغيل عند بدء التشغيل كجذر 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 على محرك احتياطي ، ذلك لا تزال صورة

تضمين التغريدة
شكرًا لك على اختبار صورتي test18180 .

النتيجة ليست غريبة.
الشيك الثاني ( Checking whether sendfile(2) is killable. ) معلق في النواة القديمة.
أنت بحاجة إلى نواة أحدث مع 296291cd لاجتياز الاختبار الثاني.

| AUFS؟ | يتضمن Kernel 296291cd؟ | النتيجة المتوقعة |
| --- | --- | --- |
| ص | ص | توقف (الشيك الأول: Checking whether hitting docker#18180. ) |
| ص | ن | توقف (الشيك الثاني: Checking whether sendfile(2) is killable. ) |
| ن | ص | تمرير |
| ن | ن | توقف (الشيك الثاني: Checking whether sendfile(2) is killable. ) |

cfstras شكرًا لك ،

cfstras ، إنها قابلة للتكرار ، وفتحت # 19073.

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

تعديل:
في وقت سابق كنت مخطئًا بشأن سبب عدم عمل عامل الإرساء بعد تغيير إصدارات kernel ، ولكن يمكنني تأكيد تثبيت الحزمة الإضافية لنواة بلدي ثم إعادة تثبيت عامل الإرساء حل هذه المشكلة بالنسبة لي:

sudo apt-get remove 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 kernel في أي يوم من أيام الأسبوع.

dschep لاحظ للآخرين أن التبديل إلى OverlayFS يتطلب إصدار kernel 3.18 + على Linux ، وكما هو مقتبس في صفحة Docker ، _ كما هو واعد مثل OverlayFS ، فإنه لا يزال صغيرًا نسبيًا.

mikeatlas أعتقد أن هذا هو أكبر قيد حتى الآن على OverlayFS: "_ لذلك ، من غير المحتمل أن يعمل استخدام yum داخل حاوية على مضيف Docker باستخدام برنامج تشغيل تخزين التراكب دون تنفيذ الحلول البديلة ._".

يتم حاليًا تصحيح brunoborges yum للعمل على التراكبات ، لذلك ، قريبًا ، يجب أن تتمكن الإصدارات الأحدث من yum من العمل على التراكبات (لا تزال هناك بعض المشكلات ، لذلك يعتمد ذلك على حالة الاستخدام / الموقف الذي تواجهه معهم). يمكن أن يكون الاستخدام المفرط inode مشكلة أخرى.

أعتقد أنني أواجه هذه المشكلة أيضًا. يذكر تتبع المكالمة المظهر ، لكن تعطيل apparmor لا يحدث فرقًا. باستخدام devicemapper جعل المشكلة تختفي.

dmesg:

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

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

ps auxfg:

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

تم إصلاح هذا في AUFS upstream - تم تحديث 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 upstream - تم تحديث boot2docker ليشمل الإصلاح (الذي سيخرج مع الإصدار التالي) ، ويجب على أي مستخدم غير boot2docker المتأثر تطبيق إصدار AUFS المحدث. : +1:

لطيف.

هل تم استخدام إصدار عربات التي تجرها الدواب من AUFS على Docker Hub؟

tianon "تطبيق إصدار AUFS المحدث" يعني للمستخدمين الذين لا يستخدمون boot2docker (كل شخص يقوم بتشغيل محرك docker _ ليس قيد التطوير على نظام التشغيل Mac OS X ، والذي تم تصميم b2d من أجله بشكل أساسي) أنه سيتعين عليهم انتظار تحديث Linux kernel تصحيح AUFS هذا ... أو ... بالنظر إلى عدد عمليات التثبيت / الأشخاص الذين يبدو أنهم تأثروا ، فهل يمكن لأي شخص توفير إرشادات مبسطة / الحد الأدنى حول كيفية تصحيح AUFS إلى 4.1.13+؟ دليل 4.1.13+ هو بالتأكيد غير تافه للقراءة ؛ إن ترقيع نواة لينكس من أجل هذا الإصلاح المحدد ليس بالضبط لضعاف القلوب.

فقط أفهم أنه إذا قمت بإنشاء هذا boot2docker.iso ووضعه في ~/.docker/machine/cache وأنشئ VM جديدًا باستخدام docker-machine VM سيستخدم هذه النسخة الجديدة من boot2docker .

فقط حتى أفهم ما إذا كنت قد أنشأت هذا boot2docker.iso ووضعته في ~ / .docker / machine / cache وأنشئ جهاز VM جديدًا مع جهاز الإرساء الذي سيستخدم VM هذه النسخة الجديدة من 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 ديبيان ويزي وأوبونتو 15.04

إصدار jakirkham عبارة عن دورة مدتها شهران ، لكننا سنصدر 1.10-rc1 قريبًا جدًا ، سيكون لدى boot2docker إصدار rc1 لذلك أيضًا.

أوه ، آسف ، يجب أن تكون قد خلطت. شكرا لتوجيهي لي ، tiborvass. هل فهمت ذلك ، shusso؟

jakirkham فعلت ، شكرًا: +1:

لقد تمكنت من إنشاء Virtualbox لمضيف جهاز الرصيف باستخدام هذا الإصلاح:

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

حاليًا ، يبدو أن مضيفي جهاز docker-machine الذين أقوم بإنشائهم على محرك حساب Google ، باستخدام خيار محرك google ، لديهم هذه المشكلة. لا يوجد خيار مع برنامج تشغيل google لتحديد ملف .iso مختلف ، لذلك لا يمكنني استخدام الإصلاح أعلاه في حساب google.

لا أحد يعرف من الحل؟ أو إذا كانت Google على علم بالمشكلة ، أو أين يجب أن أقدم تقرير خطأ لهم.

هل برنامج تشغيل آلة docker-machine من Google يتم صيانته بواسطة عامل ميناء أم بواسطة Google؟

يمكن العثور على السائق هنا. https://github.com/docker/machine/tree/master/drivers/google

أعتقد أن صورة VM التي يتم تشغيلها على 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 - engine-storage-driver overlay. تراكب محرك التخزين

يبدو أن هناك أيضًا خيار "--google-machine-image" متاح لبرنامج Google Driver لجهاز docker-machine. الامر:

قائمة صور حساب $ gcloud

يسرد الصور العامة المتاحة. لقد لاحظت أنه تم مؤخرًا طرح ماكرة جديدة في أوبونتو.

فقط للتأكيد:

$ docker-machine create -d google - engine-storage-driver overlay. تراكب محرك التخزين

عمل. سأحقق أيضًا في إنشاء صورة مخصصة للجهاز باستخدام boot2docker الثابت ، ومحاولة توصيل ذلك بجهاز عامل الإرساء.

لأي شخص يضرب هذا على boot2docker ، يرجى إعطاء RC أكثر من
https://github.com/tianon/boot2docker-legacy/releases/tag/v1.10.0-rc1 أ
اطلاق النار. : +1:

tianon أختبرها بالصورة التالية trecloux / docker-java-zombie
وهي تبدو جيدة .... لكنها لا تزال معلقة مع صورة أكيهيروسودا / 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 ، أي فكرة عن إصدار kernel الذي سيتم إصلاحه؟ يبدو أن 3.13.0-71 تعمل ، ويبدو أن 3.13.0-74 و 3.13.0-76 مكسورة ...

نفس المشكلة هنا ؛ إذن لا يوجد حل سهل لهذا؟
هل تم إصلاح ذلك في إصدار RC؟ جرب ذلك الآن. على الرغم من أنه ربما يسبب مشاكل أخرى.

أحدث الحلول السريعة (التحديث: 21 يناير 15:33 بالتوقيت العالمي المنسق)

| ديسترو | الحل |
| --- | --- |
| عام | استخدم devicemapper / overlay / btrfs (لكنه قد يسبب مشكلة أخرى ..) |
| Boot2Docker | : white_check_mark: قم بالترقية إلى v1.10.0 -rc1 |
| نظام التشغيل Ubuntu 14.04LTS | : arrow_down: قم بإرجاع kernel إلى الإصدار 3.13.0-71 أو أقدم |
| أوبونتو 15.04 | : arrow_down: قم بإرجاع kernel إلى الإصدار 3.19.0-39 أو أقدم (: تحذير: لم يتم اختباره) |
| أوبونتو 15.10 | : arrow_down: قم بإرجاع kernel إلى إصدار 4.2.0-18 أو أقدم |
| ديبيان 7/8 | : arrow_down: قم بإرجاع kernel إلى الإصدار 3.16.7-ckt11 للإصدار 3.16.0 ( apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 ) أو أقدم |
| ديبيان 9 | : white_check_mark: (لا يدعم AUFS منذ kernel 3.18-1 ~ exp1) |
| جينتو | : white_check_mark: الترقية إلى أحدثها (: تحذير: لم يتم اختباره) |
| RHEL / CentOS | : white_check_mark: (لا يدعم AUFS) |
| openSUSE | : white_check_mark: (لا يدعم AUFS) |

يقوم الموزعون بإصدار التذاكر

| ديسترو | الحالة | URL المشكلة |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: مغلق | https://github.com/boot2docker/boot2docker/pull/1113 |
| أوبونتو | : white_medium_square: قيد التقدم | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| دبيان | لم يتم تأكيده بعد | https://bugs.debian.org/cgi-bin/bugreport.cgi؟bug=812207 |

AkihiroSuda v1.10.0 -rc1 لا

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

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

بعد بدء الدعامة على العملية البائدة بعد مرور بعض الوقت ، ظهر هذا ، ولكن بعد ذلك لا يزال الزومبي موجودًا:

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 -p 23810

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

تضمين التغريدة
هل يمكنك الحصول على مكدسات LWP كما هو الحال في https://github.com/docker/docker/issues/18180#issuecomment -166186061؟
أيضا ، ما هو cmdline الخاص بك ونسخة phantomjs؟

بالتأكيد ، الإصدار phantomjs: 1.9.2

كمدلاين

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

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

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

وكذلك مجموعة المهام:

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

أيضًا لإضافة معلومات النظام:

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

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

wzrdtales هل تستخدم Docker (وليس Boot2Docker) v1.10.0-rc1 على دبيان؟
لا يعمل لأن المشكلة هي خلل في النواة وليس في Docker.

أنا أبحث في نواة دبيان وسوف أقوم بتحديث القائمة https://github.com/docker/docker/issues/18180#issuecomment -173436661.

AkihiroSuda y ، إنه موجود مباشرة على دبيان. لقد أشرفت على نقطة دبيان في قائمتك ، شكرًا للإشارة إلى :)

بالنسبة إلى دبيان ، يجب ألا نستخدم النوى المستندة إلى v3.16.7-ckt20
http://kernel.ubuntu.com/git/ubuntu/linux.git/tag/؟h=linux-3.16.y&id=v3.16.7-ckt20
http://kernel.ubuntu.com/git/ubuntu/linux.git/commit/؟h=linux-3.16.y&id=475a23000dd8d2f264bab9d6eb71a2a6b9d4de72

wzrdtales لقد قمت بتحديث القائمة ، يرجى استخدام ckt11 kernel.

AkihiroSuda : FWIW ، أعتقد أن التوصية بالرجوع إلى v3.16.7-ckt11 تعرضك لخطر CVE-2016-0728 ، والذي له تصعيد عام معروف. لقد قمت للتو باختبار اتصال https://bugs.debian.org/cgi-bin/bugreport.cgi؟bug=812207 ، ولكن لمعلوماتك قبل الرجوع إلى إصدار أقدم.

zmerlynn شكرا لك على الإشارة إلى ذلك!

أحدث الحلول السريعة (التحديث: 26 يناير 1:49 بالتوقيت العالمي المنسق)

| ديسترو | الحل |
| --- | --- |
| عام | استخدم devicemapper / overlay / btrfs (لكنه قد يتسبب في مشكلة أخرى ..).
إذا كان بإمكانك ترقية AUFS وبناء النواة يدويًا ، فيمكنك أيضًا استخدام AUFS v20160111 أو إصدار أحدث. |
| Boot2Docker | : white_check_mark: قم بالترقية إلى v1.10.0 -rc1 |
| نظام التشغيل Ubuntu 14.04LTS | : arrow_down: قم بإرجاع kernel إلى الإصدار 3.13.0-71 أو أقدم |
| أوبونتو 15.04 | : arrow_down: قم بإرجاع kernel إلى الإصدار 3.19.0-39 أو أقدم (: تحذير: لم يتم اختباره) |
| أوبونتو 15.10 | : arrow_down: قم بإرجاع kernel إلى إصدار 4.2.0-18 أو أقدم |
| ديبيان 7/8 | : arrow_down: قم بإرجاع kernel إلى الإصدار 3.16.7-ckt11 للإصدار 3.16.0 ( apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 ) أو أقدم |
| ديبيان 9 | : white_check_mark: (لا يدعم AUFS منذ kernel 3.18-1 ~ exp1) |
| جينتو | : white_check_mark: الترقية إلى أحدثها (: تحذير: لم يتم اختباره) |
| RHEL / CentOS | : white_check_mark: (لا يدعم AUFS) |
| openSUSE | : white_check_mark: (لا يدعم AUFS) |

: تحذير: الرجوع إلى إصدار أقدم من kernel يمكن أن يكون مخاطرة أمنية (على سبيل المثال ، CVE-2016-0728)

يقوم الموزعون بإصدار التذاكر

| ديسترو | الحالة | URL المشكلة |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: مغلق | https://github.com/boot2docker/boot2docker/pull/1113 |
| أوبونتو | : white_medium_square: قيد التقدم | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| دبيان | : white_medium_square: قيد التقدم | https://bugs.debian.org/cgi-bin/bugreport.cgi؟bug=812207 |

لقد واجهنا أيضًا هذه المشكلة ، mongod عالق في حالة R يعمل مع وحدة المعالجة المركزية بنسبة 100٪.

إليك الحيلة الحقيقية للحصول على تتبع مكدس صحيح يقودني هنا:

صدى "l"> / 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"

أوصي بإيقاف خدمة docker ، ومسح مجلد docker على / var / lib ثم إضافة الخط وإعادة تشغيل خدمة docker.

@ Referup-tarantegui تمامًا مثل التنبيه ، يُعتبر برنامج التشغيل devicemapper ضعيفًا للغاية بالنسبة للأداء ما لم يتم تركيبه مباشرة على أقراص فعلية حقيقية. نرى
https://jpetazzo.github.io/assets/2015-03-03-not-so-deep-dive-into-docker-storage-drivers.html#43 https://jpetazzo.github.io/assets/2015 -03-03-not-so-dive-in-docker-storage-drivers.html # 44
و
https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/ "أداء مخطط الجهاز و Docker"

هناك نسخة B للإصدار المرشح 2

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

تحديث الجدول حول أوبونتو.

أحدث الحلول السريعة (التحديث: 3 فبراير 6:30 بالتوقيت العالمي المنسق)

| ديسترو | الحل |
| --- | --- |
| عام | استخدم devicemapper / overlay / btrfs (لكنه قد يتسبب في مشكلة أخرى ..).
إذا كان بإمكانك ترقية AUFS وبناء النواة يدويًا ، فيمكنك أيضًا استخدام AUFS v20160111 أو إصدار أحدث. |
| Boot2Docker | : white_check_mark: قم بالترقية إلى v1.10.0 -rc3 |
| نظام التشغيل Ubuntu 14.04LTS | : white_check_mark: قم بترقية kernel إلى 3.13.0-77.121hf1533043v20160201b1 (PPA) |
| أوبونتو 15.04 | : white_check_mark: ترقية kernel إلى 3.19.0-49.55hf1533043v20160201b1 (PPA) |
| أوبونتو 15.10 | : white_check_mark: ترقية kernel إلى 4.2.0-27.32hf1533043v20160201b1 (PPA) |
| ديبيان 7/8 | : arrow_down: قم بإرجاع kernel إلى الإصدار 3.16.7-ckt11 للإصدار 3.16.0 ( apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 ) أو أقدم |
| ديبيان 9 | : white_check_mark: (لا يدعم AUFS منذ kernel 3.18-1 ~ exp1) |
| جينتو | : white_check_mark: الترقية إلى أحدثها (: تحذير: لم يتم اختباره) |
| RHEL / CentOS | : white_check_mark: (لا يدعم AUFS) |
| openSUSE | : white_check_mark: (لا يدعم AUFS) |

يقوم الموزعون بإصدار التذاكر

| ديسترو | الحالة | URL المشكلة |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: مغلق | https://github.com/boot2docker/boot2docker/pull/1113 |
| أوبونتو | : white_medium_square: قيد التنفيذ (الوقت المقدر للوصول: 20 فبراير) | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| دبيان | : white_medium_square: قيد التقدم | https://bugs.debian.org/cgi-bin/bugreport.cgi؟bug=812207 |

AkihiroSuda ، أعتقد أنك قصدت v1.10.0 -rc2 لـ 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 PPAs. على سبيل المثال ، بالنسبة لـ 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 ، ثم إعادة التشغيل في بنية kernel الجديدة المصححة. إذا لم تكن قد قمت بذلك من قبل ، فإليك دليل حول كيفية تعيين نواة افتراضية مختلفة في اليرقة .

يمكنني أن أؤكد أن هذه المشكلة غير موجودة في Docker 1.10.0 ، مما أدى إلى إصلاح وضعي على OS X 10.11 أيضًا. وإلا كنت سأقوم بالتخفيض إلى 1.9.0.

ما زلت أتلقى مشكلة الحاوية / العملية المعلقة java على Docker 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 أنت تدير دبيان 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

ساعة من googlening النشط للعثور على الحزمة 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 .

تم التأكيد على أن تثبيت kernel الجديد من PPA قد أصلح المشكلة بالنسبة لي (Ubuntu 14.04.3 / Kernel 3.13.0-78-generic / Docker 1.9.1)
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043

هل حصل أي شخص على تعليمات الرجوع إلى إصدار أقدم للعمل مع Debian (وليس Ubuntu)؟ أتساءل عما إذا كان سبب فشل apt-get update مع الخطأ أدناه (بعد إضافة ppa repo):

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

هل هذه حزم ubuntu فقط متاحة على https://launchpad.net/~chiluk/+archive/ubuntu/1533043؟ حسنًا ، أنا في حيرة من أمري ، أعتقد أن Ubuntu كان مبنيًا على Debian.

jamshid Ubuntu ppa لا يدعم دبيان.

إذا لم يعد الإصدار 3.16.7-ckt11-1 + deb8u3 متاحًا للأسف ، فيمكنك تصحيح أحدث نواة: https://bugs.debian.org/cgi-bin/bugreport.cgi؟bug=812207#47

(يمكنني تحميل حزمة deb ، إذا احتاجها شخص ما)

إذا احتاج شخص ما إلى kernel ، فقد قمت بتحميله هنا ، فهو أحدث قليلاً من 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

مع بضعة أسطر في ملف الرصيف ، حصلت على عملية init جيدة قادرة على إزالة الزومبي.
سيسمح هذا بتجنب الانتقال إلى devicemapper.

في صحتك،
فرانشيسكو

لذا ، أستخدم تيني. ومع ذلك ، لم يساعدني ذلك هنا لأن المشكلة التي واجهتها كانت أثناء إنشاء الصورة.

أيضًا ، عند تشغيل الحاوية ، أستخدم التيني ، لكن هذا لا يزال يؤثر علي.

تضمين التغريدة
شكرًا لك على المعلومات ، لكن مشكلة الزومبي التي يمكن لـ 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)

AkihiroSudajakirkham أنسى أن أذكر أننا لا تواجه هذه المشكلة عند بناء الصورة. نقوم ببناء صورة أساسية جدًا ومن ثم يتم تفويض منطق التزويد إلى مجموعة من البرامج النصية غير الصالحة. أثناء تقديم إحدى العمليات (kafka) تستخدم للتعليق. يبدو أن 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

ههههههههههه
أنا أيضا لا أستطيع الوصول إلى الصفحة.
أعتقد أن chiluk يعيد صنع الحزم. يمكنك أن تسأله على 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

بعد ذلك ، دعنا نثبت kernel المحدث:

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

ودعونا نعيد التشغيل

$ sudo shutdown -r now

بعد إعادة التشغيل ، يمكننا تأكيد أن الأحدث تعمل الآن على أحدث نواة:

$ uname -r
3.19.0-50-generic

شكرًا vpetersson ، أحاول معرفة ما سيحدث عند إصدار هذا الإصدار من النواة ، فهل سيتم استبدال التثبيت المقترح أم يجب عليك القيام بشيء للعودة إلى الوضع الطبيعي من فضلك؟

IainColledge نعم ، أتخيل أن الأمر سيكون كذلك ، لكنني لست متأكدًا تمامًا.

تم تحديث الجدول حول Ubuntu و Debian.

أحدث الحلول السريعة

| ديسترو | الحل |
| --- | --- |
| عام | استخدم devicemapper / overlay / btrfs (لكنه قد يتسبب في مشكلة أخرى ..).
إذا كان بإمكانك ترقية AUFS وبناء النواة يدويًا ، فيمكنك أيضًا استخدام AUFS v20160111 أو إصدار أحدث. |
| Boot2Docker | : white_check_mark: حسن بحثك الى v1.10.0 أو في وقت لاحق |
| نظام التشغيل Ubuntu 14.04LTS | : white_check_mark: قم بترقية kernel إلى 3.13.0-79.123 أو أحدث |
| أوبونتو 15.04 | : white_check_mark: قم بترقية kernel إلى 3.19.0-51.57 أو أحدث |
| أوبونتو 15.10 | : white_check_mark: قم بترقية kernel إلى 4.2.0-30.35 أو أحدث |
| ديبيان 7/8 | : arrow_down: الرجوع إلى إصدار أقدم من kernel إلى الإصدار 3.16.7-ckt11 للإصدار 3.16.0 أو أقدم ( أرشيف dpkg بواسطةwzrdtales) |
| ديبيان 9 | : white_check_mark: (لا يدعم AUFS منذ kernel 3.18-1 ~ exp1) |
| جينتو | : white_check_mark: الترقية إلى أحدثها (: تحذير: لم يتم اختباره) |
| RHEL / CentOS | : white_check_mark: (لا يدعم AUFS) |
| openSUSE | : white_check_mark: (لا يدعم AUFS) |

يقوم الموزعون بإصدار التذاكر

| ديسترو | الحالة | URL المشكلة |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: مغلق | https://github.com/boot2docker/boot2docker/pull/1113 |
| أوبونتو | : white_check_mark: مغلق | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| دبيان | : white_medium_square: قيد التقدم | https://bugs.debian.org/cgi-bin/bugreport.cgi؟bug=812207 |

شيء اخر؛ لقد أدرجت بعض الأخطاء المعروفة حول برامج تشغيل التخزين: https://github.com/AkihiroSuda/docker-issues

فقط في حالة رغبة شخص ما في الحصول على أحدث إصدار من "linux_3.16.7-ckt20-1 + deb8u3" debian kernel مع التصحيحات المذكورة سابقًا - لقد قمت بإنشائه يدويًا وهو موجود على https://fxposter.org/linux-image-3.16 .0-4-amd64_3.16.7-ckt20-1 + deb8u3a ~ test_amd64.deb.

رائعة حقا! أواجه هذه المشكلة منذ بضعة أسابيع حتى الآن ، وأعتقد أن الإصلاح الخاص بـ Ubuntu قد تم إصداره بالأمس: P

التأكيد على أن التحديث الأخير 14.04LTS kernel إلى 3.19.0-51 يضع حداً لـ java zombies. شكر!

دعمت دبيان هذه المشكلة.

أحدث الحلول السريعة

| ديسترو | الحل |
| --- | --- |
| عام | استخدم devicemapper / overlay / btrfs (لكنه قد يتسبب في مشكلة أخرى ..).
إذا كان بإمكانك ترقية AUFS وبناء النواة يدويًا ، فيمكنك أيضًا استخدام AUFS v20160111 أو إصدار أحدث. |
| Boot2Docker | : white_check_mark: حسن بحثك الى v1.10.0 أو في وقت لاحق |
| نظام التشغيل Ubuntu 14.04LTS | : white_check_mark: قم بترقية kernel إلى 3.13.0-79.123 أو أحدث |
| أوبونتو 15.04 | : white_check_mark: قم بترقية kernel إلى 3.19.0-51.57 أو أحدث |
| أوبونتو 15.10 | : white_check_mark: قم بترقية kernel إلى 4.2.0-30.35 أو أحدث |
| ديبيان 7 | : white_check_mark: قم بترقية kernel إلى 3.2.73-2 + deb7u3 (من حزمة linux-image-3.2.0-4-amd64) أو أحدث |
| ديبيان 8 | : white_check_mark: قم بترقية kernel إلى 3.16.7-ckt20-1 + deb8u4 (من حزمة linux-image-3.16.0-4-amd64) أو أحدث |
| ديبيان 9 | : white_check_mark: (لا يدعم AUFS منذ kernel 3.18-1 ~ exp1) |
| جينتو | : white_check_mark: الترقية إلى أحدثها (: تحذير: لم يتم اختباره) |
| RHEL / CentOS | : white_check_mark: (لا يدعم AUFS) |
| openSUSE | : white_check_mark: (لا يدعم AUFS) |

يقوم الموزعون بإصدار التذاكر

| ديسترو | الحالة | URL المشكلة |
| --- | --- | --- |
| Boot2Docker | : white_check_mark: مغلق | https://github.com/boot2docker/boot2docker/pull/1113 |
| أوبونتو | : white_check_mark: مغلق | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| دبيان | : white_check_mark: مغلق | https://bugs.debian.org/cgi-bin/bugreport.cgi؟bug=812207 |

عملت ترقية نواة 14.04LTS بالنسبة لي: +1:

أنا على OSX على الإصدار 1.10.2 من Boot2Docker ، بناء Master: 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 تم إصلاح المشكلة في kernel 3.13.0-79.123 (يبدو أن مشكلتك هي 3.13.0-77)

هل يمكن حل هذه المشكلة بالفعل من خلال ترقية Kernel؟ نواجه نفس المشكلة مع 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 لإصدارات kernel اللازمة لإصلاح هذه المشكلة