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)

затем перезапустите докер

$ sudo service docker restart

а затем воссоздание роя исправляет это.

Вот протокол типичного сбоя. Я использую ansible для запуска команд docker compose на одном из узлов роя против роя.

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», но его нигде нет.

Там такая же проблема.

Я часто повторяю цикл:

• докер остановка% name%
• docker rm -f% имя%
• докер тянуть% name%
• docker run% name%

В какой-то момент (2-3 дня) перестает работать:
докер: ответ об ошибке от демона: конфликт. Имя «% name%» уже используется контейнером% container_id% . Вы должны удалить (или переименовать) этот контейнер, чтобы иметь возможность повторно использовать это имя.

Когда я пытаюсь удалить контейнер% container_id% вручную, он говорит:
Не удалось удалить контейнер (% container_id%): ответ от демона об ошибке: такого контейнера нет:% container_id%

Контейнера% container_id% нет в списке docker ps -a и нет в папке / var / lib / docker / container

Может быть, корень проблемы в удалении контейнера с параметром -f? поэтому докер не очищается правильно, и демон докера думает, что контейнер все еще там.

Вывод версии Docker:

Клиент:
Версия: 1.10.3
Версия API: 1.22
Версия Go: go1.5.3
Git commit: 8acee1b
Построен:
ОС / Arch: Linux / amd64

Сервер:
Версия: 1.10.3
Версия API: 1.22
Версия Go: go1.5.3
Git commit: 8acee1b
Построен:
ОС / Arch: Linux / amd64

Вывод информации Docker:

Контейнеров: 27
Бег: 13
Приостановлено: 0
Остановлены: 14
Изображения: 1512
Версия сервера: 1.10.3
Драйвер хранилища: devicemapper
Имя пула: docker-8: 9-521647-pool
Размер блока пула: 65,54 kB
Размер базового устройства: 107,4 ГБ
Резервная файловая система: xfs
Файл данных: / dev / loop2
Файл метаданных: / dev / loop3
Используемое пространство для данных: 53,62 ГБ
Всего дискового пространства: 107,4 ГБ
Доступное пространство для данных: 53,76 ГБ
Используемое пространство метаданных: 129,9 МБ
Всего метаданных: 2,147 ГБ
Доступное пространство для метаданных: 2,018 ГБ
Поддерживается синхронизация 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 (30.01.2015)
Драйвер исполнения: native-0.2
Драйвер логирования: json-файл
Плагины:
Объем: местный
Сеть: хост-мост null
Версия ядра: 4.5.0-coreos-r1
Операционная система: CoreOS 1010.5.0 (MoreOS)
OSType: linux
Архитектура: x86_64
Процессоры: 8
Общий объем памяти: 11,74 Гбайт
Имя: xx-slave
ID: LVGE: QBNA : DXFP: AWR7 : NAVO: LQLR : 7 CGF: UDOF : CTES: VZQJ : SRZJ: JLKW

Docker использует nameIndex для сохранения ссылки на контейнеры. Судя по описанию, проблема в том, что nameIndex не синхронизируется с удаленными контейнерами. Вот где возвращается ошибка.

Возможно, мы сможем удалить рассинхронизированный nameIndex, чтобы временно решить эту проблему. Хотя docker использует несколько индексов (например, linkIndex) в дополнение к nameIndex поэтому может быть несколько мест, которые нужно очистить. В конечном итоге лучшим решением может стать определение того, где происходит рассинхронизация.

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

Для меня работает то, что нужно остановить демон докера, удалить все из /var/lib/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 и 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. В остальных случаях нам нужно 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 -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 / network / files / local-kv.db?

Мало того, также были удалены все запущенные контейнеры 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 обновляется намного позже в строке 149 на daemon.Register() .

Если что-то не получается между этими двумя, докер находится в несовместимом состоянии. Перед фиксацией https://github.com/docker/docker/commit/114be249f022535f0800bd45987c4e9cd1b321a4 (приземлился в 1.12.0), этого было все, что было необходимо для возникновения проблемы. Эта фиксация изменила функцию очистки с docker.ContainerRm , которая никогда не работает в этом случае, потому что для этого требуется регистрация контейнера , на docker.cleanupContainer .

Однако docker.cleanupContainer может выйти из строя до того, как ему удастся очистить. Он удаляет только записи из nameIndex в строке 113, но есть много вещей, которые могут пойти не так до этого.

Все вышеперечисленное объясняет случай, когда простой перезапуск демона устраняет проблему, поскольку 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

Мой рабочий процесс немного отличается от того, что было упомянуто в этом потоке, но он похож в том, что я выполняю множество настроек и разборок контейнеров в моем наборе для тестирования. Также может быть интересно, что это делается через запросы к удаленному API.

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

Есть ли у вас какие-нибудь предложения?

@davidglivar Вы перезапустили демон, но ошибка не

@ cpuguy83, если перезапуск демона означает остановку / запуск докера для приложения Windows, да. Я также переустановил докер и сделал «заводской» сброс. Я не касался Hyper-V, так как не уверен в его внутренней работе.

@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 закончились inodes
• /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 вместо docker-py?

@orodbhen Вы уверены, что ваш экземпляр docker-py

Работает только один демон: оба используют /var/run/docker.sock .

Я создал проблему для docker-py. Но я еще не уверен, что нет какой-то основной проблемы с докером, вызывающей проблему.

@orodbhen Можете ли вы получить журналы из последовательности загрузки (особенно загрузки контейнеров) после перезапуска демона?

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

Извините, не обращайте внимания. Это была проблема с тем, как я регистрировал ошибки, из-за которых казалось, что ошибка повторяется.

@orodbhen Я не использую docker-py, я использовал его только для создания небольшого воспроизводимого тестового примера. Причина, по которой этого не происходит с интерфейсом командной строки докера, заключается в том, что клиент очищает ввод перед передачей его на сервер, но я хотел иметь прямой доступ к серверу и вызвать сбой критического раздела.

удалить службу, работающую в фоновом режиме.
docker service rm имя_службы
затем ckeck информация о докере, которая показывает c ontainers: 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 container prune для удаления остановленных контейнеров.

Мне пришлось принудительно удалить контейнер docker rm -f /<container_name>