Moby: 「/ data-container-name」という名前はすでにコンテナで使用されています<hash>。 その名前を再利用できるようにするには、そのコンテナを削除（または名前変更）する必要があります。</hash>

それらの容器をどのように掃除しましたか？ これらのリソース（ボリュームネットワークなどを含む）をクリーンアップする理由で例外が発生しますか？

私はすべてを無力化するヘルパー機能を持っているので、私たちの継続的な何とか、サイクルをテストすることができます、えーと...継続的に。 基本的に、それは次のように要約されます。

コンテナをクリアするには：

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)

その後、dockerを再起動します

$ sudo service docker restart

群れを再作成すると修正されます。

これが典型的な失敗のログです。 私はansibleを使用して、群れに対して群れノードの1つでdockercomposeコマンドを実行します。

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

「bookingeng811_redis1_1」というコンテナを手動で削除しようとしましたが、どこにも存在しません。

そこにも同じ問題があります。

私は頻繁にサイクルを繰り返します：

• docker stop％name％
• docker rm -f％name％
• docker pull％name％
• docker run％name％

ある時点（2〜3日）で動作を停止します。
docker：デーモンからのエラー応答：競合。 名前「％name％」は、コンテナ％container_id％によってすでに使用されています。 その名前を再利用できるようにするには、そのコンテナを削除（または名前変更）する必要があります。

コンテナ％container_id％を手動で削除しようとすると、次のように表示されます。
コンテナの削除に失敗しました（％container_id％）：デーモンからのエラー応答：そのようなコンテナはありません：％container_id％

コンテナー％container_id％がリストdocker ps -aになく、フォルダー/ var / lib / docker / containersにありません

おそらく問題の根本は-fパラメータでコンテナを削除することですか？ そのため、dockerは正しくクリーンアップせず、dockerデーモンはコンテナーがまだそこにあると見なします。

Dockerバージョンの出力：

クライアント：
バージョン：1.10.3
APIバージョン：1.22
Goバージョン：go1.5.3
Gitコミット：8acee1b
構築：
OS / Arch：linux / amd64

サーバ：
バージョン：1.10.3
APIバージョン：1.22
Goバージョン：go1.5.3
Gitコミット：8acee1b
構築：
OS / Arch：linux / amd64

Docker情報の出力：

コンテナ：27
実行中：13
一時停止：0
停止：14
画像：1512
サーバーバージョン：1.10.3
ストレージドライバー：devicemapper
プール名：docker-8：9-521647-プール
プールのブロックサイズ：65.54 kB
基本デバイスサイズ：107.4 GB
バッキングファイルシステム：xfs
データファイル：/ dev / loop2
メタデータファイル：/ dev / loop3
使用されるデータスペース：53.62 GB
データスペースの合計：107.4 GB
使用可能なデータスペース：53.76 GB
使用されるメタデータスペース：129.9 MB
メタデータスペースの合計：2.147 GB
利用可能なメタデータスペース：2.018 GB
サポートされているUdev同期：true
遅延削除が有効：false
延期された削除が有効：false
延期された削除済みデバイス数：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 / metadata
ライブラリバージョン：1.02.93（2015-01-30）
実行ドライバー：ネイティブ-0.2
ロギングドライバー：json-file
プラグイン：
ボリューム：ローカル
ネットワーク：ホストブリッジnull
カーネルバージョン：4.5.0-coreos-r1
オペレーティングシステム：CoreOS 1010.5.0（MoreOS）
OSType：linux
アーキテクチャ：x86_64
CPU：8
総メモリ：11.74 GiB
名前：xx-スレーブ
ID： LVGE：QBNA ： DXFP：AWR7 ：NAVO ： CGF：UDOF ： CTES：VZQJ ： SRZJ：JLKW

Dockerは「nameIndex」を使用してコンテナーへの参照を保存します。 説明から、問題はnameIndexが削除されたコンテナと同期していないことが原因であると思われます。 ここでエラーが返されます。

同期していないnameIndexをクリーンアップして、問題に一時的に対処できる場合があります。 dockerはnameIndexに加えていくつかのインデックス（たとえば、linkIndex）を使用するため、クリーンアップが必要な場所がいくつかある可能性があります。 非同期が発生する場所を見つけることは、長期的にはより良い解決策になる可能性があります。

同期していないnameIndexesをクリーンアップする方法はありますか？
今のところ私が持っている唯一の解決策は、良くないノードを再起動することです。 Dockerデーモンの再起動も良くありません。

私にとってうまくいくのは、dockerデーモンを停止し、 /var/lib/docker/*からすべてを削除して、dockerを再起動することです。 これは継続的インテグレーションサーバーであるため、Dockerコンテキストにイメージがロードされていないことを処理できるので、YMMVで機能します。

1.10.3でも同じ動作が見られます

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とDocker1.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デーモンを再起動すると問題が修正されます。 それ以外の場合は、rm -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下にコンテナハッシュのあるフォルダがあり、削除しましたが、それでも運がありません。 dockerデーモンを再起動しました。動作しました。

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も削除するためです。

docker 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では発生する可能性がはるかに低くなります。

コードでこの問題を追跡しましたが、 nameIndex構造が導入されたすべてのバージョン> = 1.10.0で間違いなく発生する可能性があります。 @yongtangが述べたように、この構造は削除されたコンテナと同期しなくなります。

このエラーは、 nameIndexがdaemon.containersと同期しなくなるたびに発生します。

問題はDaemon.create（）関数にあります。 nameIndexは64行目でdaemon.newContainer()によって更新されますが、 daemon.containersは149行目でdaemon.Register()によって更新されます。

これら2つの間で何かが失敗した場合、dockerは一貫性のない状態になります。 https://github.com/docker/docker/commit/114be249f022535f0800bd45987c4e9cd1b321a4（1.12.0に到達）をコミットする前に、問題をトリガーするために必要なのはそれだけでした。 このコミットにより、クリーンアップ関数がdocker.ContainerRmからdocker.cleanupContainer 。これは、コンテナーを登録する

ただし、 docker.cleanupContainerは、クリーンアップに成功する前に失敗する可能性があります。 113行目のnameIndexからエントリを削除するだけですが、それ以前に問題が発生する可能性のあるものはたくさんあります。

上記のすべては、 nameIndexがディスクに永続化されていないため、単純なデーモンの再起動で問題が修正される場合を説明しています。 このバグが再起動を乗り切る方法を理解するためにコードに頭をぶつけましたが、その方法がわかりません。 私たちは間違いなく本番環境でそれを見てきましたので、現在私はそれが再び起こるのを待って、さらに調査しようとしています。

＃27956で問題のメモリ内バージョンを修正しました

この問題は、最新（1.12.3）に更新する前に発生したばかりで、dockerをアンインストールして再インストールしましたが、残念ながらまだ発生しています。

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

私のワークフローは、このスレッドで言及されているものとは少し異なりますが、テストスイートでコンテナーのセットアップと破棄をたくさん行っているという点で似ています。 これがリモートAPIへのリクエストを通じて行われていることも興味深いかもしれません。

どうすればいいのか少し戸惑います。 要求があれば、私は確かに私の問題のテストケースを準備することができますが、現在、それは作業中のより大きなプロジェクトの一部であるため、物事を削減する必要があります。

何か提案はありますか？

@davidglivarデーモンを再起動しても、まだエラーが表示されていますか？

@ cpuguy83デーモンを再起動することで、Windowsアプリの

@davidglivarだからあなたはこれを見ています：

1. 何かをする
2. エラーが発生する
3. docker4winを再起動します
4. エラーが発生する

？

@ cpuguy83うん！ 確かに、私はそのシーケンスを数回実行しました。

@davidglivar docker ps -a 、そこにコンテナが表示されるかどうかを確認できますか？

@ cpuguy83 docker ps -aはコンテナを生成しません。 テストの分解と準備が原因だと思いますが、テストでエラーをキャッチし、すぐにdocker ps -aの子プロセスを作成しても、結果は同じです。

前日のコメントをフォローアップするためだけに、アプリケーションのコンテキストで409エラーが発生しました。 ただし、テストスクリプト（ここ）にはまだ問題が表示されていません。

これを再現する信頼できる方法を作成しました。 次のPythonスクリプトを使用して、コンテナ名を競合させることができます。

# 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はiノードが不足しています
• /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を使用して、dockershellコマンドに問題はありません。

ただし、デーモンによって生成されたエラーメッセージを出力しているように見えるため、奇妙です。

@petrosagg docker -pyの代わりにdockershellコマンドを使用しても同じ問題が発生しますか？

@orodbhen docker -pyインスタンスがCLIと同じデーモンと

実行されているデーモンは1つだけです。どちらも/var/run/docker.sockます。

docker-pyの問題を作成しました。 しかし、問題を引き起こしているdockerに根本的な問題がないことを私はまだ確信していません。

@orodbhenデーモンを再起動するときに、ロードシーケンス（特にコンテナーのロード）からログを取得できますか？

デーモンを再起動した場合、これは参照カウントの問題にません。 名前レジストラはメモリにのみ保持され、デーモンの再起動時に再構築されます。

申し訳ありませんが、無視してください。 エラーをログに記録する方法に問題があり、エラーが再発しているように見えました。

@orodbhen docker -pyは使用していません。これは、再現可能な小さなテストケースを作成するためにのみ使用しました。 Docker CLIで発生しない理由は、クライアントが入力をサーバーに渡す前にサニタイズするためですが、サーバーに直接アクセスしてクリティカルセクションを失敗させたいと思っていました。

バックグラウンドで実行されているサービスを削除します。
docker service rm service_name
次に、コンテナを表示するDocker情報を確認します：0

削除され、＃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 restart

そして今、すべてがうまく機能しています。

また、次のエラーでこの問題に直面していました。

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を再起動したりせずに）、すべてが期待どおりに機能しています。

多くのコンテナが実行されているため、dockerの再起動は最適なソリューションではありませんでした。

docker container prune 、停止したコンテナを削除します。

コンテナを強制的に削除する必要がありましたdocker rm -f /<container_name>