Compose: UnixHTTPConnectionPool (host = 'localhost', port = None): истекло время чтения. (время ожидания чтения = 60)

попробовал это

export DOCKER_CLIENT_TIMEOUT=120
export COMPOSE_HTTP_TIMEOUT=120

и, похоже, на данный момент проблема решена

Другие решения, упомянутые в этой теме:

• Перезапустить докер
• Увеличение ЦП и памяти Docker

Бывает, если выключить WiFi? Может быть связано с https://github.com/docker/docker-py/issues/1076.

Другая теория, если в вашем сервисе включен tty: True , может быть # 3106

Я вижу точно такую ​​же проблему с последней бета-версией для Mac. Та же ошибка, если я запустил docker-compose create

Может ли это быть связано с наличием одного очень большого слоя на изображении? (очень длительная операция npm install которая занимает около минуты, чтобы объединить ее в слой, когда докер создает изображение)

Мы также наблюдаем эту проблему при использовании файла создания докеров с 6 контейнерами [docker-compose версия 1.8.1, сборка 878cff1] как в Windows, так и в Mac [версия 1.12.2-rc1-beta27 (сборка: 12496)
179c18cae7]

Увеличение ресурсов, доступных докеру, похоже, снижает вероятность того, что это произойдет (как и увеличение тайм-аута), но это никогда не устраняется.

У нас также есть несколько больших уровней (240 МБ - самый большой, основная команда установки пакета), и мы привязываемся к каталогу хоста с 120 МБ файлов в нескольких контейнерах.

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

Сначала мой сценарий выглядел примерно так:

app:
  build: .
  volumes:
    - ${PWD}:/usr/src
    - /usr/src/node_modules

Мой смонтированный путь включал множество каталогов с большими статическими файлами, которые мне действительно не нужно было монтировать с точки зрения перезагрузки кода. В итоге я поменял местами что-то вроде этого:

app:
  build: .
  volumes:
    - ${PWD}:/usr/src
    - /usr/src/static  # large files in a long dir structure
    - /usr/src/node_modules

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

Из этого я понимаю, что чем больше файлов вы монтируете, особенно чем они больше (изображения в МБ, а не в исходных файлах в Bs / KB), время загрузки сильно увеличивается.

Надеюсь это поможет

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

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

Случай с nginx conatiner, Up 47 hours .
Докер для Mac Version 17.03.1-ce-mac12 (17661) Channel: stable d1db12684b .

version: '2.1'
services:
  nginx:
    hostname: web
    extends:
      file: docker/docker-compose.yml
      service: nginx
    ports:
      - 80:80
      - 443:443
    volumes:
      - ./src:/var/www:ro

  php:
    build:
      dockerfile: "./docker/web/php/Dockerfile"
      context: "."
    volumes:
      - ./src:/var/www

$ docker-compose kill nginx
Killing project_nginx_1 ... 

ERROR: for project_nginx_1  UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)
ERROR: An HTTP request took too long to complete. Retry with --verbose to obtain debug information.
If you encounter this issue regularly because of slow network conditions, consider setting COMPOSE_HTTP_TIMEOUT to a higher value (current value: 60).

Спасибо @gvilarino , я считаю, что установка больших файлов является причиной этой проблемы на моем сервере Linux. Ваш фрагмент может быть обходным решением, если большие файлы не нужны в контейнере.

Однако мне интересно, почему в Docker происходит медленное монтирование? Может срабатывает копирование диска? Но почему?

@cherrot Я бы не сказал, что я очень разбираюсь в этой теме, но я считаю, что это связано с драйвером хранилища, используемым Docker, и тем, как он работает внутри для поддержания порядка слоев. Используйте docker info чтобы узнать, какой драйвер хранилища использует ваш демон (вероятно, aufs , который является самым медленным), и в зависимости от ОС вашего хоста вы можете изменить его так, чтобы что-то другое ( overlay - лучший выбор, если поддерживается). Существуют более быстрые альтернативы, такие как LCFS, но они не поддерживаются Docker на коммерческой основе, поэтому вам придется действовать самостоятельно.

Мы тоже наблюдаем этот тайм-аут. Похоже, также из-за используемых нами объемов.

Нам нужны контейнеры для доступа к некоторым сетевым ресурсам SMB. Поэтому мы смонтировали эти общие ресурсы в хост-системе и смонтировали их внутри контейнера. Но иногда связь между Windows Server и нашим хостом Linux останавливается (см. Https://access.redhat.com/solutions/1360683), и это блокирует запуск или остановку нашего контейнера, который через некоторое время просто истекает.

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

FWIW: Для людей, попавших сюда через поисковую систему, которые нашли свое решение, я смог исправить это просто с помощью метода _did you try to the it off and on again? _ Method; Я перезапустил свой клиент Docker для Mac OS.

+1 на этом я запускаю стресс-тестирование на своем экземпляре, который запускает 4 контейнера, и докер зависает даже для docker ps -a поэтому я пытаюсь перезапустить контейнеры, но получаю
UnixHTTPConnectionPool(host='localhost', port=None): Read timed out и

Traceback (most recent call last):
  File "/usr/bin/docker-compose", line 9, in <module>
    load_entry_point('docker-compose==1.8.0', 'console_scripts', 'docker-compose')()
  File "/usr/lib/python2.7/dist-packages/compose/cli/main.py", line 61, in main
    command()
  File "/usr/lib/python2.7/dist-packages/compose/cli/main.py", line 113, in perform_command
    handler(command, command_options)
  File "/usr/lib/python2.7/contextlib.py", line 35, in __exit__
    self.gen.throw(type, value, traceback)
  File "/usr/lib/python2.7/dist-packages/compose/cli/errors.py", line 56, in handle_connection_errors
    log_timeout_error()
TypeError: log_timeout_error() takes exactly 1 argument (0 given)

Только если я перезапускаю службу docker похоже, она решена, есть идеи?

+1

`Перезапуск web-jenkins_jenkins_1 ...

ОШИБКА: для web-jenkins_jenkins_1 UnixHTTPConnectionPool (host = 'localhost', port = None): время чтения истекло. (время ожидания чтения = 130)
ОШИБКА: запрос HTTP занял слишком много времени для выполнения. Повторите попытку с --verbose, чтобы получить отладочную информацию.
Если вы регулярно сталкиваетесь с этой проблемой из-за медленной работы сети, рассмотрите возможность установки COMPOSE_HTTP_TIMEOUT на более высокое значение (текущее значение: 120).

Я перезапускаю докер, это решено. но каждый день мне нужно перезапускать

перезапуск Docker работает для меня.

+1 перезапуск докера у меня тоже сработал.

Я столкнулся с этой проблемой при создании достаточно большого образа Docker, а затем при попытке отправить его в удаленный реестр. Перезапуск Docker не был подходящим решением, но ответ @bodaz адресовал его мне: https://github.com/docker/compose/issues/3927#issuecomment -245948736

@ rodrigo-brito - я уже некоторое время получаю эту ошибку, и перезапуск docker deamon решил проблему - не более того, поскольку я добавил еще одну службу в свой проект.

У меня такая же проблема, но у меня довольно простая настройка.
У меня только один контейнер verdaccio 3 на основе образа размером 164 МБ.
Это очень обидно: /

Я использую MBP Pro 13 2015 года выпуска.

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

Простой sudo service docker restart последовательно решает эту проблему каждый раз, когда это происходит.

Это случилось и со мной, в моем случае docker-compose push (даже не пытаясь запустить приложение) в Azure DevOps.

Другие мои сборки не используют docker-compose, а просто docker push

Я удалил версию docker для kubuntu 18.04.1 docker.io и установил docker-ce 18.09.0
Проблема ушла.

Вместо этого я просто преобразовал шаг docker-compose push в отдельные нажатия.

Мы наблюдаем этот тайм-аут при запуске контейнера через docker-compose или через библиотеку docker-py (время ожидания истекает даже после того, как мы увеличиваем время ожидания до 2 минут); однако мы не видим ошибки при запуске через Docker CLI (контейнер запускается мгновенно). Мы также видим проблему только на сервере CI Linux, но не на наших компьютерах Mac. Мы работаем над созданием минимально воспроизводимого примера.

Имея эту проблему с docker-compose kill на виртуальной машине debian на узле macos, установите прямо из докера. (Докер версии 18.09.0, сборка 4d60db4)

У меня была такая же ошибка при запуске докера с драйвером журнала: syslog, когда порт rsyslog был недоступен.
Error starting container 0ba2fb9540ec6680001f90dce56ae3a04b831c8146357efaab79d4756253ec8b: UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)

перезапуск Docker работает для меня.

@ rodrigo-brito перезапуск - не решение ...

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

То же самое и для меня. После ошибки демон докера продолжает кушать память до истощения. Мне нужно systemctl stop docker прежде чем моя система умрет. (Докер версии 18.09.3, сборка 774a1f4)

    ports:
      - "10000-20000:10000-20000"

простой перезапуск докера решил это для меня ...

Кажется, проблема все еще присутствует в последних версиях docker-ce. Я запускаю ~ 5 контейнеров, при этом у медленного есть монтирование тома докера, указывающее на общий ресурс NFS. Никакие контейнеры не открывают порт, кто-нибудь выяснил, является ли это допустимой ошибкой ( port=None кажется подозрительным)?

~~~
Клиент:
Версия: 18.09.5
Версия API: 1.39
Версия Go: go1.10.8
Git commit: e8ff056dbc
Построен: Чт 11 апр, 04:44:28 2019
ОС / Arch: Linux / amd64
Экспериментальный: ложь

Сервер: Docker Engine - Сообщество
Двигатель:
Версия: 18.09.5
Версия API: 1.39 (минимальная версия 1.12)
Версия Go: go1.10.8
Git commit: e8ff056
Построен: 11 апр, 04:10:53 2019
ОС / Arch: Linux / amd64
Экспериментальный: ложь
~~~

Добавлен еще вывод из --verbose . Я не думаю, что здесь есть что-то полезное, просто давно сказано, что какая-то операция создания контейнера долго ждет. По-видимому, он использует опрос, так как следующее сообщение печатается примерно 1 раз в секунду:

~compose.parallel.feed_queue: Ожидание: set ()~

Я думаю, что localhost / port = Node - отвлекающий маневр, поскольку соединение выполняется с помощью docker.sock, так что это не какая-то спрятанная где-то ошибка nil. Я думаю, что это нужно будет отследить внутри докера, не то, чтобы обработка этого запроса в докере здесь была оптимальной.

Docker-compose, похоже, не хватает какого-то идентификатора запроса, который можно было бы зарегистрировать, чтобы мы знали, какой запрос задерживается. Например, я знаю, что мой контейнер api не удалось создать в течение тайм-аута, но журнал запросов совершенно не помогает. Может быть, кто-нибудь еще может добавить сюда некоторую информацию:

~~~
urllib3.connectionpool._make_request: http: // localhost: None "POST /v1.25/containers/create?name=api-memcache HTTP / 1.1" 201 90
urllib3.connectionpool._make_request: http: // localhost: None "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: docker create_container -> {'Id': '22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f',
"Предупреждения": нет}
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network -> None
compose.cli.verbose_proxy.proxy_callable: docker inspect_container <- ('22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f')
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network <- ('ba67095c5ea718af13a09798bc2f5ab24f5d0b54ce684b6f4cb248ab705df900', 'proxy', ipadone ', aliases_done_done_done_docs = [' redis_done], aliases_s_docs = ['redis_done], aliases_display_doc »= [' redis_done]»
urllib3.connectionpool._make_request: http: // localhost: None "GET /v1.25/containers/22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f/json HTTP / 1.1" 200 Нет
urllib3.connectionpool._make_request: http: // localhost: None "POST /v1.25/containers/create?name=api HTTP / 1.1" 201 90
compose.cli.verbose_proxy.proxy_callable: docker create_container -> {'Id': '1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec',
"Предупреждения": нет}
compose.cli.verbose_proxy.proxy_callable: docker inspect_container <- ('1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec')
compose.parallel.feed_queue: Ожидание: set ()
urllib3.connectionpool._make_request: http: // localhost: None "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
urllib3.connectionpool._make_request: http: // localhost: None "POST /v1.25/networks/proxy/connect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: docker inspect_container -> JSON ...
urllib3.connectionpool._make_request: http: // localhost: None "GET /v1.25/containers/1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec/json HTTP / 1.1" 200 Нет
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network -> None
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network -> Нет
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network <- ('22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f', 'proxy')
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network <- ('7d81ef23610f1b8f7ac95837cbf6c9eef977b5b0846fea24be5c7054e471df39', 'proxy', ipadaldone_done_done_done_done_done_done_done_done = 7, ',', 'proxy', aliases_done_dress6, ',', 'proxy', ', aliases_done,', ','
compose.cli.verbose_proxy.proxy_callable: docker inspect_container -> JSON ...
urllib3.connectionpool._make_request: http: // localhost : None "POST /v1.25/containers/create?name=api-comments-db HTTP / 1.1" 201 90
compose.cli.verbose_proxy.proxy_callable: docker start <- ('ba67095c5ea718af13a09798bc2f5ab24f5d0b54ce684b6f4cb248ab705df900')
compose.parallel.feed_queue: Ожидание: set ()
compose.parallel.feed_queue: Ожидание: set ()
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network <- ('1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec', 'proxy')
compose.cli.verbose_proxy.proxy_callable: docker create_container -> {'Id': 'ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af',
"Предупреждения": нет}
urllib3.connectionpool._make_request: http: // localhost : None "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
urllib3.connectionpool._make_request: http: // localhost : None "POST /v1.25/networks/proxy/connect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: docker inspect_container <- ('ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af')
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network -> None
compose.parallel.feed_queue: Ожидание: set ()
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network -> Нет
compose.cli.verbose_proxy.proxy_callable: Докер connect_container_to_network <- ( '22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f', 'прокси', псевдонимы = [ 'Memcache', '22b774d0451c'], ipv4_address = нет, ipv6_address = нет, ссылки = [], link_local_ips = нет)
compose.parallel.feed_queue: Ожидание: set ()
urllib3.connectionpool._make_request: http: // localhost : None "GET /v1.25/containers/ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af/json HTTP / 1.1" 200 None
urllib3.connectionpool._make_request: http: // localhost : None "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: docker start <- ('7d81ef23610f1b8f7ac95837cbf6c9eef977b5b0846fea24be5c7054e471df39')
compose.parallel.feed_queue: Ожидание: set ()
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network -> None
compose.cli.verbose_proxy.proxy_callable: docker inspect_container -> JSON ...
urllib3.connectionpool._make_request: http: // localhost : None "POST /v1.25/networks/proxy/connect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: Докер connect_container_to_network <- ( '1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec', 'прокси', псевдонимы = [ 'API', '1b67251d4941'], ipv4_address = нет, ipv6_address = нет, ссылки = [], link_local_ips = нет)
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network <- ('ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af', 'proxy')
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network -> Нет
compose.cli.verbose_proxy.proxy_callable: docker start <- ('22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f')
compose.parallel.feed_queue: Ожидание: set ()
urllib3.connectionpool._make_request: http: // localhost: None "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
urllib3.connectionpool._make_request: http: // localhost: None "POST /v1.25/networks/proxy/connect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network -> None
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network -> Нет
compose.cli.verbose_proxy.proxy_callable: докер connect_container_to_network <- ( 'ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af', 'прокси', псевдонимы = [ 'ff8c5cc4cb87', 'комментарии ДБ'], ipv4_address = None, ipv6_address = None, ссылки = [], link_local_ips = Никто)
compose.cli.verbose_proxy.proxy_callable: docker start <- ('1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec')
urllib3.connectionpool._make_request: http: // localhost: None "POST /v1.25/networks/proxy/connect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network -> Нет
compose.cli.verbose_proxy.proxy_callable: docker start <- ('ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af')
compose.parallel.feed_queue: Ожидание: set ()
compose.parallel.feed_queue: Ожидание: set ()
compose.parallel.feed_queue: Ожидание: set ()
compose.parallel.feed_queue: Ожидание: set ()
...
- пропущено ~ 30 строк
...
Создание api-комментариев ... готово
compose.cli.verbose_proxy.proxy_callable: запуск докера -> Нет
compose.parallel.parallel_execute_iter: Завершенная обработка: ServiceName (project = 'api', service = 'comments', number = 1)
compose.parallel.feed_queue: Ожидание: set ()
compose.parallel.parallel_execute_iter: Завершенная обработка:
compose.parallel.feed_queue: Ожидание: set ()
Создание api-memcache ... готово
urllib3.connectionpool._make_request: http: // localhost: None "POST /v1.25/containers/22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f/start HTTP / 1.1" 204 0
compose.cli.verbose_proxy.proxy_callable: запуск докера -> Нет
compose.parallel.parallel_execute_iter: Завершенная обработка: ServiceName (project = 'api', service = 'memcache', number = 1)
compose.parallel.feed_queue: Ожидание: set ()
compose.parallel.parallel_execute_iter: Завершенная обработка:
compose.parallel.feed_queue: Ожидание: set ()
compose.parallel.feed_queue: Ожидание: set ()
compose.parallel.feed_queue: Ожидание: set ()
compose.parallel.feed_queue: Ожидание: set ()
urllib3.connectionpool._make_request: http: // localhost: None "POST /v1.25/containers/ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af/start HTTP / 1.1" 204 0
compose.cli.verbose_proxy.proxy_callable: запуск докера -> Нет
Создание api-comments-db ... готово
compose.parallel.feed_queue: Ожидание: set ()
compose.parallel.parallel_execute_iter: Завершенная обработка:
compose.parallel.feed_queue: Ожидание: set ()
compose.parallel.feed_queue: Ожидание: set ()
compose.parallel.feed_queue: Ожидание: set ()
compose.parallel.feed_queue: Ожидание: set ()
compose.parallel.feed_queue: Ожидание: set ()
- пропущено ~ 15 строк
Создание api-redis ... готово
compose.parallel.feed_queue: Ожидание: set ()
urllib3.connectionpool._make_request: http: // localhost: None "POST /v1.25/containers/ba67095c5ea718af13a09798bc2f5ab24f5d0b54ce684b6f4cb248ab705df900/start HTTP / 1.1" 204 0
compose.cli.verbose_proxy.proxy_callable: запуск докера -> Нет
compose.parallel.parallel_execute_iter: Завершенная обработка: ServiceName (project = 'api', service = 'redis', number = 1)
compose.parallel.feed_queue: Ожидание: set ()
compose.parallel.parallel_execute_iter: Завершенная обработка:

compose.parallel.feed_queue: Ожидание: set ()

- пропущено 100+ строк
compose.parallel.parallel_execute_iter: Failed: ServiceName (project = 'api', service = 'api', number = 1)
compose.parallel.feed_queue: Ожидание: set ()

ОШИБКА: для API UnixHTTPConnectionPool (host = 'localhost', port = None): истекло время чтения. (время ожидания чтения = 60)
compose.parallel.parallel_execute_iter: Ошибка:
compose.parallel.feed_queue: Ожидание: set ()

ОШИБКА: для api UnixHTTPConnectionPool (host = 'localhost', port = None): истекло время чтения. (время ожидания чтения = 60)
compose.cli.errors.log_timeout_error: HTTP-запрос занял слишком много времени для выполнения. Повторите попытку с --verbose, чтобы получить отладочную информацию.
Если вы регулярно сталкиваетесь с этой проблемой из-за медленных сетевых условий, рассмотрите возможность установки COMPOSE_HTTP_TIMEOUT на более высокое значение (текущее значение: 60).
~~~

@titpetric может подтвердить, что у меня тоже есть эта проблема.

IMHO эта проблема находится на стороне докеров, а не на стороне докеров. Кто-то должен включить ведение журнала отладки в докере deamon, указать на задержки и сообщить о проблеме в апстрим. Я не уверен, что без этого можно было бы легко воспроизвести это.

Если кто-то желает потратить время, я бы посоветовал воспроизвести это, создав полностью загруженную папку для монтирования тома (должно быть что-то с более чем 100000 файлов / папок), чтобы увидеть, есть ли надежное воспроизведение проблемы. может быть достигнут. Вполне вероятно, что демон docker или само монтирование привязки ядра заранее кэширует некоторые данные inode. Что ... прискорбно.

Tcpdump также может подтвердить это в случае сетевой файловой системы (samba, nfs).

Такая же точная ошибка здесь

ERROR: for docker_async_worker__local_1  UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=70)

ERROR: for docker_elasticsearch__local_1  UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=70)

ERROR: for docker_web__local_1  UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=70)

Перезапуск Docker также исправил это для меня.

Перезагрузка - это не решение проблемы, ребята ...
Как этого избежать?

Столкнувшись с той же проблемой. Получение ошибки ниже для всех контейнеров докеров одноранговых организаций:

ОШИБКА: для DNS UnixHTTPConnectionPool (host = 'localhost', port = None): истекло время чтения. (время ожидания чтения = 60)

Это из-за несоответствия или назначения портов в файле набора?

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

Просто к сведению, в моем случае только повторная попытка с помощью docker-compose имеет тенденцию разрешать
Это. Я не думаю, что когда-либо перезапускал dockerd, эта проблема не сохраняется для
мне.

Пт, 2 августа 2019 г., в 13:39 Alex [email protected] написал:

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

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/docker/compose/issues/3927?email_source=notifications&email_token=AABY7EH4MVKGI56ZLEIUV5TQCQMHBA5CNFSM4CPDX2D2YY3PNVWWK3TUL52-5DFVREXueG43V2HS4DFVREXG43VWWWK3TUL52-5DFVREXG43V2HS4DFVREXG43V2
или отключить поток
https://github.com/notifications/unsubscribe-auth/AABY7EA3NTUP5SNZRTFWFEDQCQMHBANCNFSM4CPDX2DQ
.

Я тоже столкнулся с этой проблемой :(
UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)

Та же проблема, но и перезапуск Docker зависает. Единственный способ убить Docker / или перезагрузки , но это не может быть решением.

@bitbrain да, это происходит и со мной довольно долгое время.

Я нашел отличное решение для этого (на MacOS)

Причина, по которой это продолжалось со мной, заключалась в том, что у Docker было мало доступной памяти.

Увеличение памяти с 2 ГБ до 8 ГБ решило проблему для меня.

Я получал эту ошибку после запуска docker-compose up а затем docker-compose down пару раз. Все перепробовал в этой ветке. Выталкиваю ресурсы, перезагружаю Mac и переустанавливаю последнюю версию Docker. Я мог снова запустить docker-compose up после перезагрузки моего компьютера, но после повторения этих команд несколько раз он вернется к этой ошибке, и я не смог запустить docker-compose up .

Моя проблема, похоже, связана с конфликтом с другой службой ( pow ), которая была привязана к порту 80, когда один из моих контейнеров также был привязан к порту 80. Я удалил pow и не испытывал проблем в течение трех дней.

3 года открывается этот билет и все еще не решен. Проблема все еще возникает, даже если мы увеличим клиентское соединение до 120 секунд.

только что случилось с нашим сервером, открытый выпуск с 2016 года, wtf

перезапуск Docker работает для меня.

@ rodrigo-brito перезапуск - не решение ...

мой мужчина.

Также испытываю это сейчас. Дикий.

Возникает такая же проблема при попытке docker-compose up или docker-compose down. Я решил это, остановив службу mysqld, и как только контейнер запущен, я запускаю mysql. ОЗУ используется на 20%.

Запуск сообщества Docker Desktop для Mac v2.1.0.5

Я столкнулся с этой проблемой и решил, увеличив объем памяти, выделенной Docker (и уменьшив количество процессоров).
Вы можете сделать это в Docker -> Preferences -> Advanced.
Я перешел с 8 процессоров и 2 ГБ ОЗУ на 4 процессора и 16 ГБ ОЗУ для моей конкретной настройки.

Загляните в эту проблему на Ubuntu Server 18.04 LTS. Перезапуск докера не решает проблему, равно как и установка переменных среды. Есть идеи?

@bpogodzinski вы пытались увеличить настройки памяти в Docker? Я увеличил их с 2 ГБ до 8 ГБ, и это устранило проблему.

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

У нас была эта проблема, и она, как нам кажется, связана с именованным томом с большим количеством файлов. Я этого не понимаю, но для нас это случай, когда docker-compose (отредактировано для краткости), у которого есть служба:

   serviceA:
        ...
        volumes:
            - serviceA_volume: /srvA/folder

   volumes:
       - serviceA_volume:

Внутри Dockerfile для serviceA находится, казалось бы, безобидная и неэффективная команда:

...
RUN mkdir -p /srvA/folder && chown -R user /srvA/folder
...

Обратите внимание, что это рекурсивно меняет владельца в папке / srvA /, которая в названном томе представляет собой большую файловую систему со 100 КБ файлов. Однако это происходит, когда образ создан и эта папка пуста. Похоже, что использование именованного тома наследует разрешения локального файла изображения, а затем переходит к изменению разрешений именованных томов.

Это довольно преимущество и, вероятно, не та проблема, с которой сталкиваются все остальные, но это была наша проблема (переключение строки переключает ошибку). В результате тайм-аут HTTP, вероятно, вызван несколькими причинами.

В моем случае перезапуск докера никогда не решал проблему, а увеличение ресурсов определенно помогло.

По моему опыту, эта проблема часто возникает в небольших облачных инстансах, где объем ОЗУ вполне нормален при обычном функционировании, но оказывается недостаточным во время операций docker или docker-compose. Вы можете легко увеличить объем оперативной памяти, но это, вероятно, резко увеличит стоимость небольшой виртуальной машины.

В каждом случае добавление раздела подкачки или даже файла подкачки решало эту проблему для меня!

Только что случилось со мной на малиновом пи. Нет тома с огромным количеством файлов или чего-то еще.
На самом деле я уже довольно давно создаю эти контейнеры на этой малине (год или два, смех).
Не уверен, что изменилось.
Кажется немного «неожиданно».

Проблема все еще появляется на рабочем столе докера 2.2.0.3 на MacOs 🙁

Я решил проблему с помощью следующих команд:
docker volume prune
docker system prune
(может быть достаточно только одной из этих команд, но на данный момент невозможно воспроизвести ...)

Я решил проблему с помощью следующих команд:
docker volume prune
docker system prune
(может быть достаточно только одной из этих команд, но на данный момент невозможно воспроизвести ...)

Решение @amaumont помогло, хотя я думаю, что это будет продолжаться со временем.
Как уже говорили все, перезапуск докера - не правильное решение, это бандаж.

У нас тоже есть несколько проблем с docker-compose.

После установки MaxSessions 500 в sshd_config (см. # 6463) мы также получаем тайм-ауты чтения.
Установка обоих таймаутов на 120 секунд решила проблему для следующего запуска DOCKER_HOST=xxx<strong i="8">@yyy</strong> docker-compose up -d .

Во время второго запуска загрузка машины 30 (sic!), Прежде чем команда docker-compose завершилась ошибкой из-за тайм-аутов. Перезапуск докера не решает эту проблему, даже временно.
Сервер - это экземпляр AWS EC2 с достаточным количеством CPU / Disk / NetIO и т. Д., Файл compose включает 1 traefik и 3 сервиса с mailhog, так что здесь ничего особенного. Запуск docker-compose up -d с тем же файлом docker-compose.yml непосредственно на сервере работает надежно и, как и ожидалось.
Запуск с --verbose показывает более тысячи последовательных строк, содержащих compose.parallel.feed_queue: Pending: set() .

Я попытаюсь выполнить синхронизацию файла docker-compose с удаленным сервером и запустить docker-compose непосредственно на этом компьютере в качестве временного решения.

Мне помог просто перезапуск докера.

У меня довольно часто случается, когда я пытаюсь нажать на мой частный реестр из конвейеров битбакета. Хорошо работает при нажатии с локального ПК.
Некоторое время может помочь перезапуск докера, однако это «пока» длится не более 10 минут: c

UPD. установка DOCKER_CLIENT_TIMEOUT и COMPOSE_HTTP_TIMEOUT похоже, помогла, но я не знаю, как долго

Я начал получать их после перехода на Docker Edge с включенным кешированием.

Со мной это происходило постоянно с тех пор, как я начал использовать Docker 2-3 года назад. После того, как контейнер проработает какое-то время, он становится зомби, и необходимо перезапустить весь механизм Docker, чтобы все снова стало отзывчивым. Это похоже на некоторую утечку ресурсов, так как время простоя кажется очень важным для опытного поведения.

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

Вывод docker-compose version

docker-compose version 1.25.5, build 8a1c60f6
docker-py version: 4.1.0
CPython version: 3.7.5
OpenSSL version: OpenSSL 1.1.1f  31 Mar 2020

Выход docker version

Client: Docker Engine - Community
 Version:           19.03.8
 API version:       1.40
 Go version:        go1.12.17
 Git commit:        afacb8b
 Built:             Wed Mar 11 01:21:11 2020
 OS/Arch:           darwin/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.8
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.17
  Git commit:       afacb8b
  Built:            Wed Mar 11 01:29:16 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.2.13
  GitCommit:        7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

Выход docker-compose config

services:
  portal:
    container_name: developer_portal
    image: swedbankpay/jekyll-plantuml:1.3.8
    ports:
    - published: 4000
      target: 4000
    - published: 35729
      target: 35729
    volumes:
    - .:/srv/jekyll:rw
    - ./.bundle:/usr/local/bundle:rw
version: '3.7'

macOS Mojave 10.14.6.

Я столкнулся с той же проблемой, даже если увеличил ресурс с 4 ГБ ОЗУ, 1 ГБ подкачки до 6 ГБ ОЗУ, 2 ГБ подкачки.

Я тоже столкнулся с той же проблемой

также имеет ту же проблему

Я столкнулся с той же проблемой в Ubuntu 18.04 LTS (8 ГБ ОЗУ) с использованием HTTPS.

Я могу создавать контейнеры с помощью docker-compose up , однако после развертывания я не могу останавливать контейнеры с помощью docker-compose down . Перезапуск демона докеров или перезагрузка виртуальной машины оказались неэффективными. Добавление переменных среды тайм-аута ( DOCKER_CLIENT_TIMEOUT , COMPOSE_HTTP_TIMEOUT ) также ничего не дало.

Я могу взаимодействовать с контейнерами и останавливать их по отдельности, я могу проверять контейнеры, присоединяться к ним и все остальное, но я не могу остановить или убить их с помощью команды docker-compose .

Сообщение об ошибке всегда одно и то же:

msg: 'Error stopping project - HTTPSConnectionPool(host=[ommited], port=2376): Read timed out. (read timeout=120)

У меня была такая же проблема, когда в моем docker-compose.yml было следующее:

logging:
      driver: "json-file"
      options:
        max-size: 100m
        max-file: 10

Ошибка исчезла, когда я добавил кавычки около «10». В документации указано, что значения max-file и max-size должны быть строковыми, но все же. Сообщение об ошибке вводит в заблуждение.

У меня была такая же проблема, когда в моем docker-compose.yml было следующее:

logging:
      driver: "json-file"
      options:
        max-size: 100m
        max-file: 10

Ошибка исчезла, когда я добавил кавычки около «10». В документации указано, что значения max-file и max-size должны быть строковыми, но все же. Сообщение об ошибке вводит в заблуждение.

Вы спасаете мне день. Спасибо огромное!

У меня была такая же проблема, когда в моем docker-compose.yml было следующее:

logging:
      driver: "json-file"
      options:
        max-size: 100m
        max-file: 10

Ошибка исчезла, когда я добавил кавычки около «10». В документации указано, что значения max-file и max-size должны быть строковыми, но все же. Сообщение об ошибке вводит в заблуждение.

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

попробовал это

export DOCKER_CLIENT_TIMEOUT=120
export COMPOSE_HTTP_TIMEOUT=120

и, похоже, на данный момент проблема решена

Другие решения, упомянутые в этой теме:

• Перезапустить докер
• Увеличение ЦП и памяти Docker

Ну, у меня ничего не работало, кроме опции тайм-аута, спасибо вам.

Я получаю это с тех пор, как начал использовать смонтированный каталог NFS внутри одного из моих контейнеров. Этот смонтированный каталог NFS находится на медленном канале (в удаленном месте с низкой пропускной способностью соединения). Может ли это быть проблема?

Я очень часто сталкиваюсь с этим на Mac, Docker 2.4.0.0, в двух разных проектах с разными конфигурациями docker-compose.yml. Я не припомню, чтобы это происходило раньше ~ 1 недели назад, когда я обновился до 2.4.0.0. Есть регресс?

Я попытался увеличить тайм-аут до 600, увеличить оперативную память до 16 ГБ и своп до 4 ГБ, перезапустить Docker, перезапустить весь мой Macbook, ничего не работает, кроме случайных попыток снова и снова, тогда это иногда будет работать. Но тогда в следующий раз, когда мне нужно будет перезапустить или перестроить контейнер, та же проблема :(

Это началось с версии 2.4.0.0 и на Mac. Для меня обходной путь - перезапустить докер, но позже я снова столкнусь с ним.

Тоже самое! С обновлением до 2.4.0 наши настройки иногда вообще не запускаются из-за упомянутых ошибок Read timed out. , иногда запускаются только некоторые контейнеры, другие выдают эту ошибку. Я уже подумываю о понижении рейтинга!

Стоит упомянуть: эта проблема затрагивает как настройки с использованием общих ресурсов NFS, так и проекты, использующие «обычные» смонтированные тома.

Такая же проблема здесь, также на Mac и после обновления 2.4.0. Я сейчас пытаюсь понять, помогает ли переход на более раннюю версию.

Обновление: возврат к предыдущей версии, удаление кеша и восстановление устраняют проблему.

Я также недавно начал замечать эту проблему (Mac, 2.4.0.0), хотя никогда раньше ее не видел. Запуск docker image prune решил проблему на пару дней, но теперь она снова вернулась.

Также эта ошибка тайм-аута начала часто появляться после обновления 2.4.0 (в Mac OS Mojave 10.14.5)

Также это наблюдается с увеличением частоты после обновления до Docker Desktop 2.4.0.0 (48506) на MacOS Catalina.

У меня такие же проблемы с таймаутами, как с версии 2.4.0.0 в Mac OS. У меня никогда раньше не было этой проблемы.
Я попробовал крайнюю сборку 2.4.1.0 (48583), но у меня все еще та же проблема.

У меня такая же проблема, и перезагрузка докера исправила ее для MacOs Catalina (10.15.5) и версии докера 2.4.0.0

То же самое и здесь, не было проблем до обновления до Docker desktop 2.4.0.0.
Перезапуск рабочего стола Docker работает, но это всего лишь временное решение.

То же самое здесь, начиная с v2.4.0

Обновление: возврат к предыдущей версии, удаление кеша и восстановление устраняют проблему.

Попробую это. Даже не знаю, как это делается. Я полагаю, это путем удаления и загрузки более ранней версии?

Да, я удалил 2.4 и загрузил / переустановил 2.3. Теперь все работает, я могу запускать свои контейнеры как обычно.
Я получил 2.3 оттуда: https://docs.docker.com/docker-for-mac/release-notes/#docker -desktop-community-2302

Да, могу подтвердить, что это тоже повлияло на меня. Однозначно здесь виновата как-то v2.4.

Если вы регулярно сталкиваетесь с этой проблемой из-за медленных сетевых условий, рассмотрите возможность установки COMPOSE_HTTP_TIMEOUT на более высокое значение (текущее значение: 60).

Насколько 1 Гбит / с - это медленная сеть?

У меня тоже сработало понижение версии. Для тех, кто управляет Docker через Homebrew

brew uninstall docker
brew install https://raw.githubusercontent.com/Homebrew/homebrew-cask/9da3c988402d218796d1f962910e1ef3c4fca1d3/Casks/docker.rb

Если вы регулярно сталкиваетесь с этой проблемой из-за медленных сетевых условий, рассмотрите возможность установки COMPOSE_HTTP_TIMEOUT на более высокое значение (текущее значение: 60).

Насколько 1 Гбит / с - это медленная сеть?

В моем случае это произошло из-за подключенного сетевого диска NFS.
Основная причина "низкой" скорости сети заключалась в использовании NFS, а не в скорости физического соединения.
Но это определенно показывает, что в реализации есть проблема, и я был бы удивлен, если изменение HTTP_TIMEOUT решит ее.

Тоже самое. Значительное замедление при создании контейнера, что привело к вышеупомянутой ошибке тайм-аута HTTP в Docker для Mac v2.4. Установка COMPOSE_HTTP_TIMEOUT = 120 сработала, но медленное создание контейнера все еще является новой проблемой. Это также исправляет переход на версию 2.3.

Я могу подтвердить ту же проблему, так как я установил Docker для Mac v2.4.
Я также могу подтвердить значительное увеличение потребления ОЗУ и ЦП даже в моменты простоя, только при запущенном демоне Docker. Но я думаю, это не имеет ничего общего с самим пакетом compose.

У меня была такая же проблема. Удалил 2.40 и установил 2.3 по ссылке, упомянутой @ddesrousseaux, и у меня больше нет

https://docs.docker.com/docker-for-mac/release-notes/#docker -desktop-community-2302

Эта проблема все еще существует в Docker v. 2.4.3.0 .

Я также понизил версию до 2.3 с 2.4, чтобы обойти серьезные проблемы с медлительностью в версии 2.4. С радостью предоставлю любые журналы, которые могут быть полезны для отладки того, что здесь происходит.

Повторяя вышесказанное, это началось для меня в версии 2.4.2.x. Что-то изменилось в обновлении с 2.3.

Я провел несколько тестов в среде Linux и столкнулся с аналогичной проблемой. Я установил последний бинарный файл docker-compose (v1.27.4), и у меня возникла та же проблема с тайм-аутом, о которой вы, ребята, сообщаете.

После перехода на версию 1.27.2, аналогичную версии Docker для Mac 2.3, проблема исчезла.

Та же проблема с текущей версией Ubuntu 20.04.

Моя проблема заключалась в том, что я установил docker и docker-compose с помощью snap и apt. Я удалил их, перезагрузил, а затем выполнил официальные инструкции по установке на https://docs.docker.com/engine/install/ubuntu/ и https://docs.docker.com/compose/install/

У меня все еще часто возникают ошибки тайм-аута с момента обновления 2.4.0, которые до сих пор не исправлены в 2.5.0

Ага, здесь то же самое. У меня все работало нормально последние 2 года. Но 2 месяца назад, когда я когда-либо хотел создать 1 экземпляр и запустить другой проект докера, он выдает:
для apache UnixHTTPConnectionPool (host = 'localhost', port = None): истекло время чтения.

Перезапуск Docker устраняет проблему. Но это настоящая боль, когда мне приходится переключаться между проектами несколько раз за 1 день

Возникла одна и та же проблема с версии 2.4, 300% ЦП постоянно, 2.5 не помогло, понизился до 2.3, и все в порядке. Это на последнем MacBook с процессором i7 и оперативной памятью 32g

Я только что обновился до последней версии Docker для Mac (v2.5.0.1), и проблема, похоже, решена.
Больше никаких ошибок UnixHTTPConnection и 100% загрузки ЦП.

Не уверен, что кто-то еще может это подтвердить.

Как ты это получил? Открытие Docker на Mac и выполнение «Проверить наличие обновлений» по-прежнему говорит о том, что у меня последняя версия 2.4.2.0.

Я только что обновился до последней версии Docker для Mac (v2.5.0.1), и проблема, похоже, решена.
Больше никаких ошибок UnixHTTPConnection и 100% загрузки ЦП.

Не уверен, что кто-то еще может это подтвердить.

Я только что столкнулся с проблемой на версии 2.5.0.1. Кажется, что перезапуск докера (по крайней мере, временно) решил проблему.

Как ты это получил? Открытие Docker на Mac и выполнение «Проверить наличие обновлений» по-прежнему говорит о том, что у меня последняя версия 2.4.2.0.

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

Вы можете проверить это в примечаниях к выпуску Docker для Mac (и получить оттуда любой новый установщик).

Я использую Edge. Это, вероятно, объясняет это.

Могу подтвердить, что v2.5.0.1, по крайней мере, немного лучше. Больше не получаются тайм-ауты при каждой загрузке, и я еще не сталкивался с этим с момента обновления сегодня утром. Однако время загрузки контейнера все еще кажется намного медленнее, чем 2.3.

Изменить: снова столкнулся с ошибками тайм-аута примерно после 4 или 5 перезапусков моего проекта docker-compose. Также возникла новая ошибка с 2.5.0.1: Cannot start service <container name>: error while creating mount source path <local mount path>: mkdir <local mount path>: file exists

Могу подтвердить, что v2.5.0.1, по крайней мере, немного лучше. Больше не получаются тайм-ауты при каждой загрузке, и я еще не сталкивался с этим с момента обновления сегодня утром. Однако время загрузки контейнера все еще кажется намного медленнее, чем 2.3.

Изменить: снова столкнулся с ошибками тайм-аута примерно после 4 или 5 перезапусков моего проекта docker-compose. Также возникла новая ошибка с 2.5.0.1: Cannot start service <container name>: error while creating mount source path <local mount path>: mkdir <local mount path>: file exists

Хорошо, у меня все еще возникают проблемы с версией 2.5.0.1. Использование процессора по-прежнему слишком велико по сравнению с v2.3.x, а скорость также довольно низкая.

Может ли кто-нибудь из команды Docker признать это и оценить это?

Боже, прошло 4 года, этот вопрос так и не решен, и со мной такое случается постоянно