मैं उसी समस्या का सामना कर रहा हूं। मैं जांच कर रहा हूं।

हम एक ही समस्या का सामना कर रहे हैं।

हाँ, यह एक समस्या है। मैंने 1.8.3 पर डाउनग्रेड किया और सभी समस्याओं को हल किया। अब मैं एक वर्कअराउंड की जांच कर रहा हूं। यहाँ पोस्ट करेंगे! टी.के.एस

मैं एक ही मुद्दे के साथ कर रहा हूँ 1.9.1a

मेरे पास डॉकटर 1.8.3 है, इसलिए हो सकता है कि डॉकटर के एक अलग संस्करण को स्थापित करने की प्रक्रिया स्थिति को ठीक कर दे। @bsao।

इस संस्करण के साथ एक ही मुद्दा रहा 1.9.1, निर्माण a34a1d5

क्या आप इसे केवल boot2docker पर देख रहे हैं?

मैं auf के साथ या मेरी मशीन पर एक स्टॉक ubuntu पर रेपो नहीं कर सकता। मुझे boot2docker के साथ देखने की कोशिश करें कि क्या मैं वहां रेपो कर सकता हूं।

Ubuntu के लिए Docker 1.9.1 में +1 14.10

यह एक ऐसा मुद्दा है जो काम के लिए वीपीएन चालू करने के बाद मुझे दिखाई देने लगा। इसके बाद भी मैंने वीपीएन को बंद कर दिया और ओएसएक्स पर डॉकटर मशीन को फिर से चालू कर दिया, यह समस्या बनी रही। मैंने डॉकर 1.9.1 और फिर 1.8.3 को फिर से स्थापित किया, फिर भी इस मुद्दे को देखते हुए। मैक पर मेरे सभी डॉकर्स का नहीं तो सबसे अधिक उपयोग करने से मुझे ब्लॉक करें।

OS X 10.11 का उपयोग करके ubuntu 12.04 के लिए Docker 1.9.1 में +1

मेरे दफ्तर के डेवलपर्स भी इस दुर्घटना से भर गए।

इस संस्करण / बिल्ड ने काम किया : डॉकर संस्करण 1.9.0, बिल्ड 76d6bc9

यह संस्करण / बिल्ड हंग : डॉकर संस्करण 1.9.1, बिल्ड a34a1d5

@ क्रॉस्बीमाइकल मैंने दुर्भाग्य से बूट 2 डॉकटर के अलावा किसी अन्य वातावरण पर इसकी कोशिश नहीं की है।

Git-bisecting और docker की जानकारी वाला कोई व्यक्ति @ chico1198 द्वारा प्रदान की गई आईडी का उपयोग कर सकता है!

मैं OSX एल Capitan पर 1.9.1 के साथ एक ही समस्या का अनुभव किया, 1.9.0 के लिए उन्नयन मदद नहीं की।

OSX 10.9.3 पर यहां भी यही समस्या है:
डॉकर संस्करण 1.9.1, a34a1d5 का निर्माण करें
डॉकर संस्करण 1.9.0, 76d6bc9 का निर्माण करें

@crosbymichael मैंने ps auxf भागा, यही मैंने देखा:

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

Ubuntu 14.04 से छवि बनाने के प्रयास के साथ OSX 10.11 पर docker 1.9.1 के साथ +1

+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

डॉकर 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 भेजने की कोशिश कर सकते हैं और स्टैक ट्रेस को यहां चिपका सकते हैं जब यह अटक गया हो?

OS X 10.10 पर docker 1.9.1 के साथ +1

मैंने @osterman के मेकफाइल का उपयोग करके 1.8.3 पर अपग्रेड करने की कोशिश की और SSH कुंजी के साथ भी परेशानी हुई:

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

अलग-अलग ओपजंक स्थापित करके इसका परीक्षण किया डेबियन के अंदर स्थापित करता है
OSX 10.11.1, boot2docker 1.9.1: हैंग हो जाता है
OSX 10.11.1, boot2docker 1.9.0: काम करता है
Do 1.9.1 के साथ Ubuntu 14.04: काम करता है

Boot2docker vms को इसके साथ बनाया गया था:
docker-machine create -d virtualbox --virtualbox-boot2docker-url = https://github.com/boot2docker/boot2docker/releases/download/v1.9.0/boot2docker.iso
तथा
docker-machine create -d virtualbox --virtualbox-boot2docker-url = https://github.com/boot2docker/boot2docker/releases/download/v1.9.1/boot2docker.iso

उबंटू 14.04 पर डॉक्यूमेंट https://docs.docker.com/engine/installation/ubuntulinux/ पर प्रलेखन के बाद स्थापित किया गया था

+1, चल रहा है 1.9.1 OSX Yosemite 10.10.5 पर a34a1d5 का निर्माण।

मैं इसे पुन: पेश नहीं कर सकता।

एक ही मुद्दा यहाँ।
क्या विंडोज पर पुराने संस्करण को डाउनग्रेड करने का कोई तरीका है?

खुद मिल गया।
https://github.com/docker/docker/releases

+1, डॉकटर 1.9.1 @ एल कैपिटन

OS X 10.11.1 पर +1, डॉकटर 1.9.1

+1, डॉकटर 1.9.1 ए, ओएस एक्स 10.10.5

+1, डॉकटर 1.9.1 a34a1d5, विंडोज 10 का निर्माण करें

+1, डॉकटर 1.9.1 बिल्ड a34a1d5, OS X 10.11.1, डॉकटर-मशीन 0.5.1 बिल्ड 7e8e38e

+1

OSX 10.11.1 पर डॉकर-मशीन पर समान
डॉकर संस्करण 1.9.1, a34a1d5 का निर्माण करें
डॉकटर-मशीन संस्करण 0.5.1 (HEAD)

मैं डॉकटर-मशीन, ओएस एक्स 10.10.5 पर इसे पुन: पेश करने में सक्षम हूं, इसलिए यह बूट 2 डॉक से संबंधित कुछ हो सकता है। 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>

/ cc @tianon @nathanleclaire @Jffdm शायद आप में से किसी को भी विचार हो कि कहाँ दिखना है, या क्या डिबग करना है, मुझे वास्तव में कुछ नहीं मिल रहा है

आपके VM के पास कितनी RAM है? OOM दिया जा सकता है कि यह जैसा दिखता है
प्रक्रिया अप्रत्याशित रूप से मर जाती है। : निराश:

ऐसा लगता है कि स्मृति समस्या नहीं है, हालांकि <defunct> प्रक्रिया 100% CPU का उपभोग करती है;

CONTAINER           CPU %               MEM USAGE / LIMIT   MEM %               NET I/O               BLOCK I/O
d263da116bfd        99.51%              689.3 MB / 2.1 GB   32.82%              157.9 MB / 2.754 MB   25.15 MB / 130.4 MB

कंटेनर के रूप में अच्छी तरह से फंस गया है, और मुझे इसे मारने के लिए वीएम को रिबूट करना पड़ा

+1 डॉकर संस्करण 1.9.1, a34a1d5, विन 7 का निर्माण करें।

मैंने ऐसी ही समस्याओं में भाग लिया है जो कि OOM हो गए हैं, हालांकि आंकड़े कमांड कंटेनर में उपलब्ध मेमोरी को दिखाते हैं। टास्क मैनेजर द्वारा 0 मुक्त भौतिक मेमोरी दिखाए जाने के तुरंत बाद समस्या हुई, जबकि आँकड़े <100% दिखाना जारी रखा।

अजीब बात है, कि यह प्रक्रिया चलती रही, इसलिए इसे नहीं मारा गया। मैं एक एम के साथ पुन: प्रयास कर सकता हूं, हालांकि, यह अजीब है कि यह 1.9.x पर होता है, लेकिन (इस चर्चा के बाद) 1.8 पर नहीं। इसके अलावा, 1GB DigitalOcean की छोटी बूंद (1.9.1 पर भी) को चलाने में सफलता मिली। शायद कि एक स्वैप का उपयोग करता है, कि जाँच करनी चाहिए

1.9.1 की स्थापना रद्द करने और 1.8.3 स्थापित करने के बाद यह वास्तव में मेरे साथ होता रहा। ऐसा प्रतीत होता है कि मैक पर हालांकि अनइंस्टॉल बहुत अच्छी तरह से नहीं था क्योंकि शेल को फायर करना 1.8.3 पर देरी के बिना था, एक सामान्य पहले रन के विपरीत जहां यह ssh कीज़ और सामान सेट करता है।

_USER POLL_

_ इस चर्चा में परिवर्तन होने पर सूचित करने का सबसे अच्छा तरीका ऊपर दाईं ओर स्थित सदस्यता बटन पर क्लिक करके है ।_

नीचे सूचीबद्ध लोगों ने यादृच्छिक 1 के साथ आपकी अर्थपूर्ण चर्चा की सराहना की है:

@mattes

इस मुद्दे पर 31 प्रतिभागियों और गिनती।

@ bean5 कृपया अपनी टिप्पणी रचनात्मक रखें

@thaJeztah का मतलब न तो अपमान करना था और न ही जीथब ने भाग लेने वाले लोगों की संख्या को दिखाया है ... और मैं इकट्ठा किया कि बनाना चाहता था जिन्होंने +1 किया है। शायद मैं उसके मतलब से भ्रमित था। किसी भी मामले में, मैं इस मुद्दे को बड़ी प्रत्याशा के साथ देखता हूं क्योंकि इसने मुझे पिछले हफ्तों में एक से अधिक अवसरों पर प्रभावित किया है। मुझे खुशी है कि हमारे पास विभिन्न उपयोगकर्ताओं की जानकारी है।

मैं अपने सेटअप (मैक पर डॉकर मशीन का उपयोग करके) पर इस मुद्दे की नकल करने में सक्षम हूं।

यहाँ मेरे अब तक के निष्कर्ष हैं।

जैसा कि अन्य पोस्टरों ने उल्लेख किया है, इसे डुप्लिकेट करने का सबसे सरल तरीका एयूएफएस के साथ बूट 2 डॉकटर 1.9.1 आईएसओ का उपयोग किया गया है। इस Dockerfile को समस्या को बहुत जल्दी कम करना चाहिए:

FROM debian:jessie

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

dmesg देखते हुए, मुझे इस तरह के निर्माण का प्रयास करने के बाद कुछ एएफएफएस त्रुटियां दिखाई देती हैं, लेकिन मुझे 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

अगर मैं एक डॉकटर 1.9.1 मशीन बनाता हूं जो overlay का उपयोग स्टोरेज ड्राइवर के रूप में करता है:

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

प्रक्रिया लटकी नहीं है और यह रेखा सफलतापूर्वक चलती है! ऐसा लगता है कि एएफएफएस और / या कर्नेल समस्या है।

boot2docker / boot2docker _did_ कर्नेल संस्करणों और 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.1 बाइनरी के साथ 1.9.0 आईएसओ की कोशिश कर रहा है यह देखने के लिए कि संभावित बग क्षेत्र की सतह क्षेत्र को और कम किया जा सकता है या नहीं।

Dockerfile ठीक का निर्माण करेगा और बूट 2docker 1.9.0 ISO पर Docker 1.9.1 बाइनरी के साथ नहीं लटकेगा। यह मुद्दा डॉकटर 1.9.1 के साथ झूठ नहीं लगता है, बल्कि पर्यावरण जिसमें इसे चलाया जा रहा है।

मैं 1.9.1 रिलीज़ का उपयोग नहीं कर रहा हूँ, जिसमें कोई समस्या नहीं है, लेकिन डिफ़ॉल्ट मशीन विन्यास की तुलना में काफी अधिक सीपीयू / रैम / स्टोरेज है।

मैंने सिर्फ अपने वीएम के लिए मेमोरी को 4GB तक बढ़ाने की कोशिश की, लेकिन फिर भी पुन: पेश करने में सक्षम है

@ cpuguy83 बूट 2docker 1.9.1 पर AUFS?

जैसा कि ऊपर उल्लेख किया गया है, बी 2 डी एएफएफएस का एक बहुत विशिष्ट संस्करण बंडल करता है।

हां

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");
    }
}

संकलित करें और इसे एक दोषपूर्ण जावा प्रक्रिया में परिणाम दें, 1 कोर के साथ 100% सीपीयू का उपयोग करें:
javac Foo.java && java Foo

हालाँकि ... अगर एक System.exit(0); प्रिंटल के बाद जोड़ा जाता है तो सब कुछ ठीक है:

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

संस्करण की जानकारी:
ओएसएक्स 10.10.3
१.९ १
boot2docker संस्करण 1.9.1 uname -a "linux ci 4.1.13-boot2docker" है
numproc = 1

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

स्ट्रेस आउटपुट _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, डॉकर संस्करण 1.9.1, a34a1d5, OS X का निर्माण करें

+1, डॉकर संस्करण 1.9.1, बिल्ड a34a1d5, OS X 10.10.5, डॉकर मशीन संस्करण: 0.5.1 (HEAD)

+1

डॉकर संस्करण 1.9.1, a34a1d5 , OS X 10.11.1 (15B42) का निर्माण करें

+1

डॉकर संस्करण 1.9.1, OS X 10.11.1 पर a34a1d5 का निर्माण करें

यह मुद्दा वास्तव में काफी विचित्र है। अगर मैं strace विफल apt-get आदेश देता हूं, तो आउटपुट का अंत होता है:

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

जहां उन (खराब फाइल डिस्क्रिप्टर) त्रुटियां अनिश्चित काल तक जारी रहती हैं।

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

SIGPIPE फेल हो रहा है? यह मेरी पिछली पोस्ट के अनुरूप हो सकता है जहाँ मैंने जावा "हेल्लो वर्ल्ड" देखा था, जिससे स्पष्ट "सिस्टम.एक्सिट (0);" - या शायद एक पूरी तरह से अलग मुद्दा thats। अगर शोर के लिए खेद है।

अनिश्चित काल तक लूप करते समय आपके सीपीयू का क्या होता है?

@andrewgdavis यह 100% पर है

जावा "हैलो वर्ल्ड" एक स्पष्ट "System.exit (0) के बिना ज़ोंबी प्रक्रियाओं का कारण बनता है;"

यह निश्चित रूप से यहां सामने आई समस्या के समान है।

मैं निश्चित रूप से b2d मुद्दे की पुष्टि कर सकता हूं (यहां तक ​​कि इसे सबसे सकारात्मक रूप से 4.1.13 कर्नेल बम्प को ट्रैक करने के लिए बिसेक्ट भी किया था)। मैं भी b2d के साथ 4.2.6 पर पुन: पेश कर सकता हूं।

एक अतिरिक्त किंक के रूप में, मेरा जेंटू होस्ट वर्तमान में 4.1.13 + एयूएफएस पैच पर भी है, और मैं उसी सटीक समस्या को देख रहा हूं, इसलिए हमने निश्चित रूप से कुछ भी b2d- विशेष को खारिज कर दिया है।

मुझे लगता है कि यह 4.1.12 और 4.1.13 के बीच कमिट के माध्यम से पता लगाने के लायक हो सकता है कि क्या कुछ भी संबंधित कूदता है।

(अर्थात, https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.1.13)

हाँ, कुछ कर्नेल से टूटता है 4.1.12 => 4.1.13। मैं इस बात की पुष्टि कर सकता हूं कि पूर्व के लिए बूट 2docker ISO पकाना इस बग की यात्रा नहीं करता है, लेकिन पूर्व करता है।

तो, यह विशेष रूप से बूट 2 डॉक से संबंधित नहीं है, लेकिन एयूएफएस के साथ बातचीत करने वाले कर्नेल संस्करण से संबंधित है।

या शायद Docker में AUFS ड्राइवर के साथ विशिष्ट तरीके से बातचीत करता है
नए कर्नेल - टीबीडी, संभवतः 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 को जेनेरिक_परफॉर्म_राइट (संरचना फ़ाइल * फ़ाइल, संरचना iov_iter * i, loff_t pos) में परिवर्तन करता है।

नीचे कोड का हिस्सा है जिसे मैं व्यक्तिगत रूप से परीक्षण करना चाहता हूं क्योंकि टिप्पणी में गतिरोध और लाइवलॉक दोनों स्थितियों का वर्णन किया गया है और मैं 100% पर पीईपी को देखता हूं। लेकिन यह सिर्फ मुझे और मेरे कूद करने वाली निष्कर्ष चटाई है।

4.1.13 mm / 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

mongodb बंद करते समय एक समान हैंग देखना। निश्चित रूप से 1.9.x में मौजूद है। 1.8.x में मौजूद नहीं है।

मैं डॉक-मशीन वीएम की मेमोरी को 1024 से 2048 एमबी तक बढ़ाकर और 1 के बजाय 2 सीपीयू असाइन करके अपने लिए इस मुद्दे को हल करने में सक्षम रहा हूं।

काम करता है:

वीएम: उबंटू 14.04 (2 जीबी रैम)
डॉकर इंजन: 1.9.1
डॉकर आधार छवि: ubuntu: नवीनतम

काम नहीं करता:

वीएम: उबंटू 15.10 (2 जीबी रैम)
डॉकर इंजन: 1.9.1,1.9.0,1.8.3
डॉकर आधार छवि: ubuntu: नवीनतम , ubuntu: 14.04

@marsinvasion यदि संभव हो, तो क्या आप दोनों परीक्षण प्रणालियों पर uname -a का आउटपुट प्रिंट कर सकते हैं?

वीएम: उबंटू 14.04
लिनक्स ubuntu 3.19.0-25-जेनेरिक # 26 ~ 14.04.1-Ubuntu SMP शुक्र जुलाई 24 21:16:20 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux

वीएम: उबंटू 15.10
लिनक्स ubuntu 4.2.0-19-जेनेरिक # 23-उबंटू एसएमपी बुध नवंबर 11 11:39:30 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux

+1
डॉकर संस्करण 1.9.1, OS X 10.11.1 पर a34a1d5 का निर्माण करें

Do.1 1.9.1 के साथ OS X 10.9.5 पर एनकाउंटर किया गया।

@Marsinvasion से प्रेरित होकर, मैंने अपना डॉकटर-मशीन 2 CPU और 4096Mb RAM देकर एक सफल समाधान प्राप्त किया।

उफ़, जल्द ही बात की। यह एक डॉकरफाइल मैं काम कर रहा हूँ और निर्माण फिर से चल रहा है बदलने पर काम करना बंद कर दिया।

इसके अलावा इस नरकगामी बग (OS X पर docker- मशीन boot2docker 1.9.1) को देखते हुए, पहले की इमारत ubuntu: 15.04 छवि से। ऐसा लगता है कि मेरे ज़ोंबी सर्वर को फिर से शुरू करने के लिए उन ज़ोंबी कंटेनरों को दूर करने की आवश्यकता है।

मुझे लगा कि https://github.com/docker-library/java/issues/19 संबंधित था, लेकिन शायद नहीं, यहाँ हम हैंग हो रहे हैं, वहाँ उन्हें "जावा" न मिलने के बारे में एक त्रुटि मिली।

मेरे सर्वर को वर्कअराउंड के रूप में ओवरले में स्विच किया। इससे पहले इसने ज़ोंबी कंटेनरों का एक समूह बनाया था।

डॉकर संस्करण 1.9.1, OS X 10.11.1 पर a34a1d5 का निर्माण करें

किसी को भी पता है कि एक मौजूदा बूट 2docker.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

निश्चित रूप से डॉकर टूलबॉक्स 1.9.1a द्वारा तय नहीं किया गया है। उस संस्करण के साथ इस बग से पीड़ित। टिप्पणियों के माध्यम से पीछे देखते हुए, ऐसा लगता है कि मैं केवल एक ही नहीं हूं।

अभी भी निर्माण नहीं हो रहा है

मुझे VMbox को वर्चुअलबॉक्स में डिलीट करना था और इसे काम करने के लिए स्क्रैच से शुरू करना था।

इसके अलावा, बिना किसी लाभ के कई बार नए वीएम को हटाने और बनाने की कोशिश की गई।

1.9.1a स्थापित, docker-machine rm default किया और डिफ़ॉल्ट मशीन को पुन: उत्पन्न करने के लिए Docker क्विकस्टार्ट टर्मिनल का उपयोग किया। पुनर्निर्माण चित्र (जो java:7-jre से प्राप्त होता है) और चला गया, फिर भी काम नहीं करता है। ऊपर बताए अनुसार ओवरले मशीन के साथ ठीक काम करने के लिए जारी है:

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

^ धन्यवाद! मैं पुष्टि कर सकता हूं कि ओवरले मशीन काम कर रही है।

इंजन भंडारण ड्राइवर के रूप में overlay का उपयोग करना भी MongoDB शटडाउन हैंग को ठीक करने के लिए काम करता है।

आप OpenJDK के बजाय Oracle जावा को स्थापित करके Dockerfile बिल्ड विफलता को हल कर सकते हैं:

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

लेकिन मैं समस्या के दायरे को कम कर रहा था, बूट 2docker 1.9.1 ज़ोंबी जावा प्रक्रियाओं की ओर जाता है, यहां तक ​​कि सेंटोस कंटेनरों पर भी जहां ओपनजेडक ठीक स्थापित करता है।
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)।

मुझे यकीन है कि डॉकर लोग _not_ इसकी सिफारिश करेंगे, लेकिन जिस तरह से मैंने इस अवरुद्ध मुद्दे को आगे बढ़ाया है वह बूट 2docker.iso के निर्माण से है जो कि थोड़े पुराने AUFS के साथ docker 1.9.1 का उपयोग करता है। Https://github.com/boot2docker/boot2docker/issues/1099#issuecomment -163052066 में निर्देश।

oracle jdk1.7.0_75 और jdk1.8.0_65 की कोशिश की; दोनों लटके हुए हैं और एक दोषपूर्ण जावा प्रक्रिया बनाते हैं।

FROM: 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 पर चल रहे मैक OSX 10.11.1 (15B42) पर आज पहले डुप्लिकेट मुद्दा बनाने में सक्षम था

Docker 1.9.0 स्थापित करके इसके चारों ओर प्राप्त करने में सक्षम था

_ जानकारी की कमी के लिए विचार मेरे कार्य मशीन पर पहले दिन के दौरान था - बाद में समय पर अद्यतन जानकारी प्रदान करेगा _

: +1:

यहां पर डॉकर 1.9.1 और ओएस एक्स 10.11 के साथ है।

इस मुद्दे वाले लोगों के लिए

हमने अभी तक इसे एक _docker_ बग के रूप में सीमित नहीं किया है, लेकिन कर्नेल में AUFS के साथ संयोजन में एक 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 और कर्नेल 4.2.6 के साथ) का परीक्षण किया गया है, और बग _not_ को पुन: पेश नहीं करता है, इसलिए हम अभी भी "नए कर्नेल और AUFS पैच में कुछ परिवर्तन के बीच अजीब बातचीत" कर रहे हैं। “भूमि। : निराश:

परीक्षण किया गया है, और बग अभी भी ताजा 4.1.14 कर्नेल पर मौजूद है, इसलिए हम अभी भी कुछ ऐसे कमिट पर बैठे हैं जो 4.1.13 पर वापस आ गया था जो एयूएफएस पैच के साथ अजीब बातचीत कर रहा था (और पहले से तय होने के साथ भाग्यशाली नहीं मिला। अंतरिम)।

मैंने इसे पुराने कॉलेज की कोशिश और बूट 2docker रेपो क्लोन करने का फैसला किया; फिर पिछले संस्करण में douffile में संशोधित aufs। तो 1.9.1 कर्नेल 4.1.13 + पिछला AUFS संस्करण है जो 1.9.1 से पहले शिप किया गया था। संकलन मेरी मशीन पर धीमा है ... क्या एक डॉक स्वीमर सेटअप है जिसे मैं एक गिट बायसेक्ट के साथ चला सकता हूं और परिणाम एकत्र कर सकता हूं? यह मीठा होगा।

किसी भी तरह, अगर यह काम करता है तो मैं जल्द ही अपने परिणाम पोस्ट करूंगा ...

अपडेट करें:
4.1.13 + यह AUFS अभी भी समस्या का प्रदर्शन करता है।
ENV AUFS_COMMIT 1724fe65683d126a92c6baeea0b3c7d0306c63ef

मैं परिणामों को एकत्र करने के लिए किसी भी आसान सेटअप के बारे में नहीं जानता, हालाँकि कोई भी इसका निर्माण कर सकता है।

FWIW, https://sources.debian.net/src/ca-certports-java/jessie/debian/postinst.in/ उस पैकेज में चलने वाली सटीक स्क्रिप्ट है, और https://sources.debian.net/src /ca-certificates-java/jessie/src/main/java/org/debian/security/UpdateCertificates.java/ सटीक जावा स्रोत है कि निष्पादित किया जा रहा है जब हम लटका + मृत + सीपीयू आंकी मिलता है।

संबंधित मुद्दे (जावा प्रक्रिया हैंग) में आज मिला।

मेजबान वातावरण: लिनक्स लीनोवो 4.2.0-19-जेनेरिक # 23-उबटन एसएमपी बुध 11 नवंबर 11:39:30 यूटीसी 2015 x86_64 x86_64 x86_64 GNU / Linux
डिस्ट्रो: उबंटू 15.10
डॉकर इंजन: 1.9.1
डॉकर मशीन: 0.5.0 (04cfa58)

मैं नेटवर्क मल्टी-होस्ट ट्यूटोरियल का अनुसरण कर रहा हूं। केवल अंतर यह है कि मैं ओरेकल / नोस्कल छवि के साथ खेल रहा हूं। यह चित्र ओरेकल लिनक्स पर आधारित है और OpenJDK का उपयोग करता है।

@brunoborges हाँ, वही मुद्दा हो सकता है, https://github.com/docker/docker/issues/18500#issuecomment -163334612 देखें

@brunoborges बस अपने बूट 2docker.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) = ? का प्रदर्शन करने की कोशिश कर रहे थे, जो कि ज़ोंबी जावा प्रोसेस से देखा गया था। (इस लिंक ने मुझे पायथन थ्रेडिंग / seccomp / etc http://stackoverflow.com/questions/25678139/how-do-you-cleanly-exit-after-enability-seccomp-in-python के बारे में बहुत सी जानकारी प्रदान की है)

कर्नेल भूमि से दूर: बूट 2docker iso को फिर से बनाने के बाद, aufs verions और कर्नेल संस्करणों के साथ खिलवाड़ करना (जिनमें से कुछ भी वास्तव में कोई फर्क नहीं पड़ा) मैं इस बात से तंग आ गया कि संकलन प्रक्रिया numpro = 1 का उपयोग कितना धीमा है। इसलिए मैंने इसे बदलकर 6. ==> नोट नहीं 1 सीपीयू (जो केवल 1 सीपीयू है अब एक दिन?)। अचानक विफलता का मामला

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

काम करना प्रारम्भ कर दिया।

जाहिर है, कोशिश करने के लिए अगली बात यह वापस 1 सीपीयू को टक्कर थी। ==> विफल। वापस एक दोषपूर्ण जावा प्रक्रिया के लिए।

तो फिर मैं कैसे जावा बन्द हो जाता है के बारे में अधिक पता लगाना चाहता था। यह अच्छी तरह से परिभाषित नहीं है। लेकिन केवल 1 सीपीयू के साथ यह जावा प्रक्रिया सफलतापूर्वक चलाने में सक्षम थी: (कृपया मेरे भयानक जावा का मजाक न बनाएं।)

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

क्या कोई और इस व्यवहार की पुष्टि कर सकता है? << सवाल अब मूट है

अद्यतन: यहां तक ​​कि एक से अधिक कोर के साथ, एक ख़राब जावा प्रक्रिया हो सकती है। (मैं कैसंड्रा-क्ली चला रहा था और यह हुआ।)

docker- मशीन sV 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

एक ही हैंगिंग इश्यू बिल्डिंग बिटकॉइन-सर्वर - अपडेट-कै-सर्टिफिकेट ठीक काम करता है, लेकिन jdk posthook हमेशा के लिए हैंग हो जाता है। 1.9.1 बूट 2 डॉक का उपयोग करते समय केवल एक समस्या। RancherOS छवि पर स्विच किया गया और कोई समस्या नहीं थी। OSX 10.10।

एल कैपिटन के साथ, डॉकर 1.9.1 और उबंटू 14.04.1 मुझे मिलता है: सीए-सर्टिफिकेट-जावा स्थापित करना जो असीम रूप से लटका हुआ है।

@stremlenye 1.9.0 पर वापस आ गया। अभी भी लटका हुआ है।

@brunoborges docker 1.9.0or boot2docker.iso 1.9.0?

@stremlenye Docker 1.9.0 ... मेरे सिस्टम में boot2docker.iso 1.9.0 प्राप्त करने के लिए क्या निर्देश हैं?

@brunoborges ऊपर इस टिप्पणी की जाँच करें:

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

carsten-ulrich-saitow-ag बताते हैं कि कैसे 1.9.0 iso --virtualbox-boot2docker-url ध्वज का उपयोग करके एक नया डॉकटर-मशीन बनाया जाए। उस सलाह ने मेरी बेकन को बचा लिया! एक बार मैंने ऐसा किया, मैं एक बार फिर से अपने कंटेनरों में JRE RPM स्थापित कर सकता था।

@ mobsy74 @stremlenye ने बूट 2docker 1.9.0 के साथ प्रयास किया और यह कभी-कभी लटका हुआ है।

@brunoborges कि कोशिश करने के लिए धन्यवाद। तो मैं 1.8.3 से चिपके रहूंगा जब तक यह बग ठीक नहीं हो जाता।

@stremlenye आप बूट 2docker 1.8.3 मतलब है?

@brunoborges हाँ

नमस्ते,
मेरी भी यही समस्या थी।
1.9.1 से 1.9.0 तक docker टूल को अपग्रेड करते समय समस्या हल हो गई
https://github.com/docker/toolbox/releases/download/v1.9.0/DockerToolbox-1.9.0.pkg

कई cpus (docker मशीन में) को सक्षम करने से यह मेरे लिए हल हो गया।

--virtualbox-cpu-count=4

@heith आप

imho, boot2docker को अन्य उपलब्ध स्टोरेज ड्राइवरों में से एक auf से हटना चाहिए। एक अच्छा कारण है कि aufs ने इसे लिनक्स कर्नेल में कभी नहीं बनाया।

@robvanmieghem प्रत्येक ड्राइवर की अपनी सीमाएँ होती हैं। Aufs कुल मिलाकर काफी स्थिर है, और ओवरलेफ्स में कुछ अवरोधक मुद्दे हैं (उपयोग के आधार पर)

@brunoborges DockerToolbox-1.9.1c - इसने मेरे लिए विंडोज़ और ओएक्सएक्स पर काम किया है।

@thaJeztah ने कभी नहीं कहा कि ओवरलेफ़्स सही समाधान है। मुझे लगता है कि btrfs बूट 2docker के लिए एक अच्छा विकल्प है, हालांकि, boot2docker डॉक कंटेनरों को चलाने के लिए समर्पित है और इस तथ्य के अलावा कि btrfs को लिनक्स कर्नेल में पूरी तरह से समर्थित है, सामग्री को देखना वास्तव में आसान है।

इस पर कई तरह की राय है क्योंकि डिस्ट्रो और फाइलसिस्टम के संयोजन हैं :) कोई भी समाधान सभी उपयोग-मामलों के लिए एकदम सही नहीं होने वाला है इसलिए खुले स्रोत और लिनक्स की भावना से मुझे लगता है कि बनाने का सबसे अच्छा निर्णय बेहतर प्रदान करना है। Distro के कई विकल्पों के लिए समर्थन। पहले से ही हमारे पास Boot2Docker या RancherOS का विकल्प है और मेरा मानना ​​है कि डेबियन डिस्ट्रो बेस पर boot2docker को फिर से बनाने के लिए कुछ काम किया गया था। डूकर-मशीन क्लाउड और नंगे धातु पर उबंटू का समर्थन करेगी, इसलिए मुझे यकीन है कि एक उबंटू-आधारित वीएम आइसो को एक साथ फेंकना मुश्किल नहीं होगा, जैसे कि अन्य जैसे कि अल्पाइन या कोरओएस आदि पर बनाया गया है, फिर उनमें से प्रत्येक के लिए। फाइलसिस्टम की पसंद - फिर से, RancherOS अब ZFS को एक वैकल्पिक इंस्टॉल के रूप में पेश करता है, जबकि CoreOS डिफ़ॉल्ट रूप से BTRFS का उपयोग करता है और मेरा मानना ​​है कि यह अभी भी एक विकल्प है और कर्नेल के रूप में 3.19 Ubuntu बॉक्स से बाहर OverlayFS का समर्थन करता है - किसी भी Snappy कोर के लिए आधारित b2d छवि? ;)

अब, यदि केवल हम डॉक-मशीन पैरामीटर के नामकरण को मानकीकृत कर सकते हैं और भ्रम को कम करने के लिए 'boot2docker' के संदर्भों को हटा सकते हैं - RancherOS को स्थापित करने के लिए boot2docker-url पैरामीटर का उपयोग करना कुछ हद तक एकतरफा है;)

@ दूर-नीला +1

@heiths +1। यह 1.9.1c के साथ OSX पर भी मेरे लिए इसे हल कर दिया

CPU का> 1 सेट करना मेरे लिए समस्या से बचा जाता है। 1.9.1c ने मदद नहीं की।

@heiths @fredriksvensson मुझे लगता है कि मैं इस मुद्दे को बेतरतीब ढंग से कई कंटेनरों पर्यावरण पर दिखाई दिया था और मैं भी CPU की मात्रा बढ़ाने की कोशिश की (स्मृति भी है, लेकिन एक बिंदु नहीं है)। stop <all> / start <all> के चक्रों के जोड़े ने दिखाया कि समस्या नहीं गई है। मैं आपको यह सुनिश्चित करने के लिए अपने पर्यावरण की जांच करने की सलाह दूंगा कि समाधान आपके लिए स्थिर है।
/ cc @timechanter

ओह, यह निश्चित रूप से नहीं गया है। लेकिन शॉर्ट टर्म के लिए हैंग बनाम 100% हैंग होने का 10% मौका कम से कम मैनेज करने योग्य है।

@heiths --virtualbox-cpu-count=4 ने भी मेरे लिए काम किया।

@timechanter +1 सेटिंग CPU से> 1 ने मेरे लिए समस्या को कम से कम एक बार टाला है; इस समय एक प्रभावी समाधान की तरह दिखता है।

OSX 10.10.5

अनइंस्टॉल किया गया डॉकटर टूलबॉक्स 1.9.1। डॉकर टूलबॉक्स में डाउनग्रेडेड 1.9.0 ने मेरे लिए काम किया।

El Capitan MacOSX पर एक ही मुद्दा

@heiths --virtualbox-cpu-count=4 मेरे लिए भी काम करता है।

विंडोज 7 में मेरे लिए डॉकर टूलबॉक्स 1.9.1 बी और 1.9.1e के साथ हुआ।

"सीए-सर्टिफिकेट-जावा (20130815ubuntu1) की स्थापना ..." - एल कैपिटन मैकओएसएक्स। कृपया मदद, दोस्तों !!! मैं इसे ठीक नहीं कर सकता

@ troian88 डाउनग्रेड boot2docker.iso 1.9.0 या 1.8.3 पर।

@ troian88 , कई सीपीयू के साथ एक

पुष्टि कर सकते हैं कि --virtualbox-cpu-count=2 डॉकिंग 1.9.1 के साथ एक लटकते Setting up ca-certificates-java पर एक अस्थायी समाधान है।

इस मुद्दे वाले लोगों के लिए

हमने अभी तक इसे एक _docker_ बग के रूप में सीमित नहीं किया है, लेकिन कर्नेल में AUFS के साथ संयोजन में एक https://github.com/docker/docker/issues/18180#issuecomment -161832035 देखें

• यदि आप प्रगति पर सूचित रहना चाहते हैं, तो इस पृष्ठ पर सदस्यता बटन का उपयोग टिप्पणी न करें।
• यदि आप इसे हल करने में मदद करना चाहते हैं, तो कर्नेल के git-bissect का प्रदर्शन करने में https://github.com/docker/docker/issues/18180#issuecomment -161834068 मदद कर सकता है
• याद रखें कि प्रत्येक टिप्पणी ग्राहकों को 2000 से अधिक ई-मेल भेजेगा, और अनगिनत पिल्लों की मृत्यु हो जाएगी: मुस्कान:

@externl @stremlenye धन्यवाद।

LWP स्टैक्स को देखते हुए, मैंने पाया कि बग aufs_destroy_inode कारण होता है।

मैं इसमें आगे देखूंगा।

यह इनोड से संबंधित गतिरोध प्रतीत होता

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

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

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

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



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

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

ध्यान दें

लोग कह रहे हैं कि कई सीपीयू पर चलने पर बग से बचा जा सकता है।
हालांकि, मैं अभी भी अपने भौतिक 4-सीपीयू बॉक्स के साथ बग को हिट कर सकता हूं। (हालांकि <1% संभावना।)
तो --virtualbox-cpu-count=2 _NOT_ गारंटी देता है कि आप बग से बच सकते हैं।

ध्यान दें कि सीपीयू की संख्या अभी भी मायने रखती है।
जब मैं taskset 0x1 java चलाता हूं, तो मैं निश्चित रूप से बग को हिट कर सकता हूं। ( taskset विशेष CPU को प्रक्रिया में असाइन करता है)।

@ अकिहिरोसा शुक्रिया इस में देखने के लिए बहुत बहुत धन्यवाद। हमें जानकारी देते रहिए! :दिल:

ध्यान दें कि डॉकर 1.8.3 का उपयोग करते समय यह समस्या विंडोज 7 पर भी होती है।

हम वही देख रहे हैं (बिल्कुल वही स्टैक का निशान जैसा कि अकिहिरोसा की टिप्पणी ऊपर दी गई है) पुरानी गुठली पर:
Linux 3.19.0-42-generic #48~14.04.1-Ubuntu SMP x86_64 Docker version 1.9.1, build a34a1d5

मैं कई CPU के बारे में @AkihiroSuda के दावे की पुष्टि कर सकता हूं - मैंने इसे अपने होस्ट पर भी मारा है जिसमें 8 एज़ हैं।

यह AUFS डिबगिंग वास्तव में दिलचस्प लगता है - शायद यह एएफएफएस के साथ एक मुद्दा दर्ज करने के लायक है और यह देखने के लिए कि क्या एएफएफएस अनुरक्षक डिबग में मदद कर सकता है? यह शायद उनके लिए उपयोगी होगा अगर हम सिर्फ एएफएफएस (कोई डोकर) के साथ पुन: पेश कर सकते हैं, लेकिन यह बिल्कुल तुच्छ नहीं है। :मुस्कुराओ:

@tianon मैंने aufs-users पर एक पोस्ट किया: http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/5335

@ अकिहिरोसा , मैंने इसे गैर-जावा उपयोग मामले के साथ लटका हुआ देखा है। धीरे-धीरे एक कांटेदार MongoDB डेमॉन को बंद करने की कोशिश की जा रही है। यह MongoDB स्टार्टअप या नियमित उपयोग पर नहीं होता है, लेकिन शटडाउन पर मज़बूती से होता है।

@jakirkham धन्यवाद, ऐसा लगता है कि बग को ट्रिगर करने के लिए एक विशिष्ट थ्रेड कॉन्फ़िगरेशन (जावा, MongoDB, और शायद अन्य चीजों में दिखाई देता है) की आवश्यकता है।

BTW, दूसरे विचार पर, शायद एयूएफएस लटका बग का "कारण" होने के बजाय बग का "परिणाम" है।
मैं इस विषय पर गौर कर रहा हूं: http://www.serverphorums.com/read.php?12 , 673905
(मैंने यह नहीं देखा कि दो दिन पहले zap_pid_ns_processes() भी लटका हुआ था, क्योंकि मैंने उस समय इनिट प्रक्रिया के रूप में बैश का इस्तेमाल किया था। https://github.com/docker/docker/issues/18180#issececomment- 166186061)

https://github.com/docker/docker/issues/18180#issuecomment -161843456
@andrewgdavis , आप काफी सही हैं!

बग को लिनक्स कर्नेल ( mm/filemap.c ) के लिए प्रतिबद्ध 296291cd के कारण एक प्रतिगमन प्रतीत होता है।

मैंने एक Boot2Docker ISO ( boot2docker-v1.9.1-fix1.iso ) बनाया जो कमिट 296291cd को छोड़ता है: https://github.com/AkihiroSuda/boot2docker/releases/tag/v1.1.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-डोबोस्क
आप बग मार रहे हैं क्योंकि Canonical ने मूल रूप से 296291cd को कर्नेल 3.19 पेड़ को वापस भेज दिया है: http://kernel.ubuntu.com/git/ubuntu/ubuntu-vivid.git/commit/?id=6b085bb8acc677d5b9bb798634ffd6e0ad3ad3303

@ अकिहिरोसा वाह, खोजने के लिए धन्यवाद! अगले चरण क्या हैं? क्या उस पैच को वापस लाया जाना चाहिए, या पैच को सुधारने का कोई तरीका है? क्या आप कर्नेल के ऊपर एक पैच भेजने पर विचार कर रहे हैं?

@ अकिहिरोसा , आपका फिक्स एक आकर्षण की तरह काम करता है। धन्यवाद!

@thaJeztah

यह एक आसान सवाल नहीं है।
२ ९ ६२ ९ sendfile(2) एलसीडी के बिना,
मुझे डर है कि कुछ विशिष्ट वातावरणों में यह sendfile एक सुरक्षा समस्या (यानी, अनाम उपयोगकर्ता द्वारा थकावट का हमला) का कारण बन सकता है।

मैं कमिटेड २ ९ ६२ ९ १ एलसीडी सुधारने की कोशिश कर रहा हूं, लेकिन इसमें थोड़ा समय लग सकता है।

फिर भी, मैंने इस बग को कर्नेल बगज़िला को सूचित किया: https://bugzilla.kernel.org/show_bug.cgi?id=109971

मैंने एक डॉकटर कंटेनर 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

@ अकिहिरोसा हुम , ठीक है, एक मुद्दा की तरह लगता है, हाँ। रिप्रो-कंटेनर और अनुसंधान के लिए बहुत बहुत धन्यवाद; कम से कम काम करने के लिए एक बहुत ही विशिष्ट कार्य है, उम्मीद है कि अन्य लोग इसमें शामिल होंगे, एक समाधान खोजने में सहायता करने की कोशिश कर रहे हैं। अब तक के अपने उत्कृष्ट कार्य के लिए बहुत बहुत धन्यवाद।

मुझे OS X El Capitan डार्विन कर्नेल संस्करण 15.2.0 पर मारा गया था
डॉकर संस्करण 1.9.1, बिल्ड d12ea79c9de6d144ce6bc7ccfe41c507cca6fd35
boot2docker 1.9.1

नीचे दिए गए कमांड के साथ boot2docker 1.9.0 का डाउनग्रेड मेरे लिए काम करता है:

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

@thaJeztah
AUFS 296291cd को सपोर्ट करने वाला है।
http://article.gmane.org/gmane.linux.file-systems.aufs.user/5343

इसलिए अगला कदम AUFS के अद्यतन की प्रतीक्षा करना है।

तुम एक हीरो हो, @AkihiroSuda! यह पता लगाने के लिए अपस्ट्रीम के साथ काम करने के लिए धन्यवाद! :दिल:

अगर कोई भी @ अकिहिरोसा फिक्स को लागू करना चाहता है, तो यह एक आकर्षण की तरह काम करता है:

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

उबंटू 14.04 पर किसी के लिए, गिरी 3.13.0-71 या पुराने को अपग्रेड करना समस्या को हल करना चाहिए। उसके बाद 296291cd को वापस भेज दिया गया।

टिप के लिए @ebpitts धन्यवाद, यहाँ कुछ हद तक सापेक्ष कदम हैं Ubuntu 14.04 कर्नेल को 3.13.0-71 साथ Docker 1.9.1 स्थापित करना।

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

इस बिंदु पर आपके पास बूटलोडिंग के दौरान लेने के लिए दो गुठली होनी चाहिए। हालाँकि, मैं 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

कमांड के आउटपुट में ग्रब को अपडेट किए जाने के बारे में कुछ चीजें थीं, इसलिए आप /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 चलाने का मेरा अगला प्रयास जो ओपी शीर्षक ("सीए-सर्टिफिकेट-जावा स्थापित करना") पर लटका हुआ था, यह _still_ मर गया और इस बार मेरी मशीन को बंद कर दिया , लेकिन अब जब मेरे पास कोई एसएसएच नहीं है, तो मैं घर जाऊंगा और 2016 तक इंतजार करूंगा कि यह देखने की कोशिश करें कि क्या किसी और ने उसके लिए बेहतर फिक्स किया है = /

इसलिए ... मैं इस बात की पुष्टि नहीं कर सकता कि उबंटू 14.04 + डॉकर 1.9.1 पर इस समस्या को रोकने के बाद कर्नेल को 3.13.0-71 पर अपग्रेड करने के बाद भी प्रभावी है। छी।

हाँ, बस पुष्टि करने के लिए, मैंने $ docker run -it --rm akihirosuda/test18180 भाग लिया और यह अभी भी लटका हुआ है।

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

यह उबंटू 14.04 को कर्नेल संस्करण 3.13.0-71 में एएफएफएस के साथ अपग्रेड करने के बाद है

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

@ebpitts क्या आपको यकीन है कि उबंटू पर कर्नेल डाउनग्रेड वास्तव में ठीक है?

दिलचस्प है, तब भी जब मैंने स्टोरेज ड्राइवर को devicemapper /var/default/docker स्पष्ट रूप से सेट किया:

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

और docker सेवा को पुनः आरंभ करें, docker info चल रहा है:

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

मैं अभी भी akihirosuda/test18180:latest परीक्षण छवि में लटका हूं।

मैंने अपने Ubuntu 14 बॉक्स पर कच्चे बाइनरी का उपयोग करके 1.8.3 को डॉकटर ( apt-get बिना आसान नहीं है) के लिए डाउनग्रेड किया, यहाँ कदम हैं ... किसी और के लिए ... मैं व्यापार में वापस आ गया हूं (कृपया नोट मैंने कर्नेल को 3.13.0-71-generic पहले भी डाउनग्रेड किया है, ऊपर देखें)

मैंने https://get.docker.com/builds/Linux/x86_64/docker-1.8.3 से 1.8.3 बाइनरी स्थापित किया, फिर इसे /usr/bin/docker स्थानांतरित कर दिया, इसे sudo chmod +x /usr/bin/docker निष्पादन योग्य अनुमति दे दी।

फिर, मैंने sysvinit-debian स्क्रिप्ट को पकड़ा, check_init() बॉडी की टिप्पणी की और इसे केवल echo '' साथ बदल दिया और इसे /etc/init.d में गिरा दिया। तब मैंने इसे बूट स्टार्टअप पर ln -s /etc/init.d/docker /etc/rc2.d/S99docker साथ रूट के रूप में चलाने के लिए सेट किया, और sudo reboot भाग लिया। उसके बाद, मैं बाइनरी इंस्टॉलेशन से बूट पर docker 1.8.3 सेवा वापस कर रहा हूं। मुझे नहीं पता कि डॉकर्स की वेबसाइट पर बाइनरी-इंस्टॉल पेज पर इन चरणों को वास्तव में क्यों नहीं प्रलेखित किया गया है। वैसे भी।

$ service docker status
 * Docker is running

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

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

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

यहां सब अच्छा लगता है - मैं $ docker run -it hello-world सही ढंग से चला सकता हूं। akihirosuda/test18180 अभी भी वास्तव में लटका हुआ है (???), लेकिन मैं Setting up ca-certificates-java पर फंसने के बिना अपने मूल कंटेनर को बनाने और चलाने में सक्षम हूं, जो मुझे यहां पहले स्थान पर लाया।

संदर्भ के लिए, मैं Ubuntu 15.04 ज्वलंत, लिनक्स 3.19.0-42-जेनेरिक पर हूं। भी प्रभावित हुआ।

क्योंकि मैं ओवरले का उपयोग नहीं कर सकता (मुझे RHEL मेहमानों की आवश्यकता है), मैंने एक स्पेयर ड्राइव पर एक btrfs विभाजन बनाया, और इसे / var / lib / docker पर रोक दिया (पहले docker daemon रोकें)। Docker अब खुशी से btrfs का उपयोग कर रहा है, फिर भी @akihirosuda की छवि अभी भी दूसरे चेक (अजीब) पर लटकी हुई है।

@mikeatlas
मेरी test18180 छवि का परीक्षण करने के लिए धन्यवाद।

परिणाम अजीब नहीं है।
दूसरा चेक ( Checking whether sendfile(2) is killable. ) पुरानी गुठली में लटका हुआ है।
दूसरा चेक पास करने के लिए आपको 296291cd के साथ एक नया कर्नेल चाहिए।

| AUFS? | कर्नेल में 296291cd शामिल हैं? | अपेक्षित परिणाम |
| --- --- ---
| य | य | हैंग (पहली जाँच: Checking whether hitting docker#18180. ) |
| य | एन | हैंग्स (दूसरा चेक: Checking whether sendfile(2) is killable. ) |
| एन | य | पास |
| एन | एन | हैंग (2 चेक: Checking whether sendfile(2) is killable. ) |

@cfstras धन्यवाद, मैं उस पर गौर करूंगा।

@cfstras , यह प्रतिलिपि प्रस्तुत करने योग्य है, और मैंने # 19073 खोला।

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

संपादित करें:
पहले मैं इस बारे में गलत था कि कर्नेल कर्नेल संस्करण बदलने के बाद काम क्यों नहीं करता है, लेकिन मैं अपने कर्नेल के लिए अतिरिक्त पैकेज स्थापित करने की पुष्टि कर सकता हूं और फिर पुनः स्थापित करने वाले ने मेरे लिए इस समस्या को हल किया:

sudo apt-get remove docker-engine
sudo apt-get install linux-image-extra-3.13.0-71- जेनेरिक
कर्ल-एसएसएल https://get.docker.com/ | श्री

@lwcolton दिलचस्प, linux-image-extra-3.13.0-71-generic एक पैकेज नहीं है जिसे मैंने स्थापित करने के लिए सोचा था (लेकिन मैंने जेनेरिक एक्स्ट्रा पैकेज को बाद में स्थापित किया, जैसा कि उल्लेख किया गया है) .... लेकिन फिर भी, मैं इस धारणा के तहत था कि एएफएफएस मॉड्यूल की तुलना में बहुत पुराना है बस अपेक्षाकृत हाल ही में 3.13.0-71 कर्नेल। भले ही, डॉकर 1.8.3 के लिए डाउनग्रेड करना बहुत दर्दनाक नहीं था, और अगर मुझे फिर से प्रक्रिया से गुजरना पड़ा, तो मैं सप्ताह के किसी भी दिन लिनक्स कर्नेल को डाउनग्रेड करने के लिए डॉकर को अपग्रेड करना पसंद करूंगा।

@dschep दूसरों के लिए ध्यान दें कि OverlayFS पर स्विच करने के लिए लिनक्स पर कर्नेल संस्करण 3.18 + की आवश्यकता होती है, और डॉकर के पृष्ठ पर उद्धृत किया जाता है, _जैसे OverlayFS के रूप में वादा किया जाता है, यह अभी भी अपेक्षाकृत युवा है। वातावरण में इसका उपयोग करने से पहले सावधानी बरती जानी चाहिए ।_, और, एक चेतावनी के साथ आता है कि ओवरलेएफएस को चालू करने से पहले किसी भी चित्र को प्रभावी ढंग से बैकअप लेने से पहले आपको उन्हें _all_ को एक रजिस्ट्री में धकेलना चाहिए।

@mikeatlas मुझे लगता है कि यह ओवरलेफ़्स पर अब तक की सबसे बड़ी सीमा है: "_Therefore, ओवरले स्टोरेज ड्राइवर का उपयोग करके डॉक होस्ट पर कंटेनर के अंदर यम का उपयोग करना वर्कअराउंड को लागू किए बिना काम करने की संभावना नहीं है।" "।

@brunoborges yum को वर्तमान में ओवरलेफ़्स पर काम करने के लिए पैच किया जा रहा है, इसलिए, जल्द ही, यम के नए संस्करणों को ओवरलेफ़्स पर काम करने में सक्षम होना चाहिए (हालांकि अभी भी कुछ मुद्दे होंगे, इसलिए यह आपके उपयोग-मामले पर निर्भर करता है - आप की स्थिति उन्हें)। अत्यधिक इनकोड का उपयोग एक और मुद्दा हो सकता है।

मुझे विश्वास है कि मैं इस मुद्दे को भी अनुभव कर रहा हूं। कॉल ट्रेस एपर्मर का उल्लेख करता है, लेकिन एपर्मर को अक्षम करने से कोई फर्क नहीं पड़ता। डिवाइसेमर का उपयोग करने से समस्या दूर हो गई।

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

पीएस ऑक्सफग:

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>

यह एएफएफएस अपस्ट्रीम में तय किया गया था - फिक्स को शामिल करने के लिए बूट 2 डॉक को अपडेट किया गया है (जो अगली रिलीज के साथ बाहर निकल जाएगा), और जो भी गैर-बूट 2 डॉक उपयोगकर्ता प्रभावित हैं वे अद्यतन एएफएफएस रिलीज को लागू करें। : +1:

@tianon क्या आपके पास अपस्ट्रीम बग्स का कोई संदर्भ है?

http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/5345 अपस्ट्रीम रिलीज की घोषणा है - यकीन है कि अगर वहाँ से अधिक चर्चा नहीं है

http://comments.gmane.org/gmane.linux.file-systems.aufs.user/5337 इस मुद्दे के लिए पृष्ठभूमि की चर्चा अधिक है

धन्यवाद!

यह एएफएफएस अपस्ट्रीम में तय किया गया था - फिक्स को शामिल करने के लिए बूट 2 डॉक को अपडेट किया गया है (जो अगली रिलीज के साथ बाहर निकल जाएगा), और जो भी गैर-बूट 2 डॉक उपयोगकर्ता प्रभावित हैं वे अद्यतन एएफएफएस रिलीज को लागू करें। : +1:

अच्छा लगा।

क्या डॉक्यु हब पर AUFS का छोटी गाड़ी संस्करण इस्तेमाल किया गया था?

@tianon "गैर-बूट 2 डॉक उपयोगकर्ता के लिए" अपडेटेड एएफएफएस रिलीज़ "का अर्थ है (मैक ओएस एक्स पर विकास में डॉकटर इंजन _not_ चलाने वाला हर कोई, जो कि बी 2 डी के लिए बनाया गया है, प्राथमिक रूप से) उन्हें लिनक्स कर्नेल अपडेट के लिए इंतजार करना होगा यह एएफएफएस पैच ... या ... यह देखते हुए कि कितने इंस्टॉल्स / लोग प्रभावित होते दिखाई देते हैं, क्या एएफएफएस को 4.1.13+ पर पैच करने के लिए किसी के द्वारा सरलीकृत / न्यूनतम निर्देश प्रदान किए जा सकते हैं? 4.1.13+ के लिए गाइड निश्चित रूप से पढ़ने के लिए गैर-तुच्छ है; इस विशिष्ट फिक्स के लिए लिनक्स कर्नेल अपने आप को पैच करना दिल के बेहोश होने के लिए बिल्कुल नहीं है।

जैसा कि मैं समझता हूँ कि अगर मैं इस का निर्माण boot2docker.iso और में रख ~/.docker/machine/cache और के साथ एक नया वी एम बनाने docker-machine कि वी एम की इस नई प्रतिलिपि का उपयोग करेगा boot2docker ।

बस इसलिए मैं समझता हूँ कि अगर मैं इस boot2docker.iso का निर्माण करता हूँ और इसे ~ / .docker / machine / cache में डालता हूँ और docker- मशीन के साथ एक नया 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 पर अपडेट करने का अनुरोध भेजा गया

वहाँ बूट 2docker की एक नई रिलीज होने जा रही है, 1.9.1 के रूप में यह तय नहीं है लगता है?

संपादित करें। @AkihiroSuda boot2docker छवि के साथ , मैं जारी रखने में सक्षम था। सभी का धन्यवाद!

हाँ, यह फिक्स 1.9.1 के बाद का है। @tianon ने कहा कि एक रिलीज की योजना है। आम तौर पर, यह उसी समय निकल जाता है docker रिलीज के लिए निकल जाता है। जैसा कि वे रिलीज पर 2 सप्ताह के चक्र का पालन करते हैं, मुझे उम्मीद है कि एक रिलीज आसन्न है। अंतरिम में, @ अकिहिरोसा ने एक फिक्स बनाया था जिसका उपयोग आप कर सकते हैं या आप अपना खुद का निर्माण कर सकते हैं, जो वास्तव में सीधा है बस समय लगता है।

धन्यवाद @AkihiroSuda छवि के लिए, यह काम करता है! :)

+1 डेबियन व्हीज़ी और उबंटू 15.04

@ जकीरखाम रिलीज़ 2 महीने का चक्र है, लेकिन हम बहुत जल्द ही 1.10-आरसी 1 जारी कर रहे हैं, बूट 2 डॉक के लिए एक आरसी 1 संस्करण भी होगा।

ओह, क्षमा करें, इसे मिलाया जाना चाहिए। मुझे सीधे सेट करने के लिए धन्यवाद, @tiborvass। क्या आपने उस @shusso को पकड़ा था?

@ जकीर्खम मैंने किया, धन्यवाद: +1:

मैं इस फिक्स का उपयोग करके डॉकटर-मशीन होस्ट वर्चुअलबॉक्स बनाने में सक्षम था:

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

वर्तमान में, डॉकटर-मशीन होस्ट करती है जिसे मैं गूगल कंप्यूट इंजन पर बनाता हूं, --driver google विकल्प के साथ, यह समस्या है। अलग .iso निर्दिष्ट करने के लिए Google ड्राइवर के पास कोई विकल्प नहीं है, इसलिए मैं ऊपर दिए गए फिक्स का उपयोग Google कंप्यूट पर नहीं कर सकता।

किसी को भी एक समाधान का पता है? या वास्तव में अगर Google को इस मुद्दे की जानकारी है, या मुझे उनके लिए बग रिपोर्ट कहां दर्ज करनी चाहिए।

क्या Google docker-machine ड्राइवर का रखरखाव docker या google द्वारा किया जाता है?

ड्राइवर यहां पाया जा सकता है; https://github.com/docker/machine/tree/master/drivers/google

मुझे लगता है कि Google गणना पर चलने वाली VM छवि यहां एक होनी चाहिए:

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

अर्थात्:

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

उपरोक्त के माध्यम से स्कैन करना, एक संभावित बदलाव ऐसा लगता है कि यह @nathanleclaire द्वारा सुझाया गया हो सकता है

$ docker-machine create -d google --engine-storage-driver ओवरले ओवरले

डॉकटर-मशीन के लिए Google ड्राइवर के लिए "--google-machine-image" विकल्प भी उपलब्ध है। आदेश:

$ gcloud गणना छवियों की सूची

उपलब्ध सार्वजनिक छवियों को सूचीबद्ध करता है। मुझे लगता है कि हाल ही में एक नई उबंटू विली को रखा गया है।

महज पुष्टि करने के लिए:

$ docker- मशीन create -d google --engine-storage-driver ओवरले ओवरले

काम किया। मैं भी तय बूट 2docker का उपयोग करके एक कस्टम मशीन छवि बनाने की जांच करूंगा, और उस डॉकर-मशीन के साथ जुड़ने की कोशिश करूंगा।

बूट 2docker पर किसी को भी मारने के लिए, कृपया आरसी को खत्म कर दें
https://github.com/tianon/boot2docker-legacy/releases/tag/v1.10.0-rc/ a
शॉट। : +1:

@tianon मैं निम्नलिखित छवि trecloux / docker-java-zombie के साथ इसका
और यह अच्छा लग रहा है .... लेकिन यह अभी भी akihirosuda / test18180 छवि के साथ लटका हुआ है

गंभीर रूप से प्रभावशाली काम @ अकिहिरोसा आप एक लगातार बग

@trecloux क्या आप btrfs का उपयोग कर रहे हैं और
यदि हां, तो यह एक ज्ञात मुद्दा है: https://github.com/docker/docker/issues/19073

@ अकिहिरसुदा मैं auf के साथ v1.10.0-rc1 बूट 2 डॉकटर छवि का उपयोग कर रहा हूं:

$ 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 यह अपेक्षित व्यवहार है। कुछ भी नहीं लटक रहा है।

@ अकिहिरसुदा ओके, सॉरी। और आपके प्रयास के लिए धन्यवाद :-)
तो @tianon : 1.10.0-rc1 अच्छा लग रहा है।

यहां भी यही समस्या। कै-सर्टिफिकेट सेट करने पर हैंग, CPU जाता है नट ...

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

MacOSX 10.11.2 चल रहा है

@sgoendoer ने docker-machine create --driver virtualbox --virtualbox-boot2docker-url="file:/path_to_the_image" nameofmachine साथ @AkihiroSuda की छवि का उपयोग करने का प्रयास किया

गैर बूट 2 डॉक उपयोगकर्ता के लिए, यह किस कर्नेल संस्करण के साथ तय किया जाएगा कोई भी विचार? 3.13.0-71 काम करने लगता है, 3.13.0-74 और 3.13.0-76 टूटा हुआ लगता है ...

एक ही मुद्दा यहाँ; तो इसके लिए कोई आसान तय नहीं है?
क्या यह आरसी संस्करण में तय है? कोशिश है कि अब एक हालांकि यह शायद अन्य मुद्दों का कारण बनता है।

नवीनतम क्विक वर्क्स (अपडेट: जनवरी 21 15:33 UTC)

| डिस्ट्रो | वर्कअराउंड |
| --- ---
| सामान्य | Devicemapper / Overlay / btrfs का उपयोग करें (लेकिन यह एक और समस्या का कारण हो सकता है ..) |
| Boot2Docker | : white_check_mark: अपग्रेड करने के लिए v1.10.0-rc1 |
| उबंटू 14.04LTS | : arrow_down: डाउन कर्नेल 3.13.0-71 या पुराने |
| उबंटू 15.04 | : arrow_down: डाउनग्रेड कर्नेल 3.19.0-39 या पुराने (: चेतावनी: परीक्षण नहीं किया गया) |
| उबंटू 15.10 | : arrow_down: डाउनग्रेड कर्नेल को 4.2.0-18 या पुराने |
| डेबियन 7/8 | : arrow_down: डाउनग्रेड कर्नेल संस्करण 3.16.7-ckt11 रिलीज़ 3.16.0 ( apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 ) या पुराने |
| डेबियन 9 | : white_check_mark: (कर्नेल का समर्थन नहीं करता है। 3.18-1 ~ exp1) |
| जेंटू | : white_check_mark: हाल ही में अपग्रेड करें: (चेतावनी: परीक्षण नहीं किया गया) |
| आरएचईएल / सेंटो | : white_check_mark: (AUFS का समर्थन नहीं करता) |
| ओपनएसयूएसई | : 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 |

@ अकिहिरोसुदा 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>

इस बार यह स्ट्रेस के माध्यम से सुलभ नहीं है, मुझे लगता है कि यह अभी भी संलग्न है भले ही यह नहीं है।
: ~ # स्ट्रेस -पी 23810

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

@wzrdtales
क्या आप https://github.com/docker/docker/issues/18180#issuecomment -166186061 में LWP स्टैक प्राप्त कर सकते हैं?
यह भी, कि आपका cmdline और phantomjs का संस्करण क्या है?

ज़रूर, प्रेत संस्करण: 1.9

cmdline

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

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

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

और यह भी कार्य ढेर:

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

सिस्टम जानकारी जोड़ने के लिए भी:

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

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

@wzrdtales क्या आप डेबियन पर डोकर (बूट 2 डॉक नहीं) v1.10.0-rc1 का उपयोग कर रहे हैं?
यह काम नहीं करता है क्योंकि मुद्दा डोकर के बजाय कर्नेल का एक बग है।

मैं डेबियन कर्नेल में देख रहा हूं और मैं सूची को https://github.com/docker/docker/issues/18180#issuecomment -1734363666 पर अपडेट करूंगा।

@ अकिहिरोसुदा वाई, यह सीधे डेबियन पर है। मैं आपकी सूची पर डेबियन बिंदु की देखरेख कर रहा हूं, जो इंगित करने के लिए धन्यवाद है :)

डेबियन के लिए, हमें 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 कर्नेल का उपयोग करें।

@ अकिहिरोसा : v3.16.7-ckt11 डाउनग्रेड करने की सिफारिश आपको CVE-2016-0728 के लिए जोखिम में डालती है, जिसमें एक सार्वजनिक सार्वजनिक वृद्धि है। मैंने अभी-अभी https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 , लेकिन डाउनग्रेड करने से पहले FYI किया।

@zmerlynn कि बाहर इशारा करने के लिए धन्यवाद!

सबसे तेजी से काम करता है (अपडेट: 26 जनवरी 1:49 UTC)

| डिस्ट्रो | वर्कअराउंड |
| --- ---
| सामान्य | Devicemapper / Overlay / btrfs का उपयोग करें (लेकिन यह एक और समस्या का कारण हो सकता है ..)।
यदि आप AUFS को उन्नत कर सकते हैं और मैन्युअल रूप से कर्नेल का निर्माण कर सकते हैं, तो आप AUFS v20160111 या बाद में भी उपयोग कर सकते हैं। |
| Boot2Docker | : white_check_mark: अपग्रेड करने के लिए v1.10.0-rc1 |
| उबंटू 14.04LTS | : arrow_down: डाउन कर्नेल 3.13.0-71 या पुराने |
| उबंटू 15.04 | : arrow_down: डाउनग्रेड कर्नेल 3.19.0-39 या पुराने (: चेतावनी: परीक्षण नहीं किया गया) |
| उबंटू 15.10 | : arrow_down: डाउनग्रेड कर्नेल को 4.2.0-18 या पुराने |
| डेबियन 7/8 | : arrow_down: डाउनग्रेड कर्नेल संस्करण 3.16.7-ckt11 रिलीज़ 3.16.0 ( apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 ) या पुराने |
| डेबियन 9 | : white_check_mark: (कर्नेल का समर्थन नहीं करता है। 3.18-1 ~ exp1) |
| जेंटू | : white_check_mark: हाल ही में अपग्रेड करें: (चेतावनी: परीक्षण नहीं किया गया) |
| आरएचईएल / सेंटो | : white_check_mark: (AUFS का समर्थन नहीं करता) |
| ओपनएसयूएसई | : white_check_mark: (AUFS का समर्थन नहीं करता) |

: चेतावनी: गिरी को अपग्रेड करना एक सुरक्षा जोखिम हो सकता है (जैसे, 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 |

हम इस समस्या से भी मिले, मोंगॉड 100% सीपीयू के साथ चल रहे आर राज्य में फंस गया है।

यहाँ सही स्टैक ट्रेस प्राप्त करने की वास्तविक चाल है जो मुझे यहाँ ले जाती है:

इको "l"> / proc / sysrq- ट्रिगर

वहाँ से, आप देख सकते हैं CPU 2 AUFS द्वारा एक इनफिनिटी लूप में फंस गया है

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

do_xino_fwrite द्वारा खोज मुझे यहीं ले जाती है!

मैं इस मुद्दे के साथ-साथ डेबियन स्ट्रेच पर भी मुठभेड़ कर रहा हूं जहां यह सैट स्थापित करने पर लटका हुआ है।

यहाँ त्रुटि संदेश है: https://gist.github.com/clball/738feb46094802a1bcf7
यहाँ संस्करण की जानकारी है: https://gist.github.com/clball/494fe8598dd0cdfd6d10
यहाँ dockerfile: https://gist.github.com/8778f8db143478d6c8ab है

तो यहां OSX के लिए क्या समाधान है, क्या पहले से ही एक डॉकटर अपडेट है?

अभी तक नहीं, लेकिन एक जारी उम्मीदवार है। (https://github.com/tianon/boot2docker-legacy/releases/tag/v1.10.0-rc2)

मेरे लिए समाधान स्टोरेज बैकेंड में परिवर्तन था।

/ Etc / default / docker में एक लाइन जोड़ें
¡¡BE CAREFUL आप अपना कंटेनर डेटा खो देंगे !!

DOCKER_OPTS="--storage-driver=devicemapper"

मेरा सुझाव है कि स्टॉप डॉकटर सेवा को मिटाएं, डॉक फ़ोल्डर को / var / lib पर मिटाएँ और फिर लाइन जोड़ें और docker सेवा को पुनः आरंभ करें।

@ रेफेरअप-टारेंटेग्यूई एक सिर के रूप में, 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-नहीं-तो-गहन-में-डोकर-भंडारण-drivers.html # 44
तथा
https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/ "डिवाइस मैपर और डॉकर प्रदर्शन"

रिलीज़ कैंडिडेट 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 |
| उबंटू 14.04LTS | : white_check_mark: अपग्रेड कर्नेल को 3.13.0-77.121hf1533043v2016060bb (PPA) |
| उबंटू 15.04 | : white_check_mark: अपग्रेड कर्नेल 3.19.0-49.55hf1533043v2016060bb (PPA) के लिए |
| उबंटू 15.10 | : white_check_mark: अपग्रेड कर्नेल को 4.2.0-27.32hf1533043v20160201b1 (PPA) |
| डेबियन 7/8 | : arrow_down: डाउनग्रेड कर्नेल संस्करण 3.16.7-ckt11 रिलीज़ 3.16.0 ( apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 ) या पुराने |
| डेबियन 9 | : white_check_mark: (कर्नेल का समर्थन नहीं करता है। 3.18-1 ~ exp1) |
| जेंटू | : white_check_mark: हाल ही में अपग्रेड करें: (चेतावनी: परीक्षण नहीं किया गया) |
| आरएचईएल / सेंटो | : white_check_mark: (AUFS का समर्थन नहीं करता) |
| ओपनएसयूएसई | : white_check_mark: (AUFS का समर्थन नहीं करता) |

वितरक टिकट जारी करते हैं

| डिस्ट्रो | स्थिति | अंक URL |
| --- --- ---
| Boot2Docker | : white_check_mark: बंद | https://github.com/boot2docker/boot2docker/pull/1113 |
| उबंटू | : white_medium_square: प्रगति में (ETA: फ़रवरी 20) | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043 |
| डेबियन | : white_medium_square: प्रगति में | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207 |

@ अकिहिरोसा , मुझे लगता है कि बूट 2docker के लिए आपका मतलब

@jakirkham धन्यवाद, लिंक तय किया।

rc3 मेरे कांटे के बजाय आधिकारिक रेपो पर है:
https://github.com/boot2docker/boot2docker/releases/tag/v1.10.0-rc3

हमने उस तकनीकी ऋण की जांच की, जिसने हमें अपने कांटे का उपयोग करने के लिए मजबूर किया और पाया
यह डॉक-मशीन 0.5 के बाद से तय किया गया था, इसलिए हम आगे बढ़ रहे हैं और
ऊपर की ओर। :मुस्कुराओ:

उबंटू पीपीए के लिए ऊपर सूचीबद्ध चिल्लुक-पैच संस्करणों के लिए गुठली स्विच करने की तलाश में उन लोगों के लिए btw। उदाहरण के लिए, 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 चलाएँ, फिर पैच किए गए नए कर्नेल बिल्ड में रीबूट करें। यदि आपने पहले ऐसा नहीं किया है, तो यहां एक गाइड है कि ग्रब में एक अलग डिफ़ॉल्ट कर्नेल कैसे

मैं इस बात की पुष्टि कर सकता हूं कि यह मुद्दा डॉकर 1.10.0 पर मौजूद नहीं है, जिसने ओएस एक्स 10.11 पर भी मेरी स्थिति तय कर दी है। वरना मैं १.९.० को अपग्रेड करने जा रहा था।

मैं अभी भी java 1.

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

@ अकिहिरोसुदा मैं आपके त्वरित

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

जब मैं @meateatlas सुझावों की कोशिश करता 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

software-properties-common आवश्यकता के बारे में टिप के लिए @jamshid धन्यवाद, मैंने ऊपर अपनी पोस्ट अपडेट की।

@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

डेबियन 8 पर apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt11-1+deb8u3 देता है

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

ckt11 पैकेज खोजने के लिए सक्रिय googlening का एक घंटा मदद नहीं करता था।
कृपया, हाल ही के डेबियन 8 कर्नेल को डाउनग्रेड करने का कोई सुझाव?

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

@davojan आप पहले से स्थापित /var/cache/apt/archives । आपको dpkg -i <old_package>.deb साथ डाउनग्रेड करने में सक्षम होना चाहिए।

पुष्टि की कि PPA से नया कर्नेल स्थापित करना मेरे लिए समस्या (Ubuntu 14.04.3 / कर्नेल 3.13.0-78-जेनेरिक / डॉकर 1.9.1) तय किया।
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043

क्या किसी ने डेबियन (उबंटू नहीं) के साथ काम करने का डाउनग्रेड निर्देश दिया है? मैं सोच रहा हूँ कि क्या कारण है कि मेरी apt-get update नीचे की त्रुटि (ppa रेपो को जोड़ने के बाद) में विफल रही है:

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

क्या केवल ubuntu पैकेज https://launchpad.net/~chiluk/+archive/ubuntu/1533043 पर उपलब्ध हैं

@jamshid उबंटु

यदि 3.16.7-ckt11-1 + deb8u3 दुर्भाग्य से उपलब्ध नहीं है, तो आप नवीनतम कर्नेल को पैच कर सकते हैं: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207/47

(मैं किसी को जरूरत पड़ने पर डिबेट पैकेज अपलोड कर सकता हूं)

अगर किसी को कर्नेल की आवश्यकता है, तो मैंने इसे यहां अपलोड किया है, यह deb8u3 की तुलना में थोड़ा नया है, लेकिन ऐसा नहीं लगता है कि इसमें बग होगा, कम से कम मैं इसे चलाने में काफी समय तक नहीं चला, लेकिन पैचिंग नवीनतम कर्नेल शायद बेहतर समाधान है। हालांकि अगर आपको इसकी आवश्यकता है:
https://wizardtales.com/linux-image-3.16.0-0.bpo.4-amd64_3.16.7-ckt11-1+deb8u6~bpo70+1_amd64.deb

@wzrdtales : +1:

मेरे जैसे उन लोगों के लिए जो अभी भी इस छंटनी के लिए संघर्ष कर रहे हैं, मैं आपको टीआईएनआई को एक अच्छा समाधान के रूप में इंगित करना चाहता हूं:
https://github.com/krallin/tini

डॉकफाइल में कुछ पंक्तियों के साथ मुझे एक सभ्य init प्रक्रिया मिली जो लाश को निकालने में सक्षम थी।
यह devicemapper के लिए संक्रमण से बचने की अनुमति देगा।

चीयर्स,
फ्रांसेस्को

इसलिए, मैं तीनी का उपयोग करता हूं। हालाँकि, इससे मुझे यहाँ मदद नहीं मिली क्योंकि मुझे जो समस्या आई थी, जबकि छवि का निर्माण किया जा रहा था।

कंटेनर चलाते समय, मैं टिनी का उपयोग करता हूं, लेकिन इसने मुझे प्रभावित किया।

@fflatorre
जानकारी के लिए धन्यवाद, लेकिन जिस ज़ोंबी मुद्दे को सुलझा सकती है वह इस मुद्दे से अलग लगता है।
https://github.com/docker/docker/issues/18180#issuecomment -167042078

दरअसल, तिनी के साथ भी हम एक ज़ोंबी प्राप्त कर सकते हैं:

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

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

@AkihiroSuda @jakirkham उल्लेख करना भूल जाता हूं कि हम छवि बनाते समय इस समस्या का सामना नहीं कर रहे हैं। हम एक बहुत ही मूल छवि बनाते हैं और फिर प्रोविज़निंग तर्क को एक स्क्रिप्ट के स्क्रिप्ट के एक समूह में सौंप दिया जाता है। प्रोविज़निंग के दौरान एक प्रक्रिया (काफ्का) लटकती थी। TINI अब तक उस मुद्दे को कम करने के लिए लगता है।
मैं स्वीकार करता हूं कि यह आपके लिए समाधान नहीं हो सकता है, वास्तव में मैं इसे वर्कअराउंड से प्लेसबो में डाउनग्रेड करने का सुझाव दूंगा :)
आशा है कि हम जल्द ही हल कर सकते हैं।

मेरे पास OSX 10.11.3 पर डॉकर 1.9.1 को चलाने का एक ही मुद्दा था:

$ docker -v
Docker version 1.9.1, build a34a1d5

नवीनतम डॉकटर टूलबॉक्स रिलीज़ को अपग्रेड करना:

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

@ schmunk42
मैं भी पृष्ठ तक नहीं पहुँच सका।
मुझे लगता है कि चिलुक रीमेक पैकेज है। आप उनसे https://bugs.launchpad.net/ubuntu/+source/linux/+bug/340343 पर पूछ सकते हैं

जिन लोगों के साथ यह समस्या हो रही है, उनके लिए यहाँ पर समस्या का समाधान Ubuntu 14.04 पर -proposed कर्नेल का उपयोग करके किया गया है। एक बार कर्नेल मुख्य शाखा में स्नातक होने के बाद यह निश्चित रूप से प्रासंगिक नहीं होगा।

शुरू करने से पहले, हम यह पुष्टि कर सकते हैं कि हम एक प्रभावित कर्नेल पर चल रहे हैं (यानी <3.19.0-50 Ubuntu 14.04 पर):

$ uname -r
3.19.0-49-generic

जब से हम जानते हैं, यह, हम पहले चल रहे द्वारा प्रस्तावित संकुल को

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

उस के साथ, अद्यतन कर्नेल स्थापित करें:

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

और चलो रिबूट

$ sudo shutdown -r now

रिबूट के बाद, हम पुष्टि कर सकते हैं कि नवीनतम अब नवीनतम कर्नेल पर चल रहे हैं:

$ uname -r
3.19.0-50-generic

धन्यवाद @vpetersson यह जानने की कोशिश कर रहा है कि जब कर्नेल का यह संस्करण जारी होगा तो क्या होगा, क्या यह प्रस्तावित स्थापित को अधिलेखित कर देगा या क्या आपको वापस सामान्य स्थिति में जाने के लिए कुछ करना होगा?

@IainColledge हाँ, मुझे लगता है कि ऐसा ही होगा, लेकिन मुझे पूरा यकीन नहीं है।

उबंटू और डेबियन के बारे में तालिका अपडेट की गई।

सबसे तेजी से काम करता है

| डिस्ट्रो | वर्कअराउंड |
| --- ---
| सामान्य | Devicemapper / Overlay / btrfs का उपयोग करें (लेकिन यह एक और समस्या का कारण हो सकता है ..)।
यदि आप AUFS को उन्नत कर सकते हैं और मैन्युअल रूप से कर्नेल का निर्माण कर सकते हैं, तो आप AUFS v20160111 या बाद में भी उपयोग कर सकते हैं। |
| Boot2Docker | : white_check_mark: v1.10.0 या बाद में अपग्रेड करें |
| उबंटू 14.04LTS | : white_check_mark: अपग्रेड कर्नेल को 3.13.0-79.123 या बाद में |
| उबंटू 15.04 | : white_check_mark: अपग्रेड कर्नेल को 3.19.0-51.57 या बाद में |
| उबंटू 15.10 | : white_check_mark: अपग्रेड कर्नेल को 4.2.0-30.35 या बाद में |
| डेबियन 7/8 | : arrow_down: डाउनग्रेड कर्नेल संस्करण 3.16.7-ckt11 रिलीज 3.16.0 या पुराने ( @ wzrdtales द्वारा
| डेबियन 9 | : white_check_mark: (कर्नेल का समर्थन नहीं करता है। 3.18-1 ~ exp1) |
| जेंटू | : white_check_mark: हाल ही में अपग्रेड करें: (चेतावनी: परीक्षण नहीं किया गया) |
| आरएचईएल / सेंटो | : white_check_mark: (AUFS का समर्थन नहीं करता) |
| ओपनएसयूएसई | : 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" डेबियन कर्नेल को पैच के साथ रखना चाहता है, तो पहले उल्लेख किया गया है - मैंने इसे मैन्युअल रूप से बनाया है, और यह https://fxposter.org/linux -image-3.16 पर है

गजब का! मुझे अब कुछ हफ्तों से यह समस्या हो रही है, और मुझे लगता है कि उबंटू के लिए फिक्स कल ही जारी किया गया था: पी

इस बात की पुष्टि करते हुए कि नवीनतम 14.04LTS कर्नेल अपडेट 3.19.0-51 में मेरे जावा लाश पर समाप्त हो गया है। धन्यवाद!

डेबियन ने इस मुद्दे का समर्थन किया।

सबसे तेजी से काम करता है

| डिस्ट्रो | वर्कअराउंड |
| --- ---
| सामान्य | Devicemapper / Overlay / btrfs का उपयोग करें (लेकिन यह एक और समस्या का कारण हो सकता है ..)।
यदि आप AUFS को उन्नत कर सकते हैं और मैन्युअल रूप से कर्नेल का निर्माण कर सकते हैं, तो आप AUFS v20160111 या बाद में भी उपयोग कर सकते हैं। |
| Boot2Docker | : white_check_mark: v1.10.0 या बाद में अपग्रेड करें |
| उबंटू 14.04LTS | : white_check_mark: अपग्रेड कर्नेल को 3.13.0-79.123 या बाद में |
| उबंटू 15.04 | : white_check_mark: अपग्रेड कर्नेल को 3.19.0-51.57 या बाद में |
| उबंटू 15.10 | : white_check_mark: अपग्रेड कर्नेल को 4.2.0-30.35 या बाद में |
| डेबियन 7 | : white_check_mark: अपग्रेड कर्नेल को 3.2.73-2 + deb7u3 (linux-image-3.2.0-4-amd64 पैकेज के लिए) या बाद में |
| डेबियन 8 | : white_check_mark: अपग्रेड कर्नेल को 3.16.7-ckt20-1 + deb8u4 (linux-image-3.16.0-4-amd64 पैकेज के लिए) या बाद में |
| डेबियन 9 | : white_check_mark: (कर्नेल का समर्थन नहीं करता है। 3.18-1 ~ exp1) |
| जेंटू | : white_check_mark: हाल ही में अपग्रेड करें: (चेतावनी: परीक्षण नहीं किया गया) |
| आरएचईएल / सेंटो | : white_check_mark: (AUFS का समर्थन नहीं करता) |
| ओपनएसयूएसई | : 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:

मैं बूटएक्सडायकर संस्करण 1.10.2 पर ओएसएक्स पर हूं, मास्टर बनाएँ: 611be10, डॉकर संस्करण 1.10.2, c3959b1 का निर्माण करें और पहली बार इसे डॉकटर-कंपोज से प्राप्त करें:

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

फिर docker kill 38e1e2590dfa की कोशिश की लेकिन प्रक्रिया हमेशा के लिए लटक गई। docker.log:

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

बस एक नोट के रूप में (मुझे पता है कि यह बंद है लेकिन निश्चित नहीं है कि यह एक नए मुद्दे के रूप में खुलने का मतलब है)। मैं एक बाद के संस्करण पर एक ही मुद्दा रहा था जब तक मैं devmapper पर स्विच नहीं किया।

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

@einhverfr यह मुद्दा कर्नेल में तय किया गया है। 3.13.0-79.123 (आपका कोई 3.13.0-77 लगता है)

क्या यह मुद्दा वास्तव में कर्नेल उन्नयन के साथ हल किया जा सकता है? हम उबंटू 14.04 पर डॉकटर 1.9.1 के साथ कर्नेल 3.13.0-83-जेनेरिक के साथ एक ही समस्या का सामना कर रहे हैं।

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