Compose: UnixHTTPConnectionPool (host = 'localhost', port = None): Tiempo de lectura agotado. (tiempo de espera de lectura = 60)

probé esto

export DOCKER_CLIENT_TIMEOUT=120
export COMPOSE_HTTP_TIMEOUT=120

y parece solucionar el problema por ahora

Otras soluciones que las personas mencionaron en este hilo:

• Reiniciar Docker
• Aumente la CPU y la memoria de Docker

¿Ocurre si apagas tu WiFi? Podría estar relacionado con https://github.com/docker/docker-py/issues/1076.

Otra teoría, si su servicio tiene tty: True habilitado, podría ser # 3106

Veo exactamente el mismo problema con la última versión beta para Mac. Mismo error si ejecuto docker-compose create

¿Podría esto estar relacionado con tener una capa muy grande en la imagen? (una operación npm install muy larga que tarda aproximadamente un minuto en aplanarse en una capa cuando la ventana acoplable crea la imagen)

También estamos viendo este problema al usar un archivo docker compose con 6 contenedores [docker-compose versión 1.8.1, compilación 878cff1] tanto en Windows como en Mac [Versión 1.12.2-rc1-beta27 (compilación: 12496)
179c18cae7]

El aumento de los recursos disponibles para la ventana acoplable parece reducir la posibilidad de que suceda (al igual que la extensión de las variables de tiempo de espera), pero nunca se elimina.

También tenemos algunas capas de gran tamaño (240 MB es el más grande, el comando de instalación del paquete principal) y estamos vinculando a un directorio de host con 120 MB de archivos en un par de contenedores.

A partir de diferentes intentos de solucionar esto, encontré algo que podría arrojar algo de luz sobre una posible solución:

Al principio, mi escenario se parecía un poco a esto:

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

Mi ruta montada incluía muchos directorios con archivos estáticos grandes que realmente no necesitaba montar en términos de recarga de código. Así que terminé cambiando por algo como esto:

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

Esto dejó fuera del tiempo de ejecución el montaje de todos mis archivos estáticos grandes, lo que hizo que el servicio se iniciara mucho más rápido.

Lo que entiendo de esto es: cuantos más archivos monte, especialmente cuanto más grandes sean (imágenes en MB en lugar de archivos fuente en Bs / KB), los tiempos de carga aumentan mucho.

Espero que esto ayude

+1
Veo este problema de tiempo de espera cada semana, generalmente después de un fin de semana inactivo, mientras intentaba conectarme a mis contenedores, se agotó el tiempo ...
Tengo que terminar el proceso de Docker en ejecución y reiniciarlo para que funcione ...

+1
Me pasa cada vez que intento reiniciar los contenedores porque ya no responden después de un día. No estoy seguro de si mi caso tiene que ver con el montaje, ya que estoy tratando de detener los contenedores.

Ocurriendo con un contenedor nginx , Up 47 hours .
Docker para 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).

Gracias @gvilarino , creo que el montaje de archivos grandes es la causa de este problema en mi servidor Linux. Su fragmento podría ser una solución si los archivos grandes no se necesitan en el contenedor.

Sin embargo, me pregunto por qué el montaje es lento en Docker. ¿Quizás desencadena la copia del disco? ¿Pero por qué?

@cherrot No diría que soy extremadamente competente en el tema, pero creo que esto tiene que ver con el controlador de almacenamiento que usa Docker y cómo funciona internamente para mantener las capas en orden. Use docker info para ver qué controlador de almacenamiento está usando su demonio (probablemente aufs , que es el más lento) y, según el sistema operativo de su host, puede cambiarlo por otra cosa ( overlay es una mejor opción, si es compatible). Hay alternativas más rápidas como LCFS, pero Docker no las admite comercialmente, por lo que estaría solo allí.

También estamos viendo este tiempo muerto. Parece que también se debe a los volúmenes que estamos usando.

Necesitamos algunos contenedores para acceder a algunos recursos compartidos de la red SMB. Así que montamos esos recursos compartidos en el sistema host y los montamos dentro del contenedor. Pero a veces, la comunicación entre Windows Server y nuestro host Linux se detiene (consulte https://access.redhat.com/solutions/1360683) y esto bloquea el inicio o la detención de nuestro contenedor, que simplemente se agota después de un tiempo.

Todavía no tengo una solución. Estoy buscando un complemento de volumen que admita SMB o para que desaparezca el problema de comunicación de bloqueo en SMB. pero aún no hay una solución real.

FWIW: Para las personas que aterrizan aquí a través del motor de búsqueda y encuentran su resolución, he podido solucionar este problema simplemente con el método _ ¿Intentaste apagarlo y encenderlo nuevamente? He reiniciado mi cliente Docker Mac OS.

+1 en eso, estoy ejecutando pruebas de estrés en mi instancia que ejecuta 4 contenedores y la ventana acoplable se cuelga incluso por docker ps -a así que estoy tratando de reiniciar los contenedores pero estoy obteniendo
UnixHTTPConnectionPool(host='localhost', port=None): Read timed out y

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)

Solo si estoy reiniciando el servicio docker parece estar resuelto, ¿alguna idea?

+1

`Reiniciando web-jenkins_jenkins_1 ...

ERROR: para web-jenkins_jenkins_1 UnixHTTPConnectionPool (host = 'localhost', port = None): tiempo de lectura agotado. (tiempo de espera de lectura = 130)
ERROR: Una solicitud HTTP tardó demasiado en completarse. Vuelva a intentarlo con --verbose para obtener información de depuración.
Si encuentra este problema con regularidad debido a las lentas condiciones de la red, considere configurar COMPOSE_HTTP_TIMEOUT en un valor más alto (valor actual: 120) .`

reinicio Docker, se solucionó. pero todos los días necesito reiniciar

reiniciar Docker me funciona.

+1 reiniciar Docker también funcionó para mí.

Encontré este problema mientras creaba una imagen de Docker sustancialmente grande y luego intentaba enviarla a un registro remoto. Reiniciar Docker no era una solución aplicable, pero la respuesta de @bodaz se dirigió a mí: https://github.com/docker/compose/issues/3927#issuecomment -245948736

@ rodrigo-brito - He estado recibiendo este error por un tiempo y reiniciar Docker Deamon ha estado resolviendo el problema, no más desde que agregué otro servicio a mi proyecto.

Tengo el mismo problema, pero tengo una configuración bastante simple.
Solo tengo un contenedor de verdaccio 3 basado en una imagen con 164 MB de tamaño.
Esto es muy decepcionante: /

Estoy usando un MBP Pro 13 de 2015

Me sucedió debido a un gran rango de puertos, en realidad crea una regla por puerto ...

Un simple sudo service docker restart resuelve esto constantemente cada vez que ocurre.

También me pasó a mí, en mi caso docker-compose push (ni siquiera intenté ejecutar la aplicación) en Azure DevOps.

Mis otras compilaciones no usan docker-compose sino simple docker push

Eliminé la versión kubuntu 18.04.1 docker.io de docker e instalé docker-ce 18.09.0
El problema desapareció.

En su lugar, acabo de convertir el paso de empuje docker-compose en empujes individuales.

Estamos viendo este tiempo de espera cuando ejecutamos un contenedor a través de docker-compose o mediante la biblioteca docker-py (se agota incluso después de aumentar el tiempo de espera a 2 minutos); sin embargo, no vemos el error cuando ejecutamos a través de la CLI de Docker (el contenedor se inicia instantáneamente). También vemos el problema solo en un servidor CI de Linux y no en nuestras Mac. Estamos trabajando para crear un ejemplo mínimo reproducible.

Si tiene este problema con docker-compose kill en una máquina virtual debian en el host de macos, instale directamente desde la ventana acoplable. (Docker versión 18.09.0, compilación 4d60db4)

Tuve el mismo error al iniciar Docker con log-driver: syslog cuando el puerto rsyslog no estaba disponible.
Error starting container 0ba2fb9540ec6680001f90dce56ae3a04b831c8146357efaab79d4756253ec8b: UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)

reiniciar Docker me funciona.

@ rodrigo-brito reiniciar no es una solución ...

Me sucedió debido a un gran rango de puertos, en realidad crea una regla por puerto ...

Exactamente lo mismo para mí. Después del error, el demonio de la ventana acoplable continúa consumiendo memoria hasta que se agota. Necesito systemctl stop docker antes de que mi sistema muera. (Docker versión 18.09.3, compilación 774a1f4)

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

El simple reinicio de Docker resolvió esto por mí ...

Parece que el problema sigue presente en las versiones recientes de docker-ce. Estoy comenzando ~ 5 contenedores, y el lento tiene un montaje de volumen de la ventana acoplable que apunta a un recurso compartido de NFS. Ningún contenedor expone ningún puerto, ¿alguien averiguó si se trata de un error válido ( port=None parece sospechoso)?

~~~
Cliente:
Versión: 18.09.5
Versión de API: 1.39
Go versión: go1.10.8
Confirmación de Git: e8ff056dbc
Construido: Thu Apr 11 04:44:28 2019
SO / Arch: linux / amd64
Experimental: falso

Servidor: Docker Engine - Comunidad
Motor:
Versión: 18.09.5
Versión API: 1.39 (versión mínima 1.12)
Go versión: go1.10.8
Confirmación de Git: e8ff056
Construido: Thu Apr 11 04:10:53 2019
SO / Arch: linux / amd64
Experimental: falso
~~~

Se agregó más salida de --verbose . No creo que haya nada de utilidad aquí, solo dice durante mucho tiempo que alguna operación de creación de contenedores está esperando durante mucho tiempo. Aparentemente, está usando sondeo, ya que el siguiente mensaje se imprime aproximadamente 1x / seg:

~compose.parallel.feed_queue: Pendiente: set ()~

El localhost / port = Node es una pista falsa, creo, ya que la conexión se realiza con docker.sock, por lo que no es un error nulo escondido en alguna parte. Creo que esto deberá ser rastreado dentro de la ventana acoplable, no es que el manejo de esta solicitud aquí sea óptimo.

Parece que a Docker-compose le falta algún tipo de ID de solicitud que podría registrarse, por lo que sabríamos qué solicitud se está estancando. Por ejemplo, sé que mi contenedor api no se pudo crear dentro del tiempo de espera, pero el registro de solicitudes no ayuda en absoluto. Tal vez alguien más pueda agregar información aquí:

~~~
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',
'Advertencias': Ninguna}
compose.cli.verbose_proxy.proxy_callable: dockerconnect_container_from_network -> Ninguno
compose.cli.verbose_proxy.proxy_callable: docker inspect_container <- ('22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f')
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network <- ('ba67095c5ea718af13a09798bc2f5ab24f5d0b54ce684b6f4cb248ab705df900', 'proxy', alias = ['ip6705dress', Nonedress = ['dirección_de_punto_de_inicial], Ninguno
urllib3.connectionpool._make_request: http: // localhost: None "GET /v1.25/containers/22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f/json HTTP / 1.1" 200 Ninguno
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',
'Advertencias': Ninguna}
compose.cli.verbose_proxy.proxy_callable: docker inspect_container <- ('1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec')
compose.parallel.feed_queue: Pendiente: 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: Ninguno "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 Ninguno
compose.cli.verbose_proxy.proxy_callable: dockerconnect_container_from_network -> Ninguno
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network -> Ninguno
compose.cli.verbose_proxy.proxy_callable: dockerconnect_container_from_network <- ('22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f', 'proxy')
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network <- ('7d81ef23610f1b8f7ac95837cbf6c9eef977b5b0846fea24be5c7054e471df39', 'proxy', alfiasesv = Ninguno_directorio_de_punto_de_punto_de_directorio, Ninguno.
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: Pendiente: set ()
compose.parallel.feed_queue: Pendiente: set ()
compose.cli.verbose_proxy.proxy_callable: dockerconnect_container_from_network <- ('1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec', 'proxy')
compose.cli.verbose_proxy.proxy_callable: docker create_container -> {'Id': 'ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af',
'Advertencias': Ninguna}
urllib3.connectionpool._make_request: http: // localhost : None "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
urllib3.connectionpool._make_request: http: // localhost : Ninguno "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: dockerconnect_container_from_network -> Ninguno
compose.parallel.feed_queue: Pendiente: set ()
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network -> Ninguno
compose.cli.
compose.parallel.feed_queue: Pendiente: set ()
urllib3.connectionpool._make_request: http: // localhost : None "GET /v1.25/containers/ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af/json HTTP / 1.1" 200 Ninguno
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: Pendiente: set ()
compose.cli.verbose_proxy.proxy_callable: dockerconnect_container_from_network -> Ninguno
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: docker connect_container_to_network <- ('1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec', 'proxy', aliases_d044f4d0ec ',' proxy ', aliases_d044f4d0ec', 'proxy', aliases_d044f4d0ec ',' proxy ', aliases_d044f4d0ec', 'proxy', aliases_d044f4d0ec ',' proxy ', aliases_d044f4b)
compose.cli.verbose_proxy.proxy_callable: dockerconnect_container_from_network <- ('ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af', 'proxy')
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network -> Ninguno
compose.cli.verbose_proxy.proxy_callable: docker start <- ('22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f')
compose.parallel.feed_queue: Pendiente: 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: dockerconnect_container_from_network -> Ninguno
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network -> Ninguno
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network <- ('ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af', 'proxy', alias '' alias = ['ip_dress_pc, ninguno_dirección_pc, ninguno_dirección_pc, ninguno_dirección_pc. Ninguna)
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 -> Ninguno
compose.cli.verbose_proxy.proxy_callable: docker start <- ('ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af')
compose.parallel.feed_queue: Pendiente: set ()
compose.parallel.feed_queue: Pendiente: set ()
compose.parallel.feed_queue: Pendiente: set ()
compose.parallel.feed_queue: Pendiente: set ()
...
- omitido ~ 30 líneas
...
Creando api-comentarios ... hecho
compose.cli.verbose_proxy.proxy_callable: inicio de la ventana acoplable -> Ninguno
compose.parallel.parallel_execute_iter: Procesamiento terminado: ServiceName (proyecto = 'api', servicio = 'comentarios', número = 1)
compose.parallel.feed_queue: Pendiente: set ()
compose.parallel.parallel_execute_iter: Procesamiento finalizado:
compose.parallel.feed_queue: Pendiente: set ()
Creando api-memcache ... hecho
urllib3.connectionpool._make_request: http: // localhost: None "POST /v1.25/containers/22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f/start HTTP / 1.1" 204 0
compose.cli.verbose_proxy.proxy_callable: inicio de la ventana acoplable -> Ninguno
compose.parallel.parallel_execute_iter: Procesamiento finalizado: ServiceName (proyecto = 'api', servicio = 'memcache', número = 1)
compose.parallel.feed_queue: Pendiente: set ()
compose.parallel.parallel_execute_iter: Procesamiento finalizado:
compose.parallel.feed_queue: Pendiente: set ()
compose.parallel.feed_queue: Pendiente: set ()
compose.parallel.feed_queue: Pendiente: set ()
compose.parallel.feed_queue: Pendiente: 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: inicio de la ventana acoplable -> Ninguno
Creando api-comments-db ... hecho
compose.parallel.feed_queue: Pendiente: set ()
compose.parallel.parallel_execute_iter: Procesamiento finalizado:
compose.parallel.feed_queue: Pendiente: set ()
compose.parallel.feed_queue: Pendiente: set ()
compose.parallel.feed_queue: Pendiente: set ()
compose.parallel.feed_queue: Pendiente: set ()
compose.parallel.feed_queue: Pendiente: set ()
- omitido ~ 15 líneas
Creando api-redis ... hecho
compose.parallel.feed_queue: Pendiente: 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: inicio de la ventana acoplable -> Ninguno
compose.parallel.parallel_execute_iter: Procesamiento terminado: ServiceName (project = 'api', service = 'redis', number = 1)
compose.parallel.feed_queue: Pendiente: set ()
compose.parallel.parallel_execute_iter: Procesamiento finalizado:

compose.parallel.feed_queue: Pendiente: set ()

- omitido más de 100 líneas
compose.parallel.parallel_execute_iter: Falló: ServiceName (proyecto = 'api', servicio = 'api', número = 1)
compose.parallel.feed_queue: Pendiente: set ()

ERROR: para api UnixHTTPConnectionPool (host = 'localhost', port = None): tiempo de lectura agotado. (tiempo de espera de lectura = 60)
compose.parallel.parallel_execute_iter: Falló:
compose.parallel.feed_queue: Pendiente: set ()

ERROR: para api UnixHTTPConnectionPool (host = 'localhost', port = None): tiempo de lectura agotado. (tiempo de espera de lectura = 60)
compose.cli.errors.log_timeout_error: una solicitud HTTP tardó demasiado en completarse. Vuelva a intentarlo con --verbose para obtener información de depuración.
Si encuentra este problema regularmente debido a las lentas condiciones de la red, considere configurar COMPOSE_HTTP_TIMEOUT en un valor más alto (valor actual: 60).
~~~

@titpetric puede confirmar que también tengo este problema.

En mi humilde opinión, este problema está en el lado de la ventana acoplable, no en el lado de la ventana acoplable. Alguien debería activar el registro de depuración en el demonio de la ventana acoplable y señalar los retrasos allí, y presentar un problema en sentido ascendente. No estoy seguro de que uno pueda reproducir esto fácilmente sin eso.

Si alguien está dispuesto a dedicar tiempo, le sugiero que lo repita creando una carpeta completamente cargada para un montaje de volumen (algo con alrededor de 100000+ archivos / carpetas debería ser suficiente), para ver si una reproducción confiable del problema puede lograrse. Es probable que el demonio de la ventana acoplable, o el propio montaje del enlace del kernel, almacene en caché algunos de los datos de inodo de antemano. Lo cual ... es lamentable.

Un tcpdump también podría confirmar esto en el caso de un sistema de archivos de red (samba, nfs).

El mismo error exacto aquí

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)

El reinicio de Docker también lo solucionó para mí.

Reiniciar no es una solución, chicos ...
¿Cómo evitar esto para siempre?

Frente al mismo problema. Obteniendo el siguiente error para todos los contenedores de la ventana acoplable de los pares de la organización:

ERROR: para DNS UnixHTTPConnectionPool (host = 'localhost', port = None): tiempo de lectura agotado. (tiempo de espera de lectura = 60)

¿Se debe a alguna discrepancia de puerto o asignación en el archivo de redacción?

Sí, constantemente me encuentro con este problema. Estoy de acuerdo en que reiniciar no es una solución, pero nada más parece funcionar: /

Solo un FYI, con mi caso solo reintentando con docker-compose tiende a resolverse
eso. No creo que haya reiniciado nunca dockerd, este problema no persiste durante
yo.

El viernes 2 de agosto de 2019 a las 13:39, Alex [email protected] escribió:

Sí, constantemente me encuentro con este problema. Estoy de acuerdo que reiniciar no es
una solución, pero nada más parece hacer el truco: /

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/compose/issues/3927?email_source=notifications&email_token=AABY7EH4MVKGI56ZLEIUV5TQCQMHBA5CNFSM4CPDX2D2YY3PNVWWK3TUL52HS4DFVREXP63JWWMVNX2DFVREXG43VMVBX ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AABY7EA3NTUP5SNZRTFWFEDQCQMHBANCNFSM4CPDX2DQ
.

También estoy enfrentando este problema :(
UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)

El mismo problema aquí, también se bloquea al reiniciar Docker. La única forma es matar a Docker o reiniciar, pero esa no puede ser la solución.

@bitbrain sí, esto también me ha estado sucediendo desde hace bastante tiempo.

Encontré una buena solución para esto (en MacOS)

La razón por la que esto seguía sucediéndome era que Docker tenía poca memoria disponible.

El aumento de la memoria de 2 GB a 8 GB resolvió el problema.

Recibí este error después de ejecutar docker-compose up y luego docker-compose down un par de veces. Intenté todo en este hilo. Aumento de los recursos, reinicio de mi mac y reinstalación de la última versión de Docker. Podría hacer que docker-compose up ejecute nuevamente después de reiniciar mi caja, pero después de ejecutar esos comandos varias veces, volvería a este error y no pude hacer que docker-compose up ejecutara.

Mi problema parece haber sido un conflicto con otro servicio ( pow ) que se vinculaba al puerto 80 cuando uno de mis contenedores también se vinculaba al puerto 80. Desinstalé pow y no he tenido ningún problema durante tres días.

3 años abierto este boleto y aún sin resolver. El problema persiste incluso si aumentamos la conexión del cliente a 120 segundos.

acaba de suceder en nuestro servidor, problema abierto desde 2016, wtf

reiniciar Docker me funciona.

@ rodrigo-brito reiniciar no es una solución ...

mi hombre.

También estoy experimentando esto ahora. Salvaje.

Tiene el mismo problema al intentar docker-compose up o docker-compose down. Lo resolví deteniendo el servicio mysqld y una vez que el contenedor está activo, inicio mysql. La RAM está al 20% de uso.

Ejecución de Docker Desktop Community para Mac v2.1.0.5

Me encontré con este problema y lo resolví aumentando la cantidad de memoria asignada a Docker (y disminuyendo la cantidad de CPU).
Puede hacer esto en Docker -> Preferencias -> Avanzado.
Pasé de 8 CPU y 2 GB de RAM a 4 CPU y 16 GB de RAM para mi configuración particular.

Me encontré con este problema en Ubuntu Server 18.04 LTS. Reiniciar la ventana acoplable no soluciona el problema, al igual que configurar las variables de entorno. ¿Algunas ideas?

@bpogodzinski, ¿ ha intentado aumentar la configuración de memoria en Docker? Los aumenté de 2GB a 8GB y eso me solucionó el problema.

En términos generales, este problema parece ocurrir cuando los contenedores requieren más memoria que la memoria disponible configurada en Docker y luego las cosas simplemente se cuelgan.

Tuvimos este problema y parece (para nosotros) estar relacionado con un volumen con nombre con muchos archivos. No lo entiendo, pero es el caso para nosotros que un docker-compose (editado por brevedad) que tiene un servicio:

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

   volumes:
       - serviceA_volume:

Dentro del Dockerfile para serviceA se encuentra el comando aparentemente inofensivo e ineficaz:

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

Tenga en cuenta que esto cambia el propietario de forma recursiva en la carpeta / srvA / que en el volumen nombrado es un gran sistema de archivos con 100K de archivos. Sin embargo, esto sucede cuando se crea la imagen y esa carpeta está vacía. Parece que el uso del volumen con nombre hereda los permisos del archivo local de imagen y luego procede a cambiar los permisos de los volúmenes con nombre.

Esto es bastante complicado y probablemente no sea el mismo problema que todos los demás tienen, pero era nuestro problema (alternar la línea alterna el error). El resultado es que este tiempo de espera de http probablemente se deba a múltiples causas.

Reiniciar Docker nunca resolvió el problema en mi caso, el aumento de los recursos definitivamente lo hizo.

Desde mi experiencia, este problema a menudo surge en instancias pequeñas de la nube donde la cantidad de RAM es perfecta durante el funcionamiento regular, pero resulta insuficiente durante las operaciones de docker o de composición de docker. Podría aumentar fácilmente la RAM, pero probablemente aumentaría drásticamente el costo de una máquina virtual pequeña.

En cada caso, ¡agregar una partición de intercambio o incluso un archivo de intercambio resolvió este problema para mí!

Se me acaba de ocurrir en una frambuesa pi. Sin volumen con gran cantidad de archivos ni nada.
En realidad, he estado generando estos contenedores en esa frambuesa por un tiempo (uno o dos años jajaja).
No estoy seguro de qué cambió.
Parece un poco "inesperado".

El problema sigue apareciendo en Docker Desktop 2.2.0.3 en MacOs 🙁

Resolví mi problema con los siguientes comandos:
docker volume prune
docker system prune
(solo uno de estos comandos puede ser suficiente, pero no se puede reproducir por el momento ...)

Resolví mi problema con los siguientes comandos:
docker volume prune
docker system prune
(solo uno de estos comandos puede ser suficiente, pero no se puede reproducir por el momento ...)

La solución de @amaumont ayudó, aunque creo que esto continuaría regresando con el tiempo.
Como han dicho todos los demás, reiniciar Docker no es una solución adecuada, es una curita.

También tenemos varios problemas con docker-compose.

Después de configurar MaxSessions 500 en sshd_config (ver # 6463) ahora también obtenemos tiempos de espera de lectura.
Establecer ambos tiempos de espera en 120 segundos resolvió el problema para la próxima ejecución DOCKER_HOST=xxx<strong i="8">@yyy</strong> docker-compose up -d .

Durante la segunda ejecución, la carga de la máquina llegó a 30 (¡sic!) Antes de que el comando docker-compose fallara debido a los tiempos de espera. Un reinicio de la ventana acoplable no resuelve este problema, ni siquiera temporalmente.
El servidor es una instancia de AWS EC2 con suficiente CPU / Disco / NetIO, etc., el archivo de composición incluye 1 traefik y 3 servicios con mailhog, así que no hay nada especial aquí. Ejecutar docker-compose up -d con el mismo archivo docker-compose.yml directamente en el servidor funciona de manera confiable y como se esperaba.
Ejecutar con --verbose muestra más de mil líneas consecutivas que contienen compose.parallel.feed_queue: Pending: set() .

Intentaré rsync el archivo docker-compose con el servidor remoto y ejecutaré docker-compose directamente en esa máquina como solución.

Para mí, me ayudó reiniciar Docker.

Me sucede con bastante frecuencia cuando intento ingresar a mi registro privado desde las canalizaciones de bitbucket. Aunque funciona bien cuando se empuja desde la PC local.
Reiniciar Docker podría ayudar por un tiempo, sin embargo, este "mientras" dura 10 minutos como máximo: c

upd. configurar DOCKER_CLIENT_TIMEOUT y COMPOSE_HTTP_TIMEOUT pareció ayudar, pero no sé por cuánto tiempo

Empecé a recibir estos desde que cambié a Docker Edge con el almacenamiento en caché activado

Esto me ha estado sucediendo de manera bastante constante desde que comencé a usar Docker hace 2 o 3 años. Después de que un contenedor se ha estado ejecutando durante un tiempo, se convierte en un zombi y es necesario reiniciar todo el motor de Docker para que todo vuelva a responder. Esto se siente como una fuga de recursos de algún tipo, ya que el tiempo de inactividad parece ser muy relevante para el comportamiento experimentado.

Si no se están ejecutando contenedores, o solo se ejecutan durante un corto período de tiempo, todo parece funcionar bien durante días o semanas. Pero tan pronto como dejo que un contenedor funcione durante unas horas, deja de responder, tengo que forzarlo a detenerlo en la línea de comando y cualquier intento de comunicarme con docker o docker-compose simplemente falla con un tiempo de espera. Un reinicio es la única solución que funciona.

Salida de 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

Salida de 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

Salida de 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.

Enfrenté el mismo problema, incluso aumenté los recursos de 4 GB de RAM, intercambio de 1 GB a 6 GB de RAM, intercambio de 2 GB.

También estoy enfrentando el mismo problema

también tengo el mismo problema

He estado enfrentando el mismo problema en Ubuntu 18.04 LTS (8 GB de RAM) usando HTTPS.

Puedo generar contenedores con docker-compose up , sin embargo, una vez implementado, no puedo detener contenedores con docker-compose down . Reiniciar el demonio de la ventana acoplable o reiniciar la máquina virtual ha demostrado ser ineficaz. Agregar variables de entorno de tiempo de espera ( DOCKER_CLIENT_TIMEOUT , COMPOSE_HTTP_TIMEOUT ) tampoco hizo nada.

Puedo interactuar y detener contenedores individualmente, puedo inspeccionar contenedores, adjuntarlos y cualquier otra cosa, pero no puedo detenerlos o matarlos usando el comando docker-compose .

El mensaje de error es siempre el mismo:

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

Estaba teniendo el mismo problema cuando tuve lo siguiente en mi docker-compose.yml:

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

El error desapareció cuando agregué comillas alrededor de "10". Esto se indica en los documentos que los valores para max-file y max-size deben ser string, pero aún así. El mensaje de error es bastante engañoso.

Estaba teniendo el mismo problema cuando tuve lo siguiente en mi docker-compose.yml:

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

El error desapareció cuando agregué comillas alrededor de "10". Esto se indica en los documentos que los valores para max-file y max-size deben ser string, pero aún así. El mensaje de error es bastante engañoso.

Salvas mi día. Muchas gracias!

Estaba teniendo el mismo problema cuando tuve lo siguiente en mi docker-compose.yml:

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

El error desapareció cuando agregué comillas alrededor de "10". Esto se indica en los documentos que los valores para max-file y max-size deben ser string, pero aún así. El mensaje de error es bastante engañoso.

Estoy configurando el controlador de registro en el nivel del demonio de Docker. Estoy usando fluentd como mi controlador de registro, así que desafortunadamente esta solución no me funcionará. = /

probé esto

export DOCKER_CLIENT_TIMEOUT=120
export COMPOSE_HTTP_TIMEOUT=120

y parece solucionar el problema por ahora

Otras soluciones que las personas mencionaron en este hilo:

• Reiniciar Docker
• Aumente la CPU y la memoria de Docker

Bueno, nada funcionó para mí, excepto la opción de tiempo de espera, felicitaciones.

Recibo esto desde que comencé a usar un directorio montado en NFS dentro de uno de mis contenedores. Ese directorio montado en NFS está en un enlace lento (en una ubicación remota que tiene una conexión de ancho de banda bajo). ¿Podría ser el problema?

Estoy experimentando esto con mucha frecuencia en Mac, Docker 2.4.0.0, en dos proyectos diferentes con diferentes configuraciones de docker-compose.yml. No recuerdo que haya sucedido antes de ~ hace una semana, que es cuando actualicé a 2.4.0.0. ¿Existe una regresión?

Intenté aumentar el tiempo de espera a 600, aumentar la RAM a 16 GB y cambiar a 4 GB, reiniciar Docker, reiniciar todo mi Macbook, nada parece funcionar, excepto intentarlo aleatoriamente una y otra vez, luego ocasionalmente funcionará. Pero la próxima vez que necesite reiniciar o reconstruir un contenedor, el mismo problema :(

También comencé a ver esto con 2.4.0.0 en Mac. La solución para mí es reiniciar la ventana acoplable, pero volveré a encontrarla más tarde.

¡Igual que aquí! Con la actualización a 2.4.0, nuestras configuraciones a veces no comienzan en absoluto con los errores Read timed out. , a veces solo se inician algunos contenedores, otros arrojan este error. ¡Ya estoy pensando en una rebaja!

Solo para mencionar: este problema afecta tanto a las configuraciones que usan recursos compartidos NFS como a los proyectos que usan volúmenes montados "normales"

El mismo problema aquí, también en mac y después de la actualización 2.4.0. Actualmente estoy intentando si la degradación ayuda.

Actualización: la degradación a la versión anterior, la eliminación de la memoria caché y la reconstrucción soluciona el problema.

También comencé a ver este problema recientemente (Mac, 2.4.0.0), cuando nunca lo había visto antes. Ejecutar docker image prune hizo que el problema desapareciera durante un par de días, pero ahora ha vuelto.

También comencé a tener con frecuencia este error de tiempo de espera desde la actualización 2.4.0 (en Mac OS Mojave 10.14.5)

También viendo esto con mayor frecuencia desde la actualización a Docker Desktop 2.4.0.0 (48506) en MacOS Catalina.

Tengo los mismos problemas de tiempos de espera desde 2.4.0.0 en Mac OS. Nunca tuve este problema antes.
Probé el edge build 2.4.1.0 (48583) pero todavía tengo el mismo problema.

Tuve el mismo problema y al reiniciar la ventana acoplable se solucionó para MacOs Catalina (10.15.5) y la versión de la ventana acoplable 2.4.0.0

Lo mismo aquí, no tuve el problema antes de actualizar al escritorio Docker 2.4.0.0.
Reiniciar el escritorio de Docker funciona, pero es solo una solución.

Lo mismo aquí, también comenzando con v2.4.0

Actualización: la degradación a la versión anterior, la eliminación de la memoria caché y la reconstrucción soluciona el problema.

Intentaré eso. Ni siquiera estoy seguro de cómo se hace. ¿Supongo que es desinstalando y descargando una versión anterior?

Sí, desinstalé el 2.4 y descargué / reinstalé el 2.3. Ahora funciona, puedo iniciar mis contenedores como de costumbre.
Obtuve el 2.3 desde allí: https://docs.docker.com/docker-for-mac/release-notes/#docker -desktop-community-2302

Sí, puedo confirmar que también marcó la diferencia para mí. Definitivamente la v2.4 tiene la culpa aquí de alguna manera.

Si encuentra este problema regularmente debido a las lentas condiciones de la red, considere configurar COMPOSE_HTTP_TIMEOUT en un valor más alto (valor actual: 60).

¿Cómo 1Gbps es una red lenta, exactamente?

La degradación también funcionó para mí. Para aquellos que administran Docker a través de Homebrew

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

Si encuentra este problema regularmente debido a las lentas condiciones de la red, considere configurar COMPOSE_HTTP_TIMEOUT en un valor más alto (valor actual: 60).

¿Cómo 1Gbps es una red lenta, exactamente?

En mi caso, esto sucedió debido a una unidad de red montada en NFS.
La causa principal de la velocidad de red "lenta" fue el uso de NFS, no la velocidad del enlace físico.
Pero definitivamente muestra que hay un problema en la implementación y me sorprendería si cambiar HTTP_TIMEOUT lo resuelve.

Igual que aquí. Ralentización significativa en la creación de contenedores, lo que resulta en el error de tiempo de espera HTTP mencionado anteriormente en Docker para Mac v2.4. La configuración de COMPOSE_HTTP_TIMEOUT = 120 funcionó, pero la lentitud en la creación del contenedor sigue siendo un problema nuevo. La degradación a v2.3 también corrige esto.

Puedo confirmar el mismo problema desde que instalé Docker para Mac v2.4.
También puedo confirmar un aumento significativo del consumo de RAM y CPU incluso en momentos de inactividad, solo con el demonio Docker en ejecución. Pero supongo que no tiene nada que ver con el paquete de composición en sí.

Yo tuve el mísmo problema. Desinstalé 2.40 e instalé 2.3 desde el enlace mencionado por @ddesrousseaux y ya no tengo súper lentitud o tiempos de espera con los contenedores de inicio.

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

Este problema todavía existe en Docker v. 2.4.3.0 .

También bajé de 2.4 a 2.3 para solucionar los problemas de lentitud masiva en la versión 2.4. Me complace proporcionar los registros que puedan ser útiles para depurar lo que está sucediendo aquí.

Haciéndome eco de lo anterior, esto comenzó a suceder en 2.4.2.x para mí. Algo cambió en la actualización de 2.3.

Hice algunas pruebas en un entorno Linux y tuve un problema similar. Instalé el último binario docker-compose (v1.27.4) y tuve el mismo problema de tiempo de espera que están informando.

Después de degradar a 1.27.2, el mismo disponible en Docker para Mac 2.3, el problema ha desaparecido.

El mismo problema con la versión actual en Ubuntu 20.04.

Mi problema fue que instalé docker y docker-compose con snap y apt. Los desinstalé, reinicié y luego seguí las instrucciones de instalación oficiales en https://docs.docker.com/engine/install/ubuntu/ y https://docs.docker.com/compose/install/

Sigo experimentando errores frecuentes de tiempo de espera desde la actualización 2.4.0 que aún no se han solucionado en 2.5.0

Sí, lo mismo aquí. Me funcionó bien durante los últimos 2 años. Pero hace 2 meses, de repente, cuando quiero 1 instancia y comenzar otro proyecto de ventana acoplable, arroja:
para apache UnixHTTPConnectionPool (host = 'localhost', port = None): tiempo de lectura agotado.

Reiniciar Docker soluciona el problema. Pero es un verdadero dolor cuando tengo que cambiar entre proyectos varias veces en 1 día

Golpear el mismo problema desde 2.4, 300% de cpu en todo momento, 2.5 no ayudó, bajó de nuevo a 2.3 y todo está bien. Esto en el último macbook con cpu i7 y 32g de ram

Acabo de actualizar a la última versión de Docker para Mac (v2.5.0.1) y el problema parece estar resuelto.
No más UnixHTTPConnection error y no más uso de CPU al 100%.

No estoy seguro de si alguien más puede confirmarlo.

¿Cómo conseguiste eso? Abrir Docker en Mac y hacer "Buscar actualizaciones" todavía dice que tengo el último, 2.4.2.0.

Acabo de actualizar a la última versión de Docker para Mac (v2.5.0.1) y el problema parece estar resuelto.
No más UnixHTTPConnection error y no más uso de CPU al 100%.

No estoy seguro de si alguien más puede confirmarlo.

Acabo de experimentar el problema en v2.5.0.1. El reinicio de la ventana acoplable parece resolver (al menos temporalmente) el problema.

¿Cómo conseguiste eso? Abrir Docker en Mac y hacer "Buscar actualizaciones" todavía dice que tengo el último, 2.4.2.0.

No puedo mostrarle ninguna captura de pantalla porque ya me actualicé, pero creo que es posible que tenga algunos problemas para obtener actualizaciones de su computadora, ya que ha habido una versión anterior v2.5.0 disponible durante más de una semana.

Puede verificarlo en las notas de la versión de Docker para Mac (y obtener cualquier instalador nuevo desde allí).

Estoy ejecutando Edge. Eso probablemente lo explica.

Puede confirmar que la v2.5.0.1 es al menos ligeramente mejor. Ya no tengo tiempos de espera en cada arranque y aún no lo he encontrado desde que se actualizó esta mañana. Sin embargo, el tiempo de arranque del contenedor todavía parece mucho más lento que el de 2.3.

Editar: acabo de encontrar los errores de tiempo de espera nuevamente, después de aproximadamente 4 o 5 reinicios de mi proyecto de composición de docker. También encontré un nuevo error con 2.5.0.1: Cannot start service <container name>: error while creating mount source path <local mount path>: mkdir <local mount path>: file exists

Puede confirmar que la v2.5.0.1 es al menos ligeramente mejor. Ya no tengo tiempos de espera en cada arranque y aún no lo he encontrado desde que se actualizó esta mañana. Sin embargo, el tiempo de arranque del contenedor todavía parece mucho más lento que el de 2.3.

Editar: acabo de encontrar los errores de tiempo de espera nuevamente, después de aproximadamente 4 o 5 reinicios de mi proyecto de composición de docker. También encontré un nuevo error con 2.5.0.1: Cannot start service <container name>: error while creating mount source path <local mount path>: mkdir <local mount path>: file exists

Bien, todavía tengo algunos problemas con la versión 2.5.0.1. El uso de la CPU sigue siendo demasiado alto en comparación con v2.3.x, y la velocidad también es bastante lenta.

¿Alguien del equipo de Docker puede reconocer y opinar sobre esto?

Dios, pasaron 4 años, este tema aún no se resuelve, y me pasa todo el tiempo