Moby: नाम / "डेटा-कंटेनर-नाम" पहले से ही कंटेनर द्वारा उपयोग किया जाता है<hash>। आपको उस नाम का पुन: उपयोग करने में सक्षम होने के लिए उस कंटेनर को निकालना (या नाम बदलना होगा)।</hash>

आपने उन कंटेनरों को कैसे साफ किया? कोई भी अपवाद तब होता है जब आप उन संसाधनों (वॉल्यूम नेटवर्क इत्यादि) को साफ करते हैं?

मेरे पास सब कुछ करने के लिए एक हेल्पर फंक्शन है ताकि हमारे कंटीन्यूअस ब्लाह, साइकल को टेस्ट किया जा सके, erm ... लगातार। मूल रूप से यह निम्नलिखित को उबालता है:

कंटेनरों को साफ करने के लिए:

docker rm -f $(docker ps -a -q)

छवियों को साफ़ करने के लिए:

docker rmi -f $(docker images -a -q)

वॉल्यूम साफ़ करने के लिए:

docker volume rm $(docker volume ls -q)

नेटवर्क साफ़ करने के लिए:

docker network rm $(docker network ls | tail -n+2 | awk '{if($2 !~ /bridge|none|host/){ print $1 }}')

मेरे पास एक झुंड समूह है जहां कंटेनर को ci प्रयोजनों के लिए ऊपर और नीचे लाया जा रहा है और मुझे भी यही समस्या है। मेरे मामले में मुझे मशीन को फिर से चालू करने की आवश्यकता नहीं है, आमतौर पर सभी कंटेनरों को मारना है

$ docker rm -f $(docker ps -a -q)

तब पुनः आरंभ करने वाला

$ sudo service docker restart

और फिर झुंड को फिर से बनाना इसे ठीक करता है।

यहाँ एक विशिष्ट विफलता का लॉग है। मैं झुंड के खिलाफ झुंड नोड्स में से एक पर कमांडर रचना करने के लिए ansible का उपयोग करता हूं।

TASK: [Run docker-compose up] ************************************************* 
failed: [XX.XX.XX.XX] => {"changed": true, "cmd": ["/usr/local/bin/docker-compose", "-f", "/containers/docker-compose/docker-compose-booking-pre-eng-811.yml", "--project-name", "booking-eng-811", "--verbose", "up", "-d"], "delta": "0:00:00.355991", "end": "2016-06-15 12:02:11.623256", "rc": 255, "start": "2016-06-15 12:02:11.267265", "warnings": []}
stderr: compose.config.config.find: Using configuration files: /containers/docker-compose/docker-compose-booking-pre-eng-811.yml
docker.auth.auth.load_config: Found 'auths' section
docker.auth.auth.parse_auth: Found entry (registry=u'my-private-registry', username=u'redacted-username')
compose.cli.command.get_client: docker-compose version 1.7.1, build 0a9ab35
docker-py version: 1.8.1
CPython version: 2.7.9
OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013
compose.cli.command.get_client: Docker base_url: http://127.0.0.1:4000
compose.cli.command.get_client: Docker version: KernelVersion=3.10.0-327.18.2.el7.x86_64, Os=linux, BuildTime=Fri May 27 17:25:03 UTC 2016, ApiVersion=1.22, Version=swarm/1.2.3, GitCommit=eaa53c7, Arch=amd64, GoVersion=go1.5.4
compose.cli.verbose_proxy.proxy_callable: docker inspect_network <- ('back')
compose.cli.verbose_proxy.proxy_callable: docker inspect_network -> {u'Containers': {u'0f4c1b89e2ae9476a53f07552f678d2914bb391d1d80ab051f74925eb9fbf65a': {u'EndpointID': u'5f07ba0940ffcb4b0c2f0acf5424b6976b28bd8344a56b0464ab6517da884bc8',
                                                                                       u'IPv4Address': u'10.0.0.3/24',
                                                                                       u'IPv6Address': u'',
                                                                                       u'MacAddress': u'02:42:0a:00:00:03',
                                                                                       u'Name': u'registrator_registrator_1'},
                 u'782c1d07d51f6871400da38e8840e81e9300f54a195b9e6ff2e931b23274655a': {u'EndpointID': u'c8654b5b73eaca7f630d6e2c4c898122a3ae6a86bd0cfab68a8654414fe4821a',
                                                                                       u'IPv4Address': u'10.0.0.2/24',
                                                                                       u'IPv6Address': u'',
                                                                                       u'MacAddress': u'02:42:0a:00:00:02',
                                                                                       u'Name': u'stdb1'},
...
compose.network.ensure: Network back declared as external. No new network will be created.
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=False, filters={u'label': [u'com.docker.compose.project=bookingeng811', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=bookingeng811', u'com.docker.compose.service=redis1', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=bookingeng811', u'com.docker.compose.service=web', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=bookingeng811', u'com.docker.compose.service=api_locations', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=bookingeng811', u'com.docker.compose.service=booking', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.cli.verbose_proxy.proxy_callable: docker inspect_image <- ('redis:2.8.21')
compose.cli.verbose_proxy.proxy_callable: docker inspect_image -> {u'Architecture': u'amd64',
 u'Author': u'',
 u'Comment': u'',
 u'Config': {u'AttachStderr': False,
             u'AttachStdin': False,
             u'AttachStdout': False,
             u'Cmd': [u'redis-server'],
             u'Domainname': u'',
             u'Entrypoint': [u'/entrypoint.sh'],
             u'Env': [u'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin',
...
compose.cli.verbose_proxy.proxy_callable: docker inspect_image <- ('my-private-registry/web:master')
compose.cli.verbose_proxy.proxy_callable: docker inspect_image -> {u'Architecture': u'amd64',
 u'Author': u"Emmet O'Grady",
 u'Comment': u'',
 u'Config': {u'ArgsEscaped': True,
             u'AttachStderr': False,
             u'AttachStdin': False,
             u'AttachStdout': False,
             u'Cmd': [u'/bin/sh', u'-c', u'/entrypoint.sh'],
             u'Domainname': u'',
             u'Entrypoint': None,
...
compose.cli.verbose_proxy.proxy_callable: docker inspect_image <- ('my-private-registry/api-locations:master')
compose.cli.verbose_proxy.proxy_callable: docker inspect_image -> {u'Architecture': u'amd64',
 u'Author': u"Emmet O'Grady",
 u'Comment': u'',
 u'Config': {u'ArgsEscaped': True,
             u'AttachStderr': False,
             u'AttachStdin': False,
             u'AttachStdout': False,
             u'Cmd': [u'/bin/sh', u'-c', u'/entrypoint.sh'],
             u'Domainname': u'',
             u'Entrypoint': None,
...
compose.cli.verbose_proxy.proxy_callable: docker inspect_image <- ('my-private-registry/booking:eng-811')
compose.cli.verbose_proxy.proxy_callable: docker inspect_image -> {u'Architecture': u'amd64',
 u'Author': u'',
 u'Comment': u'',
 u'Config': {u'ArgsEscaped': True,
             u'AttachStderr': False,
             u'AttachStdin': False,
             u'AttachStdout': False,
             u'Cmd': [u'/bin/sh', u'-c', u'/entrypoint.sh'],
             u'Domainname': u'',
             u'Entrypoint': None,
...
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=bookingeng811', u'com.docker.compose.service=redis1', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.project._get_convergence_plans: web has upstream changes (redis1)
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=bookingeng811', u'com.docker.compose.service=web', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.project._get_convergence_plans: api_locations has upstream changes (redis1)
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=bookingeng811', u'com.docker.compose.service=api_locations', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.project._get_convergence_plans: booking has upstream changes (redis1)
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=bookingeng811', u'com.docker.compose.service=booking', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.parallel.feed_queue: Pending: set([<Service: web>, <Service: redis1>, <Service: api_locations>, <Service: booking>])
compose.parallel.feed_queue: Starting producer thread for <Service: redis1>
compose.cli.verbose_proxy.proxy_callable: docker inspect_image <- ('redis:2.8.21')
compose.cli.verbose_proxy.proxy_callable: docker inspect_image -> {u'Architecture': u'amd64',
 u'Author': u'',
 u'Comment': u'',
 u'Config': {u'AttachStderr': False,
             u'AttachStdin': False,
             u'AttachStdout': False,
             u'Cmd': [u'redis-server'],
             u'Domainname': u'',
             u'Entrypoint': [u'/entrypoint.sh'],
             u'Env': [u'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin',
...
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=bookingeng811', u'com.docker.compose.service=redis1', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.cli.verbose_proxy.proxy_callable: docker inspect_image <- ('redis:2.8.21')
compose.cli.verbose_proxy.proxy_callable: docker inspect_image -> {u'Architecture': u'amd64',
 u'Author': u'',
 u'Comment': u'',
 u'Config': {u'AttachStderr': False,
             u'AttachStdin': False,
             u'AttachStdout': False,
             u'Cmd': [u'redis-server'],
             u'Domainname': u'',
             u'Entrypoint': [u'/entrypoint.sh'],
             u'Env': [u'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin',
...
compose.service.build_container_labels: Added config hash: ae3be0880fdcb78073a419c6102617b730bfb42171c8204bf51e5c36eb8a85f3
compose.cli.verbose_proxy.proxy_callable: docker create_host_config <- (memswap_limit=None, links=[], devices=None, pid_mode=None, log_config={'Type': u'', 'Config': {}}, cpu_quota=None, read_only=None, dns=None, volumes_from=[], port_bindings={}, security_opt=None, extra_hosts=None, cgroup_parent=None, network_mode='back', shm_size=None, tmpfs=None, cap_add=None, restart_policy={u'MaximumRetryCount': 0, u'Name': u'always'}, dns_search=None, privileged=False, binds=[], ipc_mode=None, mem_limit='64M', cap_drop=None, ulimits=None)
compose.cli.verbose_proxy.proxy_callable: docker create_host_config -> {'Binds': [],
 'Links': [],
 'LogConfig': {'Config': {}, 'Type': u''},
 'Memory': 67108864L,
 'NetworkMode': 'back',
 'PortBindings': {},
 'RestartPolicy': {u'MaximumRetryCount': 0, u'Name': u'always'},
 'VolumesFrom': []}
compose.service.create_container: Creating bookingeng811_redis1_1
compose.cli.verbose_proxy.proxy_callable: docker create_container <- (name=u'bookingeng811_redis1_1', image='redis:2.8.21', labels={u'com.docker.compose.service': u'redis1', u'com.docker.compose.project': u'bookingeng811', u'com.docker.compose.config-hash': 'ae3be0880fdcb78073a419c6102617b730bfb42171c8204bf51e5c36eb8a85f3', u'com.docker.compose.version': u'1.7.1', u'com.docker.compose.oneoff': u'False', u'com.docker.compose.container-number': '1'}, host_config={'NetworkMode': 'back', 'Links': [], 'PortBindings': {}, 'Binds': [], 'RestartPolicy': {u'MaximumRetryCount': 0, u'Name': u'always'}, 'Memory': 67108864L, 'LogConfig': {'Type': u'', 'Config': {}}, 'VolumesFrom': []}, environment=[], volumes={}, detach=True, networking_config={u'EndpointsConfig': {'back': {u'IPAMConfig': {}, u'Aliases': ['redis1']}}})
compose.parallel.parallel_execute_iter: Failed: <Service: redis1>
compose.parallel.feed_queue: Pending: set([<Service: booking>, <Service: api_locations>, <Service: web>])
compose.parallel.feed_queue: <Service: booking> has upstream errors - not processing
compose.parallel.feed_queue: <Service: api_locations> has upstream errors - not processing
compose.parallel.feed_queue: <Service: web> has upstream errors - not processing
compose.parallel.parallel_execute_iter: Failed: <Service: booking>
compose.parallel.feed_queue: Pending: set([])
compose.parallel.parallel_execute_iter: Failed: <Service: api_locations>
compose.parallel.feed_queue: Pending: set([])
compose.parallel.parallel_execute_iter: Failed: <Service: web>
compose.parallel.feed_queue: Pending: set([])

ERROR: for redis1  Error response from daemon: Conflict. The name "/bookingeng811_redis1_1" is already in use by container 5ecf77fc7bbad0548cf34c891ac4d043b2692816b63ed97744924bc1296b8e65. You have to remove (or rename) that container to be able to reuse that name.
Traceback (most recent call last):
  File "<string>", line 3, in <module>
  File "compose/cli/main.py", line 63, in main
AttributeError: 'ProjectError' object has no attribute 'msg'
docker-compose returned -1

मैंने मैन्युअल रूप से "Bookeng811_redis1_1" नामक कंटेनर को हटाने की कोशिश की है, लेकिन यह कहीं भी मौजूद नहीं है।

वहां भी यही समस्या है।

मैं अक्सर चक्र दोहराता हूं:

• डॉकटर% नाम% रोक
• docker rm -f% नाम%
• डॉकटर% नाम%
• डॉक रन% नाम%

कुछ बिंदु पर (2 - 3 दिन) यह काम करना बंद कर देता है:
docker: त्रुटि डेमन से प्रतिक्रिया: संघर्ष। "% Name%" नाम पहले से ही कंटेनर% कंटेनर_id% के उपयोग में है । आपको उस नाम का पुन: उपयोग करने में सक्षम होने के लिए उस कंटेनर को निकालना (या नाम बदलना) होगा।

जब मैं कंटेनर% कंटेनर_ड% को मैन्युअल रूप से हटाने का प्रयास करता हूं तो यह कहता है:
कंटेनर निकालने में विफल (% container_id%): डेमन से त्रुटि प्रतिक्रिया: ऐसा कोई कंटेनर नहीं:% container_id%

कंटेनर% container_id% सूची docker ps -a में नहीं और फ़ोल्डर / var / lib / docker / कंटेनर में नहीं

शायद समस्या की जड़ -f पैरामीटर के साथ कंटेनर को हटा रही है? इसलिए डॉकटर सही तरीके से सफाई नहीं करता है और डॉकटर डेमन को लगता है कि कंटेनर अभी भी है।

डोकर संस्करण आउटपुट:

ग्राहक:
संस्करण: 1.10.3
एपीआई संस्करण: 1.22
जाओ संस्करण: go1.5.3
Git प्रतिबद्ध: 8acee1b
बनाया:
OS / Arch: linux / amd64

सर्वर:
संस्करण: 1.10.3
एपीआई संस्करण: 1.22
जाओ संस्करण: go1.5.3
Git कमिट: 8acee1b
बनाया:
OS / Arch: linux / amd64

डोकर जानकारी आउटपुट:

कंटेनर: 27
चल रहा है: 13
रुका हुआ: ०
रोका: 14
चित्र: 1512
सर्वर संस्करण: 1.10.3
स्टोरेज ड्राइवर: devicemapper
पूल का नाम: docker-8: 9-521647- पूल
पूल अवरोधक: 65.54 kB
बेस डिवाइस का आकार: 107.4 जीबी
बैकिंग फाइलसिस्टम: xfs
डेटा फ़ाइल: / dev / loop2
मेटाडेटा फ़ाइल: / dev / loop3
डेटा स्पेस प्रयुक्त: 53.62 जीबी
डेटा स्पेस कुल: 107.4 जीबी
डेटा स्पेस उपलब्ध: 53.76 जीबी
मेटाडाटा स्पेस प्रयुक्त: 129.9 एमबी
मेटाडाटा स्पेस कुल: 2.147 जीबी
मेटाडाटा स्पेस उपलब्ध: 2.018 जीबी
उदय सिंक समर्थित: सच
आस्थगित निष्कासन सक्षम: असत्य
आस्थगित विलोपन सक्षम: असत्य
आस्थगित नष्ट डिवाइस गणना: 0
डेटा लूप फ़ाइल: / var / lib / docker / devicemapper / devicemapper / data
चेतावनी: उत्पादन उपयोग के लिए लूपबैक उपकरणों का उपयोग दृढ़ता से हतोत्साहित किया जाता है। या तो --storage-opt dm.thinpooldev उपयोग करें या इस चेतावनी को दबाने के लिए --storage-opt dm.no_warn_on_loop_devices=true का उपयोग करें।
मेटाडेटा लूप फ़ाइल: / var / lib / docker / devicemapper / devicemapper / मेटाडेटा
लाइब्रेरी संस्करण: 1.02.93 (2015-01-30)
निष्पादन चालक: देशी-0.2
लॉगिंग ड्राइवर: json-file
प्लग-इन:
मात्रा: स्थानीय
नेटवर्क: मेजबान पुल अशक्त
कर्नेल संस्करण: 4.5.0-coreos-r1
ऑपरेटिंग सिस्टम: CoreOS 1010.5.0 (MoreOS)
ऑस्टाइप: लाइनक्स
आर्किटेक्चर: x86_64
सीपीयू: 8
कुल मेमोरी: 11.74 GiB
नाम: xx-slave
ID: LVGE: QBNA : DXFP: AWR7 : NAVO: LQLR : 7 CGF: UDOF : CTES: VZQJ : SRZJ: JLKW

डॉकटर कंटेनर के संदर्भ को बचाने के लिए 'nameIndex' का उपयोग करते हैं। विवरण से, ऐसा लगता है कि मुद्दा इसलिए है क्योंकि हटाए गए कंटेनरों के साथ nameIndex आउट-ऑफ-सिंक है। यहीं से त्रुटि वापस हो जाती है।

हम अस्थाई रूप से समस्या को दूर करने के लिए आउट-ऑफ-सिंक नामइंडेक्स को साफ करने में सक्षम हो सकते हैं। हालांकि डॉकर्स nameIndex अलावा कई सूचकांकों (जैसे, linkIndex) का उपयोग करते हैं, इसलिए ऐसे कई स्थान हो सकते हैं, जिनकी सफाई की आवश्यकता है। यह पता लगाना कि लंबे समय में आउट-ऑफ-सिंक कहां बेहतर समाधान हो सकता है।

वहाँ सिंक नाम के बाहर साफ करने के लिए कोई रास्ता नहीं है Indexexes?
अब मेरे पास एकमात्र उपाय नोड को रिबूट करना है जो अच्छा नहीं है। रिबूटिंग डॉकटर डेमॉन भी अच्छा नहीं है।

मेरे लिए क्या काम करता है डॉकटर डेमन को रोकना, /var/lib/docker/* से सब कुछ हटा दें और फिर से डॉक शुरू करें। यह एक निरंतर एकीकरण सर्वर है इसलिए मैं डॉकटर संदर्भ में लोड की गई किसी भी छवि को नहीं संभाल सकता हूं, इसलिए यह मेरे लिए काम करता है, वाईएमएमवी।

मैं १.१०.३ पर समान व्यवहार देख रहा हूं

Containers: 105
 Running: 75
 Paused: 0
 Stopped: 30
Images: 1434
Server Version: 1.10.3
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Plugins: 
 Volume: local
 Network: bridge null host
Kernel Version: 4.5.0-coreos-r1
Operating System: CoreOS 1010.5.0 (MoreOS)
OSType: linux
Architecture: x86_64

हम इस समस्या को CoreOS और Docker 1.10.3 पर हर दिन देख रहे हैं:

 # journalctl -fu docker
Aug 22 12:37:53 stateless-0.novalocal dockerd[8215]: time="2016-08-22T12:37:53.857617384+10:00" level=error msg="Handler for POST /v1.22/containers/create returned error: Conflict. The name \"/bridge-clockwork\" is already in use by container a9710d980f2935638df62e67175e28078753818a8b7e1e20bd2840d738dd58c0. You have to remove (or rename) that container to be able to reuse that name."

# docker inspect a9710d980f2935638df62e67175e28078753818a8b7e1e20bd2840d738dd58c0
Error: No such image or container: a9710d980f2935638df62e67175e28078753818a8b7e1e20bd2840d738dd58c0

# docker rm -f a9710d980f2935638df62e67175e28078753818a8b7e1e20bd2840d738dd58c0
Failed to remove container (a9710d980f2935638df62e67175e28078753818a8b7e1e20bd2840d738dd58c0): Error response from daemon: No such container: a9710d980f2935638df62e67175e28078753818a8b7e1e20bd2840d738dd58c0

सभी मामलों के 50% में, docker daemon को पुनरारंभ करने से समस्या ठीक हो जाती है। अन्य मामलों में, हमें rr -rf / var / lib / docker करना होगा। दोनों वर्कअराउंड उत्पादन कार्यभार के लिए विघटनकारी हैं।

@cdwertmann यदि आपको rm -rf /var/lib/docker , तो इसका मतलब है कि उस नाम के साथ एक कंटेनर मौजूद है और यह डेमॉन के पुनरारंभ होने के बाद पुनः लोड हो रहा है। यदि आपको इन कंटेनरों को हटाने की कोशिश करते समय समान त्रुटियां हो रही हैं, तो यह देखना बहुत उपयोगी होगा कि /var/lib/docker/containers/<id> में क्या है

@ cpuguy83 यहाँ कंटेनर निर्देशिका के अंदर क्या है:

 # ls /var/lib/docker/containers/69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a/ -lah
total 184K
drwx------.  3 root root 4.0K Aug 20 23:14 .
drwx------. 16 root root 4.0K Aug 23 14:41 ..
-rw-r-----.  1 root root 102K Aug 23 14:39 69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a-json.log
-rw-r--r--.  1 root root 2.9K Aug 23 14:41 config.v2.json
-rw-r--r--.  1 root root  975 Aug 23 14:41 hostconfig.json
-rw-r--r--.  1 root root   17 Aug 20 23:14 hostname
-rw-r--r--.  1 root root  185 Aug 20 23:14 hosts
-rw-r--r--.  1 root root   45 Aug 20 23:14 resolv.conf
-rw-r--r--.  1 root root   71 Aug 20 23:14 resolv.conf.hash
drwx------.  2 root root 4.0K Aug 20 23:14 shm

Config.v2.json में मैं "RemovalInProgress":true देख सकता हूं:

# cat /var/lib/docker/containers/69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a/config.v2.json 
{"State":{"Running":false,"Paused":false,"Restarting":false,"OOMKilled":false,"RemovalInProgress":true,"Dead":true,"Pid":0,"ExitCode":2,"Error":"","StartedAt":"2016-08-20T13:14:17.864964407Z","FinishedAt":"2016-08-23T04:41:29.775183062Z"},"ID":"69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a","Created":"2016-08-20T13:13:58.579971761Z","Path":"/bin/registrator","Args":["-ip","172.16.0.102","-resync","300","consul://172.16.0.102:8500"],"Config":{"Hostname":"sphinx","Domainname":"novalocal","User":"","AttachStdin":false,"AttachStdout":true,"AttachStderr":true,"Tty":false,"OpenStdin":false,"StdinOnce":false,"Env":["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"],"Cmd":["-ip","172.16.0.102","-resync","300","consul://172.16.0.102:8500"],"Image":"registry/registrator","Volumes":null,"WorkingDir":"","Entrypoint":["/bin/registrator"],"OnBuild":null,"Labels":{},"StopSignal":"SIGTERM"},"Image":"sha256:3b59190c6c800907d7a62c245bf93888db802b00407002fff7e08fed24e5557e","NetworkSettings":{"Bridge":"","SandboxID":"7713b13649c7964520180342f99914dd4720833ed39a51793ed483c356e0bd85","HairpinMode":false,"LinkLocalIPv6Address":"","LinkLocalIPv6PrefixLen":0,"Networks":{"bridge":{"IPAMConfig":null,"Links":null,"Aliases":null,"NetworkID":"5c0baa715bb76ea2eb5a6a32deb36a8093391ba6c76e55f31768838560c10f22","EndpointID":"","Gateway":"","IPAddress":"","IPPrefixLen":0,"IPv6Gateway":"","GlobalIPv6Address":"","GlobalIPv6PrefixLen":0,"MacAddress":""}},"Ports":null,"SandboxKey":"/var/run/docker/netns/7713b13649c7","SecondaryIPAddresses":null,"SecondaryIPv6Addresses":null,"IsAnonymousEndpoint":false},"LogPath":"/var/lib/docker/containers/69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a/69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a-json.log","Name":"/registrator","Driver":"overlay","MountLabel":"system_u:object_r:svirt_lxc_file_t:s0:c631,c718","ProcessLabel":"system_u:system_r:svirt_lxc_net_t:s0:c631,c718","RestartCount":0,"HasBeenStartedBefore":true,"HasBeenManuallyStopped":false,"MountPoints":{"/etc/localtime":{"Source":"/etc/localtime","Destination":"/etc/localtime","RW":false,"Name":"","Driver":"","Relabel":"ro","Propagation":"rprivate","Named":false},"/tmp/docker.sock":{"Source":"/var/run/docker.sock","Destination":"/tmp/docker.sock","RW":true,"Name":"","Driver":"","Relabel":"","Propagation":"rprivate","Named":false}},"AppArmorProfile":"","HostnamePath":"/var/lib/docker/containers/69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a/hostname","HostsPath":"/var/lib/docker/containers/69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a/hosts","ShmPath":"/var/lib/docker/containers/69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a/shm","ResolvConfPath":"/var/lib/docker/containers/69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a/resolv.conf","SeccompProfile":""}

मैन्युअल रूप से /var/lib/docker/containers/69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a/ को हटाने और docker डेमन को पुनरारंभ करने के बाद, संघर्ष को हल किया गया था।

यहाँ वही देख रहे हैं:

docker -v      
Docker version 1.10.3, build 3cd164c
docker-compose -v
docker-compose version 1.8.0, build f3628c7
cat /etc/os-release 
NAME=CoreOS
ID=coreos
VERSION=1068.10.0
VERSION_ID=1068.10.0
BUILD_ID=2016-08-23-0220
PRETTY_NAME="CoreOS 1068.10.0 (MoreOS)"
ANSI_COLOR="1;32"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://github.com/coreos/bugs/issues" 

और इस तरह से मैं अपने कंटेनरों को शुरू / बंद / पुनः आरंभ करता हूं:

cat /etc/systemd/system/u\@.service 
[Unit]
Description=%p-%i

# Requirements
Requires=docker.service

# Dependency ordering
After=docker.service

[Service]
Restart=always
RestartSec=10
TimeoutStartSec=60
TimeoutStopSec=15
EnvironmentFile=-/data/domains/%i/env
WorkingDirectory=/data/domains/%i/
ExecStartPre=-/opt/bin/docker-compose rm -f
ExecStart=/bin/bash -euxc "VIRTUAL_HOST=%i /opt/bin/docker-compose up"
ExecStop=/opt/bin/docker-compose stop

[Install]
WantedBy=multi-user.target

मुझे एक ही त्रुटि मिली, और फिर, docker ps -a तहत कुछ भी नहीं, लेकिन कंटेनर हैश के साथ /var/lib/docker/containers तहत एक फ़ोल्डर था, मैंने हटा दिया, फिर भी कोई भाग्य नहीं। मैंने डॉकटर डेमॉन को फिर से शुरू किया, यह काम किया।

Https://github.com/docker/compose/issues/3277#issuecomment -238080180 के लिए यह समाधान भी इस समस्या को ठीक करता है ...

@marcelmfs मेरे लिए नहीं। मुझे पूरा /var/lib/docker हटाना होगा

अजीब है, मेरे लिए यह सिर्फ काम किया। मैं सुनिश्चित करने के लिए एक बार और कोशिश करूँगा।

@marcelmfs तो आपने सिर्फ

इतना ही नहीं, सभी चल रहे कंटेनरों को भी docker rm -f $(docker ps -aq) और शायद सभी नेटवर्क से हटा दिया, क्योंकि यह network/files/local-kv.db भी निकाल रहा है।

मुझे 1.12 पर अपग्रेड करने के बाद से इस मुद्दे को नहीं देखा गया है

क्या कोई और अभी भी 1.12.x के साथ इसे देख रहा है?

मुझे अभी भी जांच करने के लिए अपग्रेड करने की आवश्यकता है ... मैं कल अपग्रेड के लिए एक विंडो आवंटित करूंगा।

हमारे CI सर्वर को अपग्रेड किया गया है और हमने local-kv.db फ़ाइल को हटाने वाले वर्कअराउंड को हटा दिया है। अगले हफ्ते मुझे इस पर और खबर होगी।

यहाँ भी: 1.11.x में मुद्दा था, लेकिन 1.12.x के बाद से नहीं

हाँ, देखा कि कोई भी इस बारे में 1.12 में शिकायत नहीं कर रहा था।
आश्चर्य है कि हम क्या बदल गए, मैं निश्चित रूप से सीधे नामकरण से संबंधित कुछ भी नहीं हूं।

tl; dr: सभी संस्करण> = 1.10.0 प्रभावित होते हैं लेकिन> = 1.12.0 में ऐसा होने की संभावना बहुत कम होती है।

मैंने इस मुद्दे को कोड में ट्रेस किया और यह निश्चित रूप से सभी संस्करणों> = 1.10.0 पर हो सकता है, जहां nameIndex संरचना पेश की गई थी। जैसा कि @yongtang ने उल्लेख किया है, यह संरचना हटाए गए कंटेनरों के साथ सिंक से बाहर हो जाती है।

त्रुटि तब होती है जब भी nameIndex daemon.containers साथ सिंक से बाहर हो जाता है।

समस्या Daemon.create () फ़ंक्शन में है। nameIndex 64 में daemon.newContainer() लाइन से अपडेट किया जाता है, लेकिन daemon.containers लाइन में बहुत बाद में daemon.Register() अपडेट किया जाता है।

अगर इन दोनों के बीच कुछ भी विफल होता है, तो एक असंगत स्थिति में डॉकटर होता है। इससे पहले कि https://github.com/docker/docker/commit/114be249f022535f0800bd45987c4e9cd1b321a4 (1.12.0 में उतरा), वह सब जो इस मुद्दे को ट्रिगर करने की आवश्यकता थी। उस कमिट ने docker.ContainerRm से सफाई फ़ंक्शन को बदल दिया, जो इस मामले में कभी काम नहीं करता है क्योंकि इसे कंटेनर को पंजीकृत करने की आवश्यकता है , docker.cleanupContainer ।

हालाँकि, docker.cleanupContainer पहले विफल हो सकता है क्योंकि यह सफाई का प्रबंधन करता है। यह लाइन 113 पर nameIndex से प्रविष्टियों को हटाता है, लेकिन बहुत सारी चीजें हैं जो इससे पहले गलत हो सकती हैं।

उपरोक्त सभी उस मामले की व्याख्या करते हैं जहां एक साधारण डेमॉन पुनरारंभ समस्या को ठीक करता है क्योंकि nameIndex डिस्क पर बरकरार नहीं है। मैंने कोशिश की है कि कैसे इस बग को फिर से जीवित किया जा सके, लेकिन मैं यह नहीं देख सकता कि कोड के खिलाफ मेरे सिर पर चोट लगी है। हमने निश्चित रूप से इसे उत्पादन में देखा है, हालांकि वर्तमान में मैं इसके फिर से होने और आगे की जांच करने की कोशिश कर रहा हूं।

मैंने # 27956 में इन-मेमोरी संस्करण को निश्चित किया

यह मुद्दा नवीनतम (1.12.3) को अपडेट करने से पहले मेरे लिए बस पॉप अप हुआ, मैंने डॉकटर को पुनः इंस्टॉल किया और पुनः इंस्टॉल किया, और दुर्भाग्य से अभी भी इसे देख रहा हूं।

docker version का आउटपुट:

Client:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:        Wed Oct 26 23:26:11 2016
 OS/Arch:      windows/amd64

Server:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:        Wed Oct 26 23:26:11 2016
 OS/Arch:      linux/amd64

docker info का आउटपुट

Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 1
Server Version: 1.12.3
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 11
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: null host bridge overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.4.27-moby
Operating System: Alpine Linux v3.4
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.919 GiB
Name: moby
ID: XZHZ:262M:ENKG:Z62J:U4OX:FVKN:CGZW:7OCZ:IU5R:D7OM:F3MT:K3ND
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 12
 Goroutines: 22
 System Time: 2016-11-09T01:01:32.4577814Z
 EventsListeners: 0
Registry: https://index.docker.io/v1/
WARNING: No kernel memory limit support
Insecure Registries:
 127.0.0.0/8

मेरा वर्कफ़्लो इस थ्रेड में वर्णित की तुलना में थोड़ा अलग है, लेकिन यह समान है कि मैं अपने परीक्षण सूट में कंटेनरों के बहुत सारे सेटअप और फाड़ कर रहा हूं। यह रुचि का भी हो सकता है कि रिमोट एपीआई के अनुरोधों के माध्यम से ऐसा किया जा रहा है।

मैं आगे बढ़ने के लिए एक नुकसान पर थोड़ा सा हूं। यदि अनुरोध किया गया है, तो मैं निश्चित रूप से अपने मुद्दे का एक परीक्षण मामला तैयार कर सकता हूं, लेकिन अब यह काम पर एक बड़ी परियोजना का हिस्सा है, इसलिए मुझे चीजों को काटने की आवश्यकता होगी।

क्या आपके पास कोई सुझाव है?

@davidglivar आपने डेमॉन को फिर से शुरू किया और अभी भी त्रुटि देख रहे हैं?

@ cpuguy83 यदि डेमॉन को पुनरारंभ करके, आप विंडोज़ ऐप के लिए

@davidglivar तो आप इसे देख रहे हैं:

1. कार्य करना
2. त्रुटि प्राप्त करें
3. पुनः आरंभ docker4win
4. त्रुटि प्राप्त करें

?

@ cpuguy83 हां! मैं बस उस अनुक्रम के माध्यम से एक दो बार सुनिश्चित हो गया।

@davidglivar क्या आप docker ps -a कमा सकते हैं और देखें कि क्या आप वहां कंटेनर देखते हैं?

@ cpuguy83 docker ps -a पैदावार कोई कंटेनर नहीं है। मैं इसे अपने परीक्षण के टूटने और प्रस्तुत करने के कारण कहूंगा, लेकिन यहां तक ​​कि मेरे परीक्षणों में त्रुटि को पकड़ने पर, और तुरंत docker ps -a की एक बाल प्रक्रिया बनाने का परिणाम समान है।

बस पिछले दिन की टिप्पणियों का पालन करने के लिए: मुझे अभी भी अपने आवेदन के संदर्भ में 409 त्रुटि का सामना करना पड़ा; हालाँकि, एक परीक्षण स्क्रिप्ट ( यहाँ ) अभी तक किसी भी समस्या को प्रदर्शित करने के लिए है।

मैंने इसे पुन: पेश करने का एक विश्वसनीय तरीका बनाया। आप किसी भी कंटेनर का नाम संघर्ष करने के लिए निम्नलिखित अजगर स्क्रिप्ट का उपयोग कर सकते हैं:

# pip install docker-py
from docker import Client

NAME = 'foobar'

cli = Client(version='auto')

# Create an invalid security option that will cause an error in
# https://github.com/docker/docker/blob/v1.10.3/daemon/create.go#L82
host_config = cli.create_host_config(security_opt=['invalid_opt'])

# After this, NAME will always conflict until the daemon gets restarted
try:
    cli.create_container(name=NAME, host_config=host_config, image='', command='/')
except:
    pass

इस समस्या को निम्न स्थितियों में से एक में भी ट्रिगर किया जा सकता है जो कुछ ऐसे मामलों की व्याख्या करती है जहां /var/lib/docker की आवश्यकता होती है:

• /var/lib/docker इनोड से बाहर है
• /var/lib/docker अंतरिक्ष से बाहर है
• /var/lib/docker/<storage-driver> केवल-पढ़ने के लिए है

फ़िक्स को docker> = 1.12.0 पर अपडेट करना है

इस मुद्दे पर देर से आने के लिए क्षमा करें।

अब तक, वर्कअराउंड को हटाने के बाद से, हमारे CI सर्वर को इस समस्या से कोई परेशानी नहीं हुई है।

Client:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   23cf638
 Built:
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   23cf638
 Built:
 OS/Arch:      linux/amd64

इसके साथ यह अनुभव करना:

CentOS 7.2
Docker 1.12.1

/var/lib/docker/containers तहत निर्दिष्ट हैश के साथ कोई फ़ोल्डर नहीं है, और डेमॉन को पुनरारंभ करने का कोई प्रभाव नहीं था।

@orodbhen यदि डेमॉन को फिर से शुरू करने से काम नहीं चला, तो उस नाम के साथ एक कंटेनर लोड होना चाहिए।
क्या आप docker ps -a जाँच कर सकते हैं?

@ cpuguy83 नहीं, उस नाम के साथ कोई कंटेनर नहीं है।

मुझे वास्तव में लगता है कि यह docker-py साथ एक मुद्दा हो सकता है। मुझे आश्चर्य है कि यहां कितने लोग इसका उपयोग कर रहे हैं। ऐसा प्रतीत होता है कि @petrosagg है।

ऐसा तब होता है जब create_container() का उपयोग किया जाता है, भले ही अपमानजनक कंटेनर नाम का उपयोग न किया गया हो। लेकिन डॉक शेल कमांड के साथ मेरे पास कोई मुद्दा नहीं है, docker create या docker run ।

हालांकि, अजीब है, क्योंकि यह डेमन द्वारा उत्पादित त्रुटि संदेश को मुद्रित करता है।

@petrosagg आपको docker शेल कमांड का उपयोग करने में समान समस्या है?

@orodbhen क्या आप सुनिश्चित हैं कि आपका

केवल एक डेमॉन चल रहा है: दोनों /var/run/docker.sock का उपयोग कर रहे हैं।

मैंने docker-py के लिए एक मुद्दा बनाया है। लेकिन मैं अभी तक आश्वस्त नहीं हूं कि समस्या पैदा करने वाले डॉक के साथ कुछ अंतर्निहित मुद्दा नहीं है।

@orodbhen जब आप डेमॉन को पुनरारंभ करते हैं, तो क्या आप लोडिंग अनुक्रम (विशेष रूप से लोडिंग कंटेनर) से लॉग को पकड़ सकते हैं?

यदि आपने डेमॉन को फिर से शुरू किया है तो यह रेफ-काउंटिंग मुद्दा नहीं हो सकता है। रजिस्ट्रार नाम केवल स्मृति में रखा गया है और डेमॉन पुनरारंभ पर फिर से बनाया गया है।

क्षमा करें, कृपया अवहेलना करें। यह उस तरह से एक समस्या थी जिस तरह से मैं त्रुटियों को लॉग इन कर रहा था जिससे ऐसा लगता था कि त्रुटि फिर से आ रही थी।

@orodbhen मैं टेस्टकेस बनाने के लिए किया है। कारण यह नहीं होता है कि docker CLI के साथ ऐसा नहीं होता है क्योंकि क्लाइंट इनपुट को सर्वर से पास करने से पहले उसे मंजूरी दे देता है, लेकिन मैं चाहता था कि सर्वर तक सीधी पहुंच हो और क्रिटिकल सेक्शन फेल हो जाए।

पृष्ठभूमि में चल रही सेवा को हटाएं।
docker सेवा rm service_name
फिर ckeck docker की जानकारी यह c ontainers दिखाता है

# 3277 पर हटा दिया गया

मैं भी निम्नलिखित त्रुटियों के साथ एक ही समस्या का सामना कर रहा था:

   x Start Mongo: FAILED

-----------------------------------STDERR-----------------------------------
Error response from daemon: Cannot update container 78dc6f6a43d0e6cfb7aa6bba2f0a377bd39620bff79ca308540a13ddd4e62886: container is marked for removal and cannot be "update"
Error response from daemon: removal of container mongodb is already in progress
docker: Error response from daemon: Conflict. The container name "/mongodb" is already in use by container "78dc6f6a43d0e6cfb7aa6bba2f0a377bd39620bff79ca308540a13ddd4e62886". You have to remove (or rename) that container to be able to reuse that name.
See 'docker run --help'.
-----------------------------------STDOUT-----------------------------------
3.4.1: Pulling from library/mongo
Digest: sha256:aff0c497cff4f116583b99b21775a8844a17bcf5c69f7f3f6028013bf0d6c00c
Status: Image is up to date for mongo:3.4.1
no such container
Running mongo:3.4.1

मैंने सिर्फ कमांड चलाया: sudo service docker पुनरारंभ

और अब सब कुछ ठीक चल रहा है।

मैं भी निम्नलिखित त्रुटियों के साथ इस मुद्दे का सामना कर रहा था:

docker-compose up -d --no-build api
Creating api ... 
Creating api ... error

ERROR: for api  Cannot create container for service api: Conflict. The name "/api" is already in use by container 2788cdc091645f0dcef417f189f9c80fddd3f6f99eaba3771d0f4a87e2295841. You have to remove (or rename) that container to be able to reuse that name.

ERROR: for api  Cannot create container for service api: Conflict. The name "/api" is already in use by container 2788cdc091645f0dcef417f189f9c80fddd3f6f99eaba3771d0f4a87e2295841. You have to remove (or rename) that container to be able to reuse that name.
ERROR: Encountered errors while bringing up the project.

यह उस निर्देशिका का पता लगाता है जहां कंपोज़ फ़ाइल स्थित है, उस समय का नाम बदला गया जब मौजूदा कंटेनर चलाया गया था और जब मैंने कंटेनर को फिर से चलाने का प्रयास किया था। मैंने निम्नलिखित चलाकर जाँच की:

docker inspect api | grep -i compose
"com.docker.compose.config-hash": "c0e3e88ad502faf806288e16419dc52b113cae18abeac1769fa0e98a741de48a",
"com.docker.compose.container-number": "1",
"com.docker.compose.oneoff": "False",
"com.docker.compose.project": "api",
"com.docker.compose.service": "api",
"com.docker.compose.version": "1.14.0"

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

हमारे पास बहुत से कंटेनर हैं, जिन्हें फिर से शुरू करना एक इष्टतम समाधान नहीं था।

रुके हुए कंटेनरों को हटाने के लिए docker container prune ।

मुझे कंटेनर को docker rm -f /<container_name> निकालने के लिए मजबूर करना पड़ा