Compose: UnixHTTPConnectionPool (host = 'localhost', port = None): la lecture a expiré. (délai de lecture = 60)

essayé ça

export DOCKER_CLIENT_TIMEOUT=120
export COMPOSE_HTTP_TIMEOUT=120

et cela semble résoudre le problème pour le moment

Autres solutions mentionnées dans ce fil:

• Redémarrez Docker
• Augmenter le CPU et la mémoire Docker

Cela se produit-il si vous désactivez votre WiFi? Pourrait être lié à https://github.com/docker/docker-py/issues/1076.

Une autre théorie, si votre service a tty: True activé, pourrait être # 3106

Je vois exactement le même problème avec la dernière version bêta pour Mac. Même erreur si j'exécute docker-compose create

Cela pourrait-il être lié au fait d'avoir un très grand calque dans l'image? (une opération npm install très longue qui prend environ une minute pour être aplatie dans un calque lorsque le docker crée l'image)

Nous constatons également ce problème en utilisant un fichier de composition de docker avec 6 conteneurs [docker-compose version 1.8.1, build 878cff1] sur Windows et Mac [Version 1.12.2-rc1-beta27 (build: 12496)
179c18cae7]

L'augmentation des ressources disponibles pour docker semble réduire le risque que cela se produise (tout comme l'extension du délai d'expiration des variables), mais ce n'est jamais éliminé.

Nous avons également des couches volumineuses (240 Mo est la plus grande, la commande principale d'installation du package) et nous nous attachons à un répertoire hôte avec 120 Mo de fichiers dans quelques conteneurs.

À partir de différentes tentatives pour contourner ce problème, j'ai trouvé quelque chose qui pourrait faire la lumière sur une solution possible:

Au début, mon scénario ressemblait un peu à ceci:

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

Mon chemin monté comprenait de nombreux répertoires avec de gros fichiers statiques dont je n'avais pas vraiment besoin pour le rechargement du code. J'ai donc fini par échanger pour quelque chose comme ça:

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

Cela a laissé hors de l'exécution de montage tous mes gros fichiers statiques, qui ont fait plus rapidement la voie de démarrage du service.

Ce que je comprends de cela, c'est que plus vous montez de fichiers, en particulier plus ils sont volumineux (images dans les Mo au lieu des fichiers source dans les Bs / KB), les temps de chargement augmentent beaucoup.

J'espère que cela t'aides

+1
Je vois ce problème de délai d'expiration chaque semaine, généralement après un week-end d'inactivité, alors que j'essayais de me connecter à des conteneurs, il a expiré ...
Je dois terminer le proc docker en cours d'exécution et le redémarrer pour contourner ...

+1
Cela m'arrive à chaque fois que j'essaye de redémarrer les conteneurs car ils ne répondent plus après une journée. Je ne sais pas si mon cas a à voir avec le montage puisque j'essaye d'arrêter les conteneurs.

Arriver avec un nginx conatiner, Up 47 hours .
Docker pour 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).

Merci @gvilarino , je pense que le montage de gros fichiers est la cause de ce problème sur mon serveur Linux. Votre extrait de code peut être une solution de contournement si les gros fichiers ne sont pas nécessaires dans le conteneur.

Cependant, je me demande pourquoi le montage est lent dans Docker? Peut-être que cela déclenche la copie du disque? Mais pourquoi?

@cherrot Je ne dirais pas que je suis extrêmement compétent sur le sujet, mais je pense que cela a à voir avec le pilote de stockage utilisé par Docker et comment il fonctionne en interne pour garder les couches en ordre. Utilisez docker info pour voir quel pilote de stockage votre démon utilise (probablement aufs , qui est le plus lent) et en fonction de votre système d'exploitation hôte, vous pouvez le changer pour autre chose ( overlay étant un meilleur choix, s'il est pris en charge). Il existe des alternatives plus rapides comme LCFS, mais elles ne sont pas prises en charge commercialement par Docker, vous serez donc seul.

Nous assistons également à ce temps mort. Cela semble également dû aux volumes que nous utilisons.

Nous avons besoin de certains conteneurs pour accéder à certains partages réseau SMB. Nous avons donc monté ces partages sur le système hôte et les avons montés en liaison à l'intérieur du conteneur. Mais parfois, la communication entre le serveur Windows et notre hôte Linux est bloquée (voir https://access.redhat.com/solutions/1360683) et cela bloque le démarrage ou l'arrêt de notre conteneur qui expire juste après un certain temps.

Je n'ai pas encore de solution. Je recherche un plugin de volume prenant en charge SMB, ou pour faire disparaître le problème de communication de décrochage sur SMB. mais pas encore de vraie solution.

FWIW: Pour les personnes qui atterrissent ici via le moteur de recherche trouvant leur résolution, j'ai été en mesure de résoudre ce problème simplement par la méthode _avez-vous essayé de l'éteindre et de la réactiver? _; J'ai redémarré mon client Docker Mac OS.

+1 à ce sujet, j'exécute des tests de résistance sur mon instance qui exécute 4 conteneurs et le docker se bloque même pour docker ps -a donc j'essaye de redémarrer les conteneurs mais je reçois
UnixHTTPConnectionPool(host='localhost', port=None): Read timed out et

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)

Seulement si je redémarre le service docker , il semble être résolu, des idées?

+1

`Redémarrage de web-jenkins_jenkins_1 ...

ERREUR: for web-jenkins_jenkins_1 UnixHTTPConnectionPool (host = 'localhost', port = None): la lecture a expiré. (timeout de lecture = 130)
ERREUR: une requête HTTP a pris trop de temps à se terminer. Réessayez avec --verbose pour obtenir des informations de débogage.
Si vous rencontrez régulièrement ce problème en raison de conditions de réseau lentes, envisagez de définir COMPOSE_HTTP_TIMEOUT sur une valeur plus élevée (valeur actuelle: 120).

je redémarre docker, il est résolu. mais chaque jour j'ai besoin de redémarrer

le redémarrage de Docker fonctionne pour moi.

Le redémarrage de +1 docker a également fonctionné pour moi.

J'ai rencontré ce problème lors de la création d'une image Docker considérablement volumineuse, puis en tentant de la pousser vers un registre distant. Le redémarrage de Docker n'était pas une solution applicable, mais la réponse de @bodaz l'a résolu pour moi: https://github.com/docker/compose/issues/3927#issuecomment -245948736

@ rodrigo-brito - J'obtiens cette erreur depuis un petit moment maintenant et le redémarrage de docker deamon a résolu le problème - pas plus depuis que j'ai ajouté un autre service à mon projet.

J'ai le même problème, mais j'ai une configuration assez simple.
Je n'ai qu'un seul conteneur verdaccio 3 basé sur une image d'une taille de 164 Mo.
C'est très décevant: /

J'utilise un MBP Pro 13 à partir de 2015

Cela m'est arrivé à cause d'une large plage de ports, cela crée en fait une règle par port ...

Un simple sudo service docker restart résout cela pour moi de manière cohérente chaque fois que cela se produit.

Cela m'est également arrivé, dans mon cas docker-compose push (sans même essayer d'exécuter l'application) sur Azure DevOps.

Mes autres builds n'utilisent pas docker-compose mais plain docker push

J'ai supprimé la version kubuntu 18.04.1 docker.io de docker et installé docker-ce 18.09.0
Le problème est parti.

Je viens de convertir l'étape push docker-compose en pushs individuels à la place.

Nous voyons ce délai d'expiration lors de l'exécution d'un conteneur via docker-compose ou via la bibliothèque docker-py (expire même après que nous ayons repoussé le délai à 2 minutes); cependant, nous ne voyons pas l'erreur lorsque nous exécutons via la CLI Docker (le conteneur démarre instantanément). Nous ne voyons également le problème que sur un serveur Linux CI et non sur nos Mac. Nous travaillons à la construction d'un exemple minimal reproductible.

Ayant ce problème avec un docker-compose kill sur une machine virtuelle Debian sur un hôte macos, installez directement à partir du docker. (Docker version 18.09.0, build 4d60db4)

J'ai eu la même erreur lors du démarrage de docker avec log-driver: syslog lorsque le port rsyslog n'était pas disponible.
Error starting container 0ba2fb9540ec6680001f90dce56ae3a04b831c8146357efaab79d4756253ec8b: UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)

le redémarrage de Docker fonctionne pour moi.

@ rodrigo-brito redémarrer n'est pas une solution ...

Cela m'est arrivé à cause d'une large plage de ports, cela crée en fait une règle par port ...

Exactement la même chose pour moi. Après l'erreur, le démon docker continue de consommer de la mémoire jusqu'à épuisement. J'ai besoin de systemctl stop docker avant que mon système ne meure. (Docker version 18.09.3, build 774a1f4)

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

un simple redémarrage de docker a résolu cela pour moi ...

Il semble que le problème soit toujours présent dans les versions récentes de docker-ce. Je commence ~ 5 conteneurs, le lent ayant un montage de volume docker qui pointe vers un partage NFS. Aucun conteneur n'expose de port, quelqu'un a-t-il découvert s'il s'agissait d'une erreur valide ( port=None semble suspect)?

~~~
Client:
La dernière version: 18.09.5
Version de l'API: 1.39
Version Go: go1.10.8
Commit Git: e8ff056dbc
Construit: jeu 11 avril 04:44:28 2019
OS / Arch: linux / amd64
Expérimental: faux

Serveur: Docker Engine - Communauté
Moteur:
La dernière version: 18.09.5
Version de l'API: 1.39 (version minimale 1.12)
Version Go: go1.10.8
Commit Git: e8ff056
Construit: jeu 11 avril 04:10:53 2019
OS / Arch: linux / amd64
Expérimental: faux
~~~

Ajout d'un peu plus de sortie de --verbose . Je ne pense pas qu'il y ait quoi que ce soit d'utile ici, cela dit simplement pendant longtemps qu'une opération de création de conteneur attend depuis longtemps. Apparemment, il utilise l'interrogation, car le message suivant est imprimé environ 1x / s:

~compose.parallel.feed_queue: En attente: set ()~

Le localhost / port = Node est un peu un hareng rouge je pense, car la connexion est établie avec docker.sock, donc ce n'est pas une erreur nulle cachée quelque part. Je pense que cela devra être retrouvé à l'intérieur de docker, et non pas que la gestion de cette requête par docker-compose soit optimale.

Docker-compose semble manquer une sorte d'identifiant de demande qui pourrait être journalisé, nous saurions donc quelle demande est bloquée. Par exemple, je sais que mon conteneur api n'a pas pu être créé dans le délai imparti, mais le journal des demandes n'aide pas du tout. Peut-être que quelqu'un d'autre peut ajouter quelques informations ici:

~~~
urllib3.connectionpool._make_request: http: // localhost: Aucun "POST /v1.25/containers/create?name=api-memcache HTTP / 1.1" 201 90
urllib3.connectionpool._make_request: http: // localhost: Aucun "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: docker create_container -> {'Id': '22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f',
'Avertissements': Aucun}
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network -> Aucun
compose.cli.verbose_proxy.proxy_callable: docker inspect_container <- ('22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f')
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network <- ('ba67095c5ea718af13a09798bc2f5ab24f5d0b54ce684b6f4cb248ab705df900', 'proxy', alias_address, 'ip4_address,' ip_address '= [' redis_address ',' ip_address ',' ip_address '= [' redis_address '', 'ip_address', 'ip_address' '= [' redis_address '' = 'ip_address']
urllib3.connectionpool._make_request: http: // localhost: None "GET /v1.25/containers/22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f/json HTTP / 1.1" 200 Aucun
urllib3.connectionpool._make_request: http: // localhost: Aucun "POST /v1.25/containers/create?name=api HTTP / 1.1" 201 90
compose.cli.verbose_proxy.proxy_callable: docker create_container -> {'Id': '1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec',
'Avertissements': Aucun}
compose.cli.verbose_proxy.proxy_callable: docker inspect_container <- ('1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec')
compose.parallel.feed_queue: En attente: set ()
urllib3.connectionpool._make_request: http: // localhost: Aucun "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
urllib3.connectionpool._make_request: http: // localhost: Aucun "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 Aucun
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network -> Aucun
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network -> Aucun
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', alias_network ']
compose.cli.verbose_proxy.proxy_callable: docker inspect_container -> JSON ...
urllib3.connectionpool._make_request: http: // localhost : Aucun "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: En attente: set ()
compose.parallel.feed_queue: En attente: 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',
'Avertissements': Aucun}
urllib3.connectionpool._make_request: http: // localhost : Aucun "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
urllib3.connectionpool._make_request: http: // localhost : Aucun "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 -> Aucun
compose.parallel.feed_queue: En attente: set ()
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network -> Aucun
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network <- ( '22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f', 'proxy', alias = [ 'memcache', '22b774d0451c'] = Aucun, adresse_IPv4, ipv6_address = Aucun, liens = [], link_local_ips = None)
compose.parallel.feed_queue: En attente: set ()
urllib3.connectionpool._make_request: http: // localhost : None "GET /v1.25/containers/ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af/json HTTP / 1.1" 200 Aucun
urllib3.connectionpool._make_request: http: // localhost : Aucun "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: docker start <- ('7d81ef23610f1b8f7ac95837cbf6c9eef977b5b0846fea24be5c7054e471df39')
compose.parallel.feed_queue: En attente: set ()
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network -> Aucun
compose.cli.verbose_proxy.proxy_callable: docker inspect_container -> JSON ...
urllib3.connectionpool._make_request: http: // localhost : Aucun "POST /v1.25/networks/proxy/connect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network <- ('1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec', 'proxy', alias1_address ',' ipb_address ',' proxy ', alias1_address,' ip4_address = ['ipb_address' ',' proxy ', alias1_address', 'ipb_address', 'ip_address, alias1']
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network <- ('ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af', 'proxy')
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network -> Aucun
compose.cli.verbose_proxy.proxy_callable: docker start <- ('22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f')
compose.parallel.feed_queue: En attente: set ()
urllib3.connectionpool._make_request: http: // localhost: Aucun "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
urllib3.connectionpool._make_request: http: // localhost: Aucun "POST /v1.25/networks/proxy/connect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network -> Aucun
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network -> Aucun
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network <- ('ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af', 'proxy', aliasces '] [' ff8_vocal_address, 'ipbress' = ['fcc_address' ',' ipbips_address ',' ip4_address ',' ipb_address ',' ipb_address '= [' ' Aucun)
compose.cli.verbose_proxy.proxy_callable: docker start <- ('1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec')
urllib3.connectionpool._make_request: http: // localhost: Aucun "POST /v1.25/networks/proxy/connect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network -> Aucun
compose.cli.verbose_proxy.proxy_callable: docker start <- ('ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af')
compose.parallel.feed_queue: En attente: set ()
compose.parallel.feed_queue: En attente: set ()
compose.parallel.feed_queue: En attente: set ()
compose.parallel.feed_queue: En attente: set ()
...
- omis ~ 30 lignes
...
Création de commentaires api ... terminé
compose.cli.verbose_proxy.proxy_callable: docker start -> Aucun
compose.parallel.parallel_execute_iter: Traitement terminé: ServiceName (project = 'api', service = 'comments', number = 1)
compose.parallel.feed_queue: En attente: set ()
compose.parallel.parallel_execute_iter: Traitement terminé:
compose.parallel.feed_queue: En attente: set ()
Création de api-memcache ... terminé
urllib3.connectionpool._make_request: http: // localhost: None "POST /v1.25/containers/22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f/start HTTP / 1.1" 204 0
compose.cli.verbose_proxy.proxy_callable: docker start -> Aucun
compose.parallel.parallel_execute_iter: Traitement terminé: ServiceName (project = 'api', service = 'memcache', number = 1)
compose.parallel.feed_queue: En attente: set ()
compose.parallel.parallel_execute_iter: Traitement terminé:
compose.parallel.feed_queue: En attente: set ()
compose.parallel.feed_queue: En attente: set ()
compose.parallel.feed_queue: En attente: set ()
compose.parallel.feed_queue: En attente: 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: docker start -> Aucun
Création de api-comments-db ... terminé
compose.parallel.feed_queue: En attente: set ()
compose.parallel.parallel_execute_iter: Traitement terminé:
compose.parallel.feed_queue: En attente: set ()
compose.parallel.feed_queue: En attente: set ()
compose.parallel.feed_queue: En attente: set ()
compose.parallel.feed_queue: En attente: set ()
compose.parallel.feed_queue: En attente: set ()
- omis ~ 15 lignes
Création de api-redis ... terminé
compose.parallel.feed_queue: En attente: 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: docker start -> Aucun
compose.parallel.parallel_execute_iter: Traitement terminé: ServiceName (project = 'api', service = 'redis', number = 1)
compose.parallel.feed_queue: En attente: set ()
compose.parallel.parallel_execute_iter: Traitement terminé:

compose.parallel.feed_queue: En attente: set ()

- omis plus de 100 lignes
compose.parallel.parallel_execute_iter: Échec: ServiceName (project = 'api', service = 'api', number = 1)
compose.parallel.feed_queue: En attente: set ()

ERREUR: pour l'api UnixHTTPConnectionPool (host = 'localhost', port = None): la lecture a expiré. (délai de lecture = 60)
compose.parallel.parallel_execute_iter: échec:
compose.parallel.feed_queue: En attente: set ()

ERREUR: pour l'api UnixHTTPConnectionPool (host = 'localhost', port = None): la lecture a expiré. (délai de lecture = 60)
compose.cli.errors.log_timeout_error: Une requête HTTP a mis trop de temps à se terminer. Réessayez avec --verbose pour obtenir des informations de débogage.
Si vous rencontrez régulièrement ce problème en raison de conditions de réseau lentes, envisagez de définir COMPOSE_HTTP_TIMEOUT sur une valeur plus élevée (valeur actuelle: 60).
~~~

@titpetric peut confirmer que je rencontre également ce problème.

À mon humble avis, ce problème est du côté docker, pas du côté docker-compose. Quelqu'un devrait activer la journalisation de débogage sur le démon docker et identifier les retards là-bas, et déposer un problème en amont. Je ne suis pas sûr que l'on puisse reproduire cela facilement sans cela.

Si quelqu'un est prêt à mettre du temps, je suggérerais de reproduire cela en créant un dossier entièrement chargé pour un montage de volume (quelque chose avec environ 100000 fichiers / dossiers devrait faire), pour voir si une reproduction fiable du problème peut être atteint. Il est probable que le démon docker, ou le montage de liaison du noyau lui-même, met en cache au préalable certaines des données d'inode. Ce qui ... est malheureux.

Un tcpdump peut également confirmer cela dans le cas d'un système de fichiers réseau (samba, nfs).

Même erreur exacte ici

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)

Le redémarrage de Docker l'a également corrigé pour moi.

Redémarrer n'est pas une solution les gars .....
Comment éviter cela pour de bon?

Face au même problème. Obtenir une erreur ci-dessous pour tous les conteneurs Docker des homologues de l'organisation:

ERREUR: pour DNS UnixHTTPConnectionPool (host = 'localhost', port = None): la lecture a expiré. (délai de lecture = 60)

Est-ce à cause d'une incompatibilité de port ou d'une affectation dans le fichier de composition?

Oui, je rencontre constamment ce problème moi-même. Je suis d'accord que le redémarrage n'est pas une solution, mais rien d'autre ne semble faire l'affaire: /

Juste un FYI, avec mon cas, seule une nouvelle tentative avec docker-compose a tendance à se résoudre
il. Je ne pense pas avoir redémarré dockerd, ce problème ne persiste pas pendant
moi.

Le vendredi 2 août 2019 à 13 h 39, Alex [email protected] a écrit:

Oui, je rencontre constamment ce problème moi-même. Je suis d'accord que le redémarrage n'est pas
une solution, mais rien d'autre ne semble faire l'affaire: /

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/docker/compose/issues/3927?email_source=notifications&email_token=AABY7EH4MVKGI56ZLEIUV5TQCQMHBA5CNFSM4CPDX2D2YY3PNVWWK3TUL52HS4MVKGI56ZLEIUV5TQCQMHBA5CNFSM4CPDX2D2YY3PNVWWK3TUL52HS4DFVom
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AABY7EA3NTUP5SNZRTFWFEDQCQMHBANCNFSM4CPDX2DQ
.

Je suis également confronté à ce problème :(
UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)

Même problème ici, le redémarrage de Docker se bloque également. Le seul moyen est de tuer Docker / ou de redémarrer mais cela ne peut pas être la solution.

@bitbrain yup cela m'est arrivé aussi depuis un certain temps.

J'ai trouvé une solution intéressante à cela (sur MacOS)

La raison pour laquelle cela n'arrêtait pas de m'arriver était que Docker avait trop peu de mémoire disponible.

L'augmentation de la mémoire de 2 Go à 8 Go a résolu le problème pour moi.

J'obtenais cette erreur après avoir exécuté docker-compose up puis docker-compose down plusieurs fois. J'ai tout essayé dans ce fil. Bumping les ressources, redémarrer mon mac et réinstaller le dernier Docker. Je pourrais faire redémarrer docker-compose up après avoir redémarré ma boîte, mais après avoir cyclé ces commandes plusieurs fois, cela reviendrait à cette erreur et je ne pouvais pas exécuter docker-compose up .

Mon problème semble avoir été un conflit avec un autre service ( pow ) qui était lié au port 80 alors qu'un de mes conteneurs était également lié au port 80. J'ai désinstallé pow et je n'ai pas eu de problème depuis trois jours maintenant.

3 ans ouvrent ce ticket et toujours non résolus. Le problème persiste même si nous augmentons la connexion client à 120 sec.

vient d'arriver sur notre serveur, problème ouvert depuis 2016, wtf

le redémarrage de Docker fonctionne pour moi.

@ rodrigo-brito redémarrer n'est pas une solution ...

mon homme.

Également expérimenté cela maintenant. Sauvage.

Avoir le même problème lorsque vous essayez docker-compose up ou docker-compose down. Je l'ai résolu en arrêtant le service mysqld et une fois que le conteneur est en place, je lance mysql. La RAM est à 20% d'utilisation.

Exécution de Docker Desktop Community pour Mac v2.1.0.5

J'ai rencontré ce problème et je l'ai résolu en augmentant la quantité de mémoire allouée à Docker (et en diminuant la quantité de processeurs).
Vous pouvez le faire dans Docker -> Préférences -> Avancé.
Je suis passé de 8 processeurs et 2 Go de RAM à 4 processeurs et 16 Go de RAM pour ma configuration particulière.

Ran dans ce problème sur Ubuntu Server 18.04 LTS. Le redémarrage de docker ne résout pas le problème, de même que la définition des variables d'environnement. Des idées?

@bpogodzinski avez-vous essayé d'augmenter vos paramètres de mémoire dans Docker? Je les ai augmentés de 2 Go à 8 Go et cela a résolu le problème pour moi.

De manière générale, ce problème semble se produire lorsque les conteneurs nécessitent plus de mémoire que la mémoire disponible configurée dans Docker, puis que tout se bloque.

Nous avons eu ce problème et il semble (pour nous) être lié à un volume nommé avec beaucoup de fichiers. Je ne le comprends pas, mais c'est le cas pour nous qu'un docker-compose (édité par souci de concision) qui a un service:

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

   volumes:
       - serviceA_volume:

À l'intérieur du Dockerfile for serviceA se trouve la commande apparemment inoffensive et inefficace:

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

Notez que cela change récursivement le propriétaire dans le dossier / srvA / qui dans le volume nommé est un système de fichiers volumineux avec 100K de fichiers. Cependant, cela se produit lorsque l'image est créée et que ce dossier est vide. Il apparaît que l'utilisation du volume nommé hérite des autorisations du fichier d'image local, puis procède à la modification des autorisations des volumes nommés.

C'est plutôt un avantage et probablement pas le même problème que tout le monde a, mais c'était notre problème (basculer la ligne bascule l'erreur). Le résultat est que ce délai d'attente http est probablement dû à plusieurs causes.

Le redémarrage de docker n'a jamais résolu le problème dans mon cas, l'augmentation des ressources l'a définitivement fait.

D'après mon expérience, ce problème survient souvent sur de petites instances de cloud où la quantité de RAM est parfaitement adaptée au fonctionnement normal mais s'avère insuffisante lors des opérations de docker ou de docker-compose. Vous pourriez facilement augmenter la RAM, mais cela augmenterait probablement considérablement le coût d'une petite VM.

Dans chaque cas, l'ajout d'une partition d'échange ou même d'un fichier d'échange a résolu ce problème pour moi!

Je viens de me passer sur un Raspberry Pi. Pas de volume avec une énorme quantité de fichiers ou quoi que ce soit.
En fait, je crée ces conteneurs sur cette framboise depuis un moment maintenant (un an ou deux lol).
Je ne sais pas ce qui a changé.
Semble un peu "à l'improviste".

Le problème apparaît toujours sur le bureau Docker 2.2.0.3 sur MacOs 🙁

J'ai résolu mon problème avec les commandes suivantes:
docker volume prune
docker system prune
(une seule de ces commandes peut suffire, mais ne peut pas se reproduire pour le moment ...)

J'ai résolu mon problème avec les commandes suivantes:
docker volume prune
docker system prune
(une seule de ces commandes peut suffire, mais ne peut pas se reproduire pour le moment ...)

La solution de @amaumont a aidé, même si je pense que cela continuerait de revenir au
Comme tout le monde l'a dit, redémarrer docker n'est pas une bonne solution, c'est un pansement.

Nous rencontrons également plusieurs problèmes avec docker-compose.

Après avoir défini MaxSessions 500 dans sshd_config (voir # 6463), nous obtenons également des délais de lecture.
La définition des deux délais d'expiration à 120 secondes a résolu le problème pour la prochaine exécution DOCKER_HOST=xxx<strong i="8">@yyy</strong> docker-compose up -d .

Au cours de la deuxième exécution, la charge de la machine a 30 (sic!) Avant que la commande docker-compose échoue en raison de délais d'attente. Un redémarrage du docker ne résout pas ce problème, même temporairement.
Le serveur est une instance AWS EC2 avec suffisamment de CPU / disque / NetIO, etc., le fichier de composition comprend 1 traefik et 3 services avec mailhog, donc rien de spécial ici. L'exécution de docker-compose up -d avec le même fichier docker-compose.yml directement sur le serveur fonctionne de manière fiable et comme prévu.
L'exécution avec --verbose montre plus de mille lignes consécutives contenant compose.parallel.feed_queue: Pending: set() .

Je vais essayer de resynchroniser le fichier docker-compose sur le serveur distant et d'exécuter docker-compose directement sur cette machine comme solution de contournement.

Pour moi, cela m'a aidé de simplement redémarrer docker.

Cela me arrive assez souvent lorsque j'essaie de pousser vers mon registre privé à partir de pipelines bitbucket. Fonctionne bien lorsque vous poussez à partir d'un PC local.
Le redémarrage de docker peut aider pendant un certain temps, mais ce "while" dure 10 min max: c

upd. définir DOCKER_CLIENT_TIMEOUT et COMPOSE_HTTP_TIMEOUT semblé aider, mais je ne sais pas pendant combien de temps

J'ai commencé à les obtenir depuis le passage à Docker Edge avec la mise en cache activée

Cela se produit assez régulièrement pour moi depuis que j'ai commencé à utiliser Docker il y a 2-3 ans. Après qu'un conteneur a fonctionné pendant un certain temps, il devient un zombie et l'ensemble du moteur Docker doit être redémarré pour que les choses redeviennent réactives. Cela ressemble à une fuite de ressources, car le temps d'inactivité semble être très pertinent pour le comportement expérimenté.

Si aucun conteneur n'est en cours d'exécution ou s'ils ne fonctionnent que pendant une courte période, tout semble fonctionner correctement pendant des jours ou des semaines. Mais dès que je laisse un conteneur fonctionner pendant quelques heures, il ne répond plus, je dois l'arrêter de force dans la ligne de commande et toute tentative de communication avec docker ou docker-compose échoue tout simplement avec un timeout. Un redémarrage est la seule solution qui fonctionne.

Sortie 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

Sortie 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

Sortie 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.

J'ai rencontré le même problème, même si j'ai augmenté les ressources de 4 Go de RAM, 1 Go de swap à 6 Go de RAM, 2 Go de swap.

Je suis également confronté au même problème

ayant également le même problème

J'ai été confronté au même problème sur Ubuntu 18.04 LTS (8 Go de RAM) en utilisant HTTPS.

Je peux générer des conteneurs avec docker-compose up , mais une fois déployé, je ne peux pas arrêter les conteneurs avec docker-compose down . Le redémarrage du démon docker ou le redémarrage de la machine virtuelle se sont avérés inefficaces. L'ajout de variables d'environnement de délai d'expiration ( DOCKER_CLIENT_TIMEOUT , COMPOSE_HTTP_TIMEOUT ) n'a également rien fait.

Je suis capable d'interagir avec et d'arrêter les conteneurs individuellement, je peux inspecter les conteneurs, y attacher et n'importe quoi d'autre, mais je ne peux pas les arrêter ou les tuer en utilisant la commande docker-compose .

Le message d'erreur est toujours le même:

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

J'avais le même problème lorsque j'avais ce qui suit dans mon docker-compose.yml:

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

L'erreur a disparu lorsque j'ai ajouté des citations autour de "10". Ceci est indiqué dans la documentation que les valeurs pour max-file et max-size doivent être une chaîne, mais toujours. Le message d'erreur est assez trompeur.

J'avais le même problème lorsque j'avais ce qui suit dans mon docker-compose.yml:

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

L'erreur a disparu lorsque j'ai ajouté des citations autour de "10". Ceci est indiqué dans la documentation que les valeurs pour max-file et max-size doivent être une chaîne, mais toujours. Le message d'erreur est assez trompeur.

Vous sauvez ma journée. Merci beaucoup!

J'avais le même problème lorsque j'avais ce qui suit dans mon docker-compose.yml:

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

L'erreur a disparu lorsque j'ai ajouté des citations autour de "10". Ceci est indiqué dans la documentation que les valeurs pour max-file et max-size doivent être une chaîne, mais toujours. Le message d'erreur est assez trompeur.

Je configure le pilote de journalisation au niveau du démon docker. J'utilise fluentd comme pilote de journalisation, donc malheureusement ce correctif ne fonctionnera pas pour moi. = /

essayé ça

export DOCKER_CLIENT_TIMEOUT=120
export COMPOSE_HTTP_TIMEOUT=120

et cela semble résoudre le problème pour le moment

Autres solutions mentionnées dans ce fil:

• Redémarrez Docker
• Augmenter le CPU et la mémoire Docker

Eh bien, rien n'a fonctionné pour moi, sauf l'option de délai d'attente, bravo à vous.

J'obtiens cela depuis que j'ai commencé à utiliser un répertoire monté NFS dans l'un de mes conteneurs. Ce répertoire monté NFS se trouve sur une liaison lente (dans un emplacement distant disposant d'une connexion à faible bande passante). Est-ce que cela pourrait être le problème?

Je rencontre cela très fréquemment sur Mac, Docker 2.4.0.0, dans deux projets différents avec différentes configurations docker-compose.yml. Je ne me souviens pas que cela se soit déjà produit il y a environ une semaine, c'est-à-dire lorsque j'ai mis à niveau vers la version 2.4.0.0. Y a-t-il une régression?

J'ai essayé d'augmenter le délai d'expiration à 600, d'augmenter la RAM à 16 Go et de passer à 4 Go, de redémarrer Docker, de redémarrer tout mon Macbook, rien ne semble fonctionner, sauf essayer au hasard encore et encore, puis cela fonctionnera occasionnellement. Mais la prochaine fois que j'ai besoin de redémarrer ou de reconstruire un conteneur, même problème :(

J'ai commencé à voir cela avec 2.4.0.0 sur Mac également. La solution de contournement pour moi consiste à redémarrer le docker, mais je l'exécuterai à nouveau plus tard.

Pareil ici! Avec la mise à jour vers 2.4.0, nos configurations ne démarrent parfois pas du tout avec les erreurs Read timed out. mentionnées, parfois seuls certains conteneurs démarrent, d'autres lancent cette erreur. Je pense déjà à un déclassement!

Juste pour mentionner: ce problème affecte à la fois les configurations utilisant des partages NFS ainsi que les projets utilisant des volumes montés «normaux»

Même problème ici, également sur mac et après la mise à jour 2.4.0. J'essaie actuellement si la rétrogradation aide.

Mise à jour: la mise à niveau vers la version précédente, la suppression du cache et la reconstruction corrigent le problème.

J'ai également récemment commencé à voir ce problème (Mac, 2.4.0.0), alors que je ne l'avais jamais vu auparavant. L'exécution de docker image prune fait disparaître le problème pendant quelques jours, mais il est maintenant de retour.

Également commencé à avoir fréquemment cette erreur de délai d'expiration depuis la mise à jour 2.4.0 (sur Mac OS Mojave 10.14.5)

Voir également cela avec une fréquence accrue depuis la mise à jour vers Docker Desktop 2.4.0.0 (48506) sur MacOS Catalina.

J'obtiens les mêmes problèmes de délai d'expiration depuis 2.4.0.0 sur Mac OS. Je n'ai jamais eu ce problème auparavant.
J'ai essayé la version Edge 2.4.1.0 (48583) mais j'ai toujours le même problème.

J'ai eu le même problème et le redémarrage du docker l'a corrigé pour MacOs Catalina (10.15.5) et la version 2.4.0.0 du docker

Même chose ici, je n'ai pas eu de problème avant la mise à jour vers Docker Desktop 2.4.0.0.
Le redémarrage du bureau Docker fonctionne, mais ce n'est qu'une solution de contournement.

Idem ici, à partir de la v2.4.0

Mise à jour: la mise à niveau vers la version précédente, la suppression du cache et la reconstruction corrigent le problème.

J'essaierai ça. Je ne sais même pas comment c'est fait. Je suppose que c'est en désinstallant et en téléchargeant une version antérieure?

Oui, j'ai désinstallé le 2.4 et téléchargé / réinstallé le 2.3. Maintenant ça marche, je peux démarrer mes conteneurs comme d'habitude.
J'ai obtenu le 2.3 à partir de là: https://docs.docker.com/docker-for-mac/release-notes/#docker -desktop-community-2302

Oui, je peux confirmer que cela a fait la différence pour moi aussi. La v2.4 est certainement à blâmer ici d'une manière ou d'une autre.

Si vous rencontrez régulièrement ce problème en raison de conditions de réseau lentes, envisagez de définir COMPOSE_HTTP_TIMEOUT sur une valeur plus élevée (valeur actuelle: 60).

Comment 1 Gbps est un réseau lent, exactement?

Le déclassement a fonctionné pour moi aussi. Pour ceux qui gèrent Docker via Homebrew

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

Si vous rencontrez régulièrement ce problème en raison de conditions de réseau lentes, envisagez de définir COMPOSE_HTTP_TIMEOUT sur une valeur plus élevée (valeur actuelle: 60).

Comment 1 Gbps est un réseau lent, exactement?

Dans mon cas, cela s'est produit en raison d'un lecteur réseau monté sur NFS.
La cause première de la vitesse du réseau "lente" était l'utilisation de NFS et non la vitesse de liaison physique.
Mais cela montre clairement qu'il y a un problème dans l'implémentation et je serais surpris si changer HTTP_TIMEOUT le résoudra.

Pareil ici. Ralentissement important de la création de conteneurs, entraînant l'erreur d'expiration HTTP mentionnée ci-dessus sur Docker pour Mac v2.4. La définition de COMPOSE_HTTP_TIMEOUT = 120 a fonctionné, mais la lenteur de création du conteneur est toujours un nouveau problème. La mise à niveau vers la v2.3 résout également ce problème.

Je peux confirmer le même problème depuis que j'ai installé sur Docker pour Mac v2.4.
Je peux également confirmer une augmentation significative de la consommation de RAM et de processeur même dans les moments d'inactivité, juste avec le démon Docker en cours d'exécution. Mais je suppose que cela n'a rien à voir avec le package de composition lui-même.

J'ai eu le même problème. Désinstallé 2.40 et installé 2.3 à partir du lien mentionné par @ddesrousseaux et je n'ai plus de super lenteur ni de délais avec les conteneurs de départ.

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

Ce problème existe toujours dans Docker v. 2.4.3.0 .

J'ai également rétrogradé à 2.3 de 2.4 pour contourner les problèmes de lenteur énormes dans la version 2.4. Heureux de fournir tous les journaux qui pourraient être utiles pour déboguer ce qui se passe ici.

Faisant écho à ce qui précède, cela a commencé à se produire dans 2.4.2.x pour moi. Quelque chose a changé dans la mise à jour de la version 2.3.

J'ai fait des tests dans un environnement Linux et j'ai eu un problème similaire. J'ai installé le dernier binaire docker-compose (v1.27.4) et j'ai eu le même problème de timeout que vous signalez.

Après le passage à la version 1.27.2, le même disponible dans Docker pour Mac 2.3, le problème a disparu.

Même problème avec la version actuelle sur Ubuntu 20.04.

Mon problème était que j'avais installé docker et docker-compose avec snap et apt. Je les ai désinstallés, redémarrés, puis suivi les instructions d'installation officielles sur https://docs.docker.com/engine/install/ubuntu/ et https://docs.docker.com/compose/install/

Je rencontre encore fréquemment des erreurs de temporisation depuis la mise à jour 2.4.0 qui ne sont toujours pas corrigées dans 2.5.0

Ouais, pareil ici. Cela fonctionnait bien pour moi depuis 2 ans. Mais il y a 2 mois, tout à coup, quand je veux 1 instance et démarrer un autre projet docker qu'il lance:
pour apache UnixHTTPConnectionPool (host = 'localhost', port = None): la lecture a expiré.

Le redémarrage de Docker résout le problème. Mais c'est vraiment pénible quand je dois basculer entre les projets plusieurs fois en 1 jour

Frapper le même problème depuis 2.4, 300% CPU à tout moment, 2.5 n'a pas aidé, rétrogradé à 2.3 et tout va bien. Ceci sur le dernier macbook w / i7 cpu et 32g de ram

Je viens de passer à la dernière version de Docker pour Mac (v2.5.0.1) et le problème semble être résolu.
Plus d'erreur UnixHTTPConnection , et plus d'utilisation du processeur à 100%.

Je ne sais pas si quelqu'un d'autre peut le confirmer.

Comment as-tu eu ça? Ouvrir Docker sur Mac et faire "Vérifier les mises à jour" indique toujours que j'ai la dernière version 2.4.2.0.

Je viens de passer à la dernière version de Docker pour Mac (v2.5.0.1) et le problème semble être résolu.
Plus d'erreur UnixHTTPConnection , et plus d'utilisation du processeur à 100%.

Je ne sais pas si quelqu'un d'autre peut le confirmer.

Je viens de rencontrer le problème sur v2.5.0.1. Le redémarrage de docker semble (au moins temporairement) résoudre le problème.

Comment as-tu eu ça? Ouvrir Docker sur Mac et faire "Vérifier les mises à jour" indique toujours que j'ai la dernière version 2.4.2.0.

Je ne peux pas vous montrer de capture d'écran car j'ai déjà mis à niveau, mais je pense que vous pourriez avoir du mal à obtenir les mises à jour de votre ordinateur, car une version précédente v2.5.0 est disponible depuis plus d'une semaine.

Vous pouvez le vérifier dans les notes de version de Docker pour Mac (et récupérer tout nouveau programme d'installation à partir de là).

Je cours Edge. Cela explique probablement cela.

Peut confirmer que la v2.5.0.1 est au moins légèrement meilleure. Ne plus avoir de délais à chaque démarrage, et je ne l'ai pas encore rencontré depuis la mise à jour ce matin. Cependant, le temps de démarrage du conteneur semble encore beaucoup plus lent que 2.3.

Edit: vient de rencontrer à nouveau les erreurs de temporisation, après environ 4 ou 5 redémarrages de mon projet docker-compose. Également rencontré une nouvelle erreur avec 2.5.0.1: Cannot start service <container name>: error while creating mount source path <local mount path>: mkdir <local mount path>: file exists

Peut confirmer que la v2.5.0.1 est au moins légèrement meilleure. Ne plus avoir de délais à chaque démarrage, et je ne l'ai pas encore rencontré depuis la mise à jour ce matin. Cependant, le temps de démarrage du conteneur semble encore beaucoup plus lent que 2.3.

Edit: vient de rencontrer à nouveau les erreurs de temporisation, après environ 4 ou 5 redémarrages de mon projet docker-compose. Également rencontré une nouvelle erreur avec 2.5.0.1: Cannot start service <container name>: error while creating mount source path <local mount path>: mkdir <local mount path>: file exists

OK, je suis toujours confronté à des problèmes avec la version 2.5.0.1. L'utilisation du processeur est encore trop élevée par rapport à la v2.3.x, et la vitesse est également assez lente.

Quelqu'un de l'équipe Docker peut-il reconnaître et peser sur cela?

Dieu, 4 ans ont passé, ce problème n'est toujours pas résolu, et cela m'arrive tout le temps