Compose: UnixHTTPConnectionPool (host = 'localhost', port = None): Zeitüberschreitung beim Lesen. (Lesezeitlimit = 60)

habe das versucht

export DOCKER_CLIENT_TIMEOUT=120
export COMPOSE_HTTP_TIMEOUT=120

und es scheint das Problem vorerst zu beheben

Andere in diesem Thread erwähnte Lösungen:

• Starten Sie Docker neu
• Erhöhen Sie die Docker-CPU und den Speicher

Kommt es vor, wenn Sie Ihr WLAN ausschalten? Könnte mit https://github.com/docker/docker-py/issues/1076 zusammenhängen.

Eine andere Theorie, wenn für Ihren Dienst tty: True aktiviert ist, könnte # 3106 sein

Ich sehe genau das gleiche Problem mit der neuesten Beta für Mac. Gleicher Fehler, wenn ich docker-compose create ausführe

Könnte dies damit zusammenhängen, dass das Bild eine sehr große Ebene enthält? (Eine sehr langwierige npm install -Operation, die ungefähr eine Minute dauert, um zu einer Ebene abgeflacht zu werden, wenn Docker das Bild erstellt.)

Wir sehen dieses Problem auch bei Verwendung einer Docker-Compose-Datei mit 6 Containern [Docker-Compose-Version 1.8.1, Build 878cff1] unter Windows und Mac [Version 1.12.2-rc1-beta27 (Build: 12496).
179c18cae7]

Das Erhöhen der verfügbaren Ressourcen für Docker scheint die Wahrscheinlichkeit zu verringern, dass dies geschieht (ebenso wie das Erweitern der Timeout-Variablen), wird jedoch nie beseitigt.

Wir haben auch einige große Schichten (240 MB ist der größte, der Hauptbefehl zur Paketinstallation) und wir binden an ein Hostverzeichnis mit 120 MB Dateien in mehreren Containern.

Bei verschiedenen Versuchen, dies zu umgehen, habe ich etwas gefunden, das Aufschluss über eine mögliche Lösung geben könnte:

Anfangs sah mein Szenario ein bisschen so aus:

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

Mein gemounteter Pfad enthielt viele Verzeichnisse mit großen statischen Dateien, die ich beim erneuten Laden von Code nicht wirklich mounten musste. Also habe ich gegen so etwas getauscht:

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

Dadurch wurde die Laufzeit für das Mounten aller meiner großen statischen Dateien nicht berücksichtigt, wodurch der Dienst viel schneller gestartet wurde.

Was ich daraus verstehe, ist: Je mehr Dateien Sie mounten, insbesondere je größer sie sind (Bilder in den MBs anstelle von Quelldateien in den Bs / KBs), desto länger werden die Ladezeiten.

Hoffe das hilft

+1
Ich sehe dieses Timeout-Problem jede Woche, normalerweise nach einem Leerlaufwochenende, während ich versuchte, eine Verbindung zu meinen Containern herzustellen. Es ist eine Zeitüberschreitung aufgetreten ...
Ich muss den laufenden Docker-Prozess beenden und neu starten, um das Problem zu umgehen.

+1
Es passiert mir jedes Mal, wenn ich versuche, die Container neu zu starten, weil sie nach einem Tag nicht mehr reagieren. Ich bin mir nicht sicher, ob mein Fall mit der Montage zu tun hat, da ich versuche, die Container anzuhalten.

Happing mit einem nginx Conatiner, Up 47 hours .
Docker für 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).

Vielen Dank an @gvilarino . Ich glaube, dass das Mounten großer Dateien die Ursache für dieses Problem auf meinem Linux-Server ist. Ihr Snippet könnte eine Problemumgehung sein, wenn die großen Dateien nicht im Container benötigt werden.

Ich frage mich jedoch, warum die Bereitstellung in Docker langsam ist. Vielleicht löst es eine Diskettenkopie aus? Aber wieso?

@cherrot Ich würde nicht sagen, dass ich das Thema sehr gut beherrsche, aber ich glaube, das hat mit dem von Docker verwendeten Speichertreiber zu tun und damit, wie er intern funktioniert, um die Ebenen in Ordnung zu halten. Verwenden Sie docker info zu sehen, welchen Speichertreiber Ihr Daemon verwendet (wahrscheinlich aufs , was am langsamsten ist). Abhängig von Ihrem Host-Betriebssystem können Sie ihn ändern, um etwas anderes zu ändern ( overlay ist eine bessere Wahl, wenn unterstützt). Es gibt schnellere Alternativen wie LCFS, aber sie werden von Docker nicht kommerziell unterstützt, sodass Sie dort alleine sind.

Wir sehen auch diese Auszeit. Dies scheint auch auf die von uns verwendeten Volumes zurückzuführen zu sein.

Wir benötigen einige Container, um auf einige SMB-Netzwerkfreigaben zugreifen zu können. Also haben wir diese Freigabe auf dem Host-System bereitgestellt und sie im Container gebunden. Manchmal ist die Kommunikation zwischen dem Windows Server und unserem Linux-Host jedoch unterbrochen (siehe https://access.redhat.com/solutions/1360683), und dies blockiert das Starten oder Stoppen unseres Containers, das nach einer Weile eine Zeitüberschreitung aufweist.

Ich habe noch keine Lösung. Ich bin auf der Suche nach einem Volume-Plugin, das SMB unterstützt, oder um das Kommunikationsproblem bei SMB zu beheben. aber noch keine wirkliche Lösung.

FWIW: Für die Leute, die hier über eine Suchmaschine landen und ihre Lösung finden, konnte ich dies einfach durch die Methode beheben. Haben Sie versucht, sie aus- und wieder einzuschalten? Ich habe meinen Docker Mac OS-Client neu gestartet.

+1 auf diesem, ich führe Stresstests auf meiner Instanz durch, die 4 Container ausführt und Docker hängt sogar für docker ps -a also versuche ich, die Container neu zu starten, aber ich bekomme
UnixHTTPConnectionPool(host='localhost', port=None): Read timed out und

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)

Nur wenn ich den docker -Dienst neu starte, scheint es gelöst zu sein, irgendwelche Ideen?

+1

`Neustart von web-jenkins_jenkins_1 ...

FEHLER: für web-jenkins_jenkins_1 UnixHTTPConnectionPool (host = 'localhost', port = None): Zeitüberschreitung beim Lesen. (Lesezeitlimit = 130)
FEHLER: Das Abschließen einer HTTP-Anforderung hat zu lange gedauert. Versuchen Sie es erneut mit --verbose, um Debug-Informationen zu erhalten.
Wenn dieses Problem aufgrund langsamer Netzwerkbedingungen regelmäßig auftritt, sollten Sie COMPOSE_HTTP_TIMEOUT auf einen höheren Wert (aktueller Wert: 120) setzen. "

Ich starte Docker neu, es ist gelöst. aber jeden Tag muss ich neu starten

Der Neustart von Docker funktioniert für mich.

+1 Docker neu starten hat auch bei mir funktioniert.

Ich bin auf dieses Problem gestoßen, als ich ein sehr großes Docker-Image erstellt und dann versucht habe, es in eine Remote-Registrierung zu übertragen. Das Neustarten von Docker war keine anwendbare Lösung, aber die Antwort von @bodaz hat es für mich angesprochen: https://github.com/docker/compose/issues/3927#issuecomment -245948736

@ rodrigo-brito - Ich habe diesen Fehler schon seit einiger Zeit und der Neustart von Docker Deamon hat das Problem gelöst - nicht mehr, seit ich meinem Projekt einen weiteren Dienst hinzugefügt habe.

Ich habe das gleiche Problem, aber ich habe eine ziemlich einfache Einrichtung.
Ich habe nur einen Verdaccio 3-Container, der auf einem Bild mit einer Größe von 164 MB basiert.
Das ist sehr enttäuschend: /

Ich verwende einen MBP Pro 13 von 2015

Ist mir aufgrund eines großen Portbereichs passiert, erstellt es tatsächlich eine Regel pro Port ....

Ein einfaches sudo service docker restart löst dies für mich jedes Mal, wenn es auftritt.

Ist mir auch passiert, in meinem Fall docker-compose push (nicht einmal versucht, die App auszuführen) auf Azure DevOps.

Meine anderen Builds verwenden kein Docker-Compose, sondern nur docker push

Ich habe die kubuntu 18.04.1 docker.io-Version von docker entfernt und docker-ce 18.09.0 installiert
Problem ging weg.

Ich habe gerade den Push-Schritt docker-compose in einzelne Pushs umgewandelt.

Dieses Zeitlimit tritt auf, wenn ein Container über Docker-Compose oder über die Docker-Py-Bibliothek ausgeführt wird (Zeitüberschreitung, selbst wenn das Zeitlimit auf 2 Minuten erhöht wird). Der Fehler wird jedoch nicht angezeigt, wenn wir ihn über die Docker-CLI ausführen (der Container wird sofort gestartet). Wir sehen das Problem auch nur auf einem Linux CI-Server und nicht auf unseren Macs. Wir arbeiten daran, ein minimal reproduzierbares Beispiel zu entwickeln.

Wenn Sie dieses Problem mit einem docker-compose kill auf einer Debian-VM auf einem MacOS-Host haben, installieren Sie es direkt vom Docker. (Docker Version 18.09.0, Build 4d60db4)

Ich hatte den gleichen Fehler beim Starten von Docker mit Protokolltreiber: syslog, wenn der rsyslog-Port nicht verfügbar war.
Error starting container 0ba2fb9540ec6680001f90dce56ae3a04b831c8146357efaab79d4756253ec8b: UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)

Der Neustart von Docker funktioniert für mich.

@ rodrigo-brito Neustart ist keine Lösung ...

Ist mir aufgrund eines großen Portbereichs passiert, erstellt es tatsächlich eine Regel pro Port ....

Genau das Gleiche für mich. Nach dem Fehler verbraucht der Docker-Daemon bis zur Erschöpfung weiterhin Speicher. Ich muss systemctl stop docker bevor mein System stirbt. (Docker Version 18.09.3, Build 774a1f4)

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

einfacher Neustart von Docker löste dies für mich ...

Es scheint, dass das Problem in den neuesten Docker-CE-Versionen immer noch vorhanden ist. Ich starte ~ 5 Container, wobei der langsame einen Docker-Volume-Mount hat, der auf eine NFS-Freigabe verweist. Keine Container legen einen Port offen. Hat jemand herausgefunden, ob dies ein gültiger Fehler ist ( port=None scheint verdächtig)?

~~~
Klient:
Version: 18.09.5
API-Version: 1.39
Go-Version: go1.10.8
Git Commit: e8ff056dbc
Gebaut: Do 11. April 04:44:28 2019
OS / Arch: Linux / AMD64
Experimentell: falsch

Server: Docker Engine - Community
Motor:
Version: 18.09.5
API-Version: 1.39 (Mindestversion 1.12)
Go-Version: go1.10.8
Git Commit: e8ff056
Gebaut: Do 11. April 04:10:53 2019
OS / Arch: Linux / AMD64
Experimentell: falsch
~~~

Es wurde eine weitere Ausgabe von --verbose hinzugefügt. Ich glaube nicht, dass es hier irgendetwas Nützliches gibt, es sagt nur für eine lange Zeit, dass einige Containererstellungsoperationen für eine lange Zeit warten. Anscheinend wird Polling verwendet, da die folgende Meldung etwa 1x / s gedruckt wird:

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

Der localhost / port = Node ist meiner Meinung nach ein bisschen wie ein roter Hering, da die Verbindung mit docker.sock hergestellt wird, sodass kein Fehler irgendwo versteckt ist. Ich denke, dies muss innerhalb von Docker aufgespürt werden, nicht dass die Docker-Compose-Behandlung dieser Anfrage hier optimal ist.

Docker-compose scheint eine Anforderungs-ID zu fehlen, die protokolliert werden könnte, sodass wir wissen würden, welche Anforderung blockiert. Ich weiß zum Beispiel, dass mein api -Container nicht innerhalb des Timeouts erstellt werden konnte, aber das Anforderungsprotokoll hilft überhaupt nicht. Vielleicht kann jemand anderes hier einige Informationen hinzufügen:

~~~
urllib3.connectionpool._make_request: http: // localhost: Keine "POST /v1.25/containers/create?name=api-memcache HTTP / 1.1" 201 90
urllib3.connectionpool._make_request: http: // localhost: Keine "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: docker create_container -> {'Id': '22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f',
'Warnungen': Keine}
compose.cli.verbose_proxy.proxy_callable: docker separect_container_from_network -> Keine
compose.cli.verbose_proxy.proxy_callable: docker inspect_container <- ('22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f')
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network <- ('ba67095c5ea718af13a09798bc2f5ab24f5d0b54ce684b6f4cb248ab705df900', 'proxy', aliases = '' ip '
urllib3.connectionpool._make_request: http: // localhost: None "GET /v1.25/containers/22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f/json HTTP / 1.1" 200 None
urllib3.connectionpool._make_request: http: // localhost: Keine "POST /v1.25/containers/create?name=api HTTP / 1.1" 201 90
compose.cli.verbose_proxy.proxy_callable: docker create_container -> {'Id': '1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec',
'Warnungen': Keine}
compose.cli.verbose_proxy.proxy_callable: docker inspect_container <- ('1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec')
compose.parallel.feed_queue: Ausstehend: set ()
urllib3.connectionpool._make_request: http: // localhost: Keine "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
urllib3.connectionpool._make_request: http: // localhost: Keine "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 None
compose.cli.verbose_proxy.proxy_callable: docker separect_container_from_network -> Keine
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network -> Keine
compose.cli.verbose_proxy.proxy_callable: docker separect_container_from_network <- ('22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f', 'proxy')
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network <- ('7d81ef23610f1b8f7ac95837cbf6c9eef977b5b0846fea24be5c7054e471df39', 'proxy', aliases = [']
compose.cli.verbose_proxy.proxy_callable: docker inspect_container -> JSON ...
urllib3.connectionpool._make_request: http: // localhost : Keine "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: Ausstehend: set ()
compose.parallel.feed_queue: Ausstehend: set ()
compose.cli.verbose_proxy.proxy_callable: docker separect_container_from_network <- ('1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec', 'proxy')
compose.cli.verbose_proxy.proxy_callable: docker create_container -> {'Id': 'ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af',
'Warnungen': Keine}
urllib3.connectionpool._make_request: http: // localhost : Keine "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
urllib3.connectionpool._make_request: http: // localhost : Keine "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 separect_container_from_network -> Keine
compose.parallel.feed_queue: Ausstehend: set ()
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network -> Keine
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network <- ('22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f', 'proxy', aliases = ['
compose.parallel.feed_queue: Ausstehend: set ()
urllib3.connectionpool._make_request: http: // localhost : None "GET /v1.25/containers/ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af/json HTTP / 1.1" 200 None
urllib3.connectionpool._make_request: http: // localhost : Keine "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: Docker-Start <- ('7d81ef23610f1b8f7ac95837cbf6c9eef977b5b0846fea24be5c7054e471df39')
compose.parallel.feed_queue: Ausstehend: set ()
compose.cli.verbose_proxy.proxy_callable: docker separect_container_from_network -> Keine
compose.cli.verbose_proxy.proxy_callable: docker inspect_container -> JSON ...
urllib3.connectionpool._make_request: http: // localhost : Keine "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 = ['ip', ''
compose.cli.verbose_proxy.proxy_callable: docker separect_container_from_network <- ('ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af', 'proxy')
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network -> Keine
compose.cli.verbose_proxy.proxy_callable: Docker-Start <- ('22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f')
compose.parallel.feed_queue: Ausstehend: set ()
urllib3.connectionpool._make_request: http: // localhost: Keine "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
urllib3.connectionpool._make_request: http: // localhost: Keine "POST /v1.25/networks/proxy/connect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: docker separect_container_from_network -> Keine
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network -> Keine
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network <- ('ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af', 'proxy', aliases = '' Keiner)
compose.cli.verbose_proxy.proxy_callable: Docker-Start <- ('1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec')
urllib3.connectionpool._make_request: http: // localhost: Keine "POST /v1.25/networks/proxy/connect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network -> Keine
compose.cli.verbose_proxy.proxy_callable: Docker start <- ('ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af')
compose.parallel.feed_queue: Ausstehend: set ()
compose.parallel.feed_queue: Ausstehend: set ()
compose.parallel.feed_queue: Ausstehend: set ()
compose.parallel.feed_queue: Ausstehend: set ()
...
- ~ 30 Zeilen weggelassen
...
API-Kommentare erstellen ... fertig
compose.cli.verbose_proxy.proxy_callable: Docker-Start -> Keine
compose.parallel.parallel_execute_iter: Abgeschlossene Verarbeitung: ServiceName (Projekt = 'API', Service = 'Kommentare', Nummer = 1)
compose.parallel.feed_queue: Ausstehend: set ()
compose.parallel.parallel_execute_iter: Abgeschlossene Verarbeitung:
compose.parallel.feed_queue: Ausstehend: set ()
API-Memcache erstellen ... fertig
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 -> Keine
compose.parallel.parallel_execute_iter: Abgeschlossene Verarbeitung: ServiceName (project = 'api', service = 'memcache', number = 1)
compose.parallel.feed_queue: Ausstehend: set ()
compose.parallel.parallel_execute_iter: Abgeschlossene Verarbeitung:
compose.parallel.feed_queue: Ausstehend: set ()
compose.parallel.feed_queue: Ausstehend: set ()
compose.parallel.feed_queue: Ausstehend: set ()
compose.parallel.feed_queue: Ausstehend: 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 -> Keine
API-Kommentare erstellen-db ... fertig
compose.parallel.feed_queue: Ausstehend: set ()
compose.parallel.parallel_execute_iter: Abgeschlossene Verarbeitung:
compose.parallel.feed_queue: Ausstehend: set ()
compose.parallel.feed_queue: Ausstehend: set ()
compose.parallel.feed_queue: Ausstehend: set ()
compose.parallel.feed_queue: Ausstehend: set ()
compose.parallel.feed_queue: Ausstehend: set ()
- ~ 15 Zeilen weggelassen
Api-Redis erstellen ... fertig
compose.parallel.feed_queue: Ausstehend: 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 -> Keine
compose.parallel.parallel_execute_iter: Abgeschlossene Verarbeitung: ServiceName (Projekt = 'API', Service = 'Redis', Nummer = 1)
compose.parallel.feed_queue: Ausstehend: set ()
compose.parallel.parallel_execute_iter: Abgeschlossene Verarbeitung:

compose.parallel.feed_queue: Ausstehend: set ()

- 100+ Zeilen weggelassen
compose.parallel.parallel_execute_iter: Fehlgeschlagen: ServiceName (project = 'api', service = 'api', number = 1)
compose.parallel.feed_queue: Ausstehend: set ()

FEHLER: für API UnixHTTPConnectionPool (Host = 'localhost', Port = Keine): Zeitüberschreitung beim Lesen. (Lesezeitlimit = 60)
compose.parallel.parallel_execute_iter: Fehlgeschlagen:
compose.parallel.feed_queue: Ausstehend: set ()

FEHLER: für API UnixHTTPConnectionPool (Host = 'localhost', Port = Keine): Zeitüberschreitung beim Lesen. (Lesezeitlimit = 60)
compose.cli.errors.log_timeout_error: Das Abschließen einer HTTP-Anforderung hat zu lange gedauert. Versuchen Sie es erneut mit --verbose, um Debug-Informationen zu erhalten.
Wenn dieses Problem aufgrund langsamer Netzwerkbedingungen regelmäßig auftritt, sollten Sie COMPOSE_HTTP_TIMEOUT auf einen höheren Wert setzen (aktueller Wert: 60).
~~~

@titpetric kann bestätigen, dass ich auch dieses Problem habe.

IMHO ist dieses Problem auf der Docker-Seite, nicht auf der Docker-Compose-Seite. Jemand sollte die Debug-Protokollierung auf dem Docker-Deamon aktivieren und auf die dortigen Verzögerungen hinweisen und ein Problem vorab einreichen. Ich bin mir nicht sicher, ob man das ohne das leicht reproduzieren könnte.

Wenn jemand bereit ist, die Zeit einzuplanen, würde ich vorschlagen, dies zu replizieren, indem ein vollständig geladener Ordner für eine Volume-Bereitstellung erstellt wird (etwas mit mehr als 100000 Dateien / Ordnern sollte ausreichen), um festzustellen, ob eine zuverlässige Reproduktion des Problems vorliegt Kann erreicht werden. Es ist wahrscheinlich, dass der Docker-Daemon oder der Kernel-Bind-Mount selbst einige der Inode-Daten zuvor zwischenspeichert. Welches ... ist unglücklich.

Ein tcpdump kann dies auch bei einem Netzwerkdateisystem (samba, nfs) bestätigen.

Gleicher exakter Fehler hier

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)

Der Neustart von Docker hat das Problem auch für mich behoben.

Neustart ist keine Lösung Jungs .....
Wie kann man das endgültig vermeiden?

Vor dem gleichen Problem. Der folgende Fehler wird für alle Docker-Container der Organisations-Peers angezeigt:

FEHLER: für DNS UnixHTTPConnectionPool (Host = 'localhost', Port = Keine): Zeitüberschreitung beim Lesen. (Lesezeitlimit = 60)

Liegt es an einer Port-Nichtübereinstimmung oder Zuweisung in der Erstellungsdatei?

Ja, ich bin ständig auf dieses Problem gestoßen. Ich bin damit einverstanden, dass ein Neustart keine Lösung ist, aber nichts anderes scheint den Trick zu tun: /

Nur ein FYI, mit meinem Fall, der nur mit Docker-Compose wiederholt wird, neigt dazu, sich zu lösen
es. Ich glaube nicht, dass ich dockerd jemals neu gestartet habe, dieses Problem besteht nicht weiter
mich.

Am Fr, 2. August 2019 um 13:39 Uhr schrieb Alex [email protected] :

Ja, ich bin ständig auf dieses Problem gestoßen. Ich bin damit einverstanden, dass ein Neustart nicht erfolgt
eine Lösung, aber nichts anderes scheint den Trick zu tun: /

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/docker/compose/issues/3927?
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AABY7EA3NTUP5SNZRTFWFEDQCQMHBANCNFSM4CPDX2DQ
.

Ich stehe auch vor diesem Problem :(
UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)

Das gleiche Problem hier, auch das Neustarten von Docker hängt tatsächlich. Die einzige Möglichkeit besteht darin, Docker zu beenden oder neu zu starten, aber das kann nicht die Lösung sein.

@bitbrain yup das passiert mir auch schon seit geraumer zeit.

Ich habe eine gute Lösung dafür gefunden (unter MacOS)

Der Grund, warum mir das immer wieder passiert ist, war, dass Docker zu wenig Speicher zur Verfügung hatte.

Das Erhöhen des Speichers von 2 GB auf 8 GB löste das Problem für mich.

Ich habe diesen Fehler erhalten, nachdem ich ein paar Mal docker-compose up und dann docker-compose down . Ich habe alles in diesem Thread versucht. Bumping der Ressourcen, Neustart meines Mac und Neuinstallation des neuesten Docker. Ich könnte docker-compose up nach dem Neustart meiner Box wieder zum Laufen bringen, aber nachdem ich diese Befehle ein paar Mal wiederholt habe, würde es zu diesem Fehler zurückkehren und ich könnte docker-compose up zum Laufen bringen.

Mein Problem scheint ein Konflikt mit einem anderen Dienst ( pow ) gewesen zu sein, der an Port 80 gebunden war, als einer meiner Container auch an Port 80 gebunden war. Ich habe pow deinstalliert und hatte seit drei Tagen kein Problem mehr.

3 Jahre öffnen Sie dieses Ticket und noch ungelöst. Das Problem tritt auch dann auf, wenn wir die Clientverbindung auf 120 Sekunden erhöhen.

gerade passiert auf unserem Server, offene Ausgabe seit 2016, wtf

Der Neustart von Docker funktioniert für mich.

@ rodrigo-brito Neustart ist keine Lösung ...

mein Mann.

Erlebe das jetzt auch. Wild.

Haben Sie das gleiche Problem, wenn Sie Docker-Compose Up oder Docker-Compose Down versuchen. Ich habe es gelöst, indem ich den mysqld-Dienst gestoppt habe. Sobald der Container aktiv ist, starte ich mysql. RAM ist zu 20% ausgelastet.

Ausführen der Docker Desktop Community für Mac v2.1.0.5

Ich bin auf dieses Problem gestoßen und habe es gelöst, indem ich den Docker zugewiesenen Speicherplatz erhöht (und den CPU-Speicher verringert) habe.
Sie können dies unter Docker -> Einstellungen -> Erweitert tun.
Ich habe für mein spezielles Setup von 8 CPUs und 2 GB RAM auf 4 CPUs und 16 GB RAM gewechselt.

Ist auf Ubuntu Server 18.04 LTS auf dieses Problem gestoßen. Ein Neustart von Docker behebt das Problem nicht und setzt auch die Umgebungsvariablen. Irgendwelche Ideen?

@bpogodzinski Haben Sie versucht, Ihre Speichereinstellungen in Docker zu erhöhen? Ich habe sie von 2 GB auf 8 GB erhöht und das hat das Problem für mich behoben.

Im Allgemeinen scheint dieses Problem aufzutreten, wenn die Container mehr Speicher als der in Docker konfigurierte verfügbare Speicher benötigen und dann nur noch etwas hängt.

Wir hatten dieses Problem und es scheint (für uns) mit einem benannten Volume mit vielen Dateien in Verbindung zu stehen. Ich verstehe es nicht, aber es ist bei uns so, dass ein Docker-Compose (der Kürze halber bearbeitet) einen Dienst hat:

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

   volumes:
       - serviceA_volume:

In der Docker-Datei für serviceA befindet sich der scheinbar harmlose und ineffektive Befehl:

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

Beachten Sie, dass dies den Eigentümer rekursiv im Ordner / srvA / ändert, der auf dem genannten Volume ein großes Dateisystem mit 100 KB Dateien ist. Dies geschieht jedoch, wenn das Image erstellt wird und dieser Ordner leer ist. Es wird angezeigt, dass die Verwendung des benannten Volumes die Berechtigungen der lokalen Image-Datei erbt und anschließend die Berechtigungen für die benannten Volumes ändert.

Dies ist ein ziemlicher Rand und wahrscheinlich nicht das gleiche Problem, das alle anderen haben, aber es war unser Problem (das Umschalten der Linie schaltet den Fehler um). Das Ergebnis ist, dass dieses http-Timeout wahrscheinlich auf mehrere Ursachen zurückzuführen ist.

Ein Neustart von Docker hat das Problem in meinem Fall nie gelöst, und die Erhöhung der Ressourcen hat dies definitiv getan.

Nach meiner Erfahrung tritt dieses Problem häufig in kleinen Cloud-Fällen auf, in denen die RAM-Größe während des regulären Betriebs vollkommen in Ordnung ist, sich jedoch bei Docker- oder Docker-Compose-Vorgängen als unzureichend herausstellt. Sie könnten den Arbeitsspeicher leicht erhöhen, aber dies würde wahrscheinlich die Kosten einer kleinen VM drastisch erhöhen.

In jedem Fall hat das Hinzufügen einer Swap-Partition oder sogar einer Swap-Datei dieses Problem für mich gelöst!

Ist mir gerade auf einem Himbeer-Pi eingefallen. Kein Volume mit einer großen Anzahl von Dateien oder irgendetwas.
Eigentlich habe ich diese Behälter schon eine Weile auf dieser Himbeere laichen lassen (ein oder zwei Jahre lol).
Ich bin mir nicht sicher, was sich geändert hat.
Scheint ein bisschen "aus heiterem Himmel".

Das Problem tritt weiterhin auf Docker Desktop 2.2.0.3 unter MacOs auf 🙁

Ich habe mein Problem mit den folgenden Befehlen behoben:
docker volume prune
docker system prune
(Nur einer dieser Befehle ist möglicherweise ausreichend, kann aber im Moment nicht reproduziert werden ...)

Ich habe mein Problem mit den folgenden Befehlen behoben:
docker volume prune
docker system prune
(Nur einer dieser Befehle ist möglicherweise ausreichend, kann aber im Moment nicht reproduziert werden ...)

Die Lösung von @amaumont hat geholfen, obwohl ich denke, dass dies weiterhin Überstunden machen würde.
Wie alle anderen gesagt haben, ist ein Neustart von Docker keine richtige Lösung, sondern ein Pflaster.

Wir haben auch mehrere Probleme mit Docker-Compose.

Nachdem wir in sshd_config MaxSessions 500 gesetzt haben (siehe # 6463), erhalten wir jetzt auch Lese-Timeouts.
Durch Festlegen beider Zeitlimits auf 120 Sekunden wurde das Problem für den nächsten Lauf von DOCKER_HOST=xxx<strong i="8">@yyy</strong> docker-compose up -d behoben.

Im zweiten Lauf ging die Maschine so hoch wie 30 (sic!) Vor dem Docker-compose Befehl aufgrund Timeouts fehlgeschlagen. Ein Docker-Neustart hat dieses Problem nicht gelöst, auch nicht vorübergehend.
Der Server ist eine AWS EC2-Instanz mit genügend CPU / Disk / NetIO usw. Die Compose-Datei enthält 1 Traefik und 3 Services mit Mailhog, daher hier nichts Besonderes. Das Ausführen von docker-compose up -d mit derselben Datei docker-compose.yml direkt auf dem Server funktioniert zuverlässig und wie erwartet.
Das Ausführen mit --verbose zeigt über tausend aufeinanderfolgende Zeilen mit compose.parallel.feed_queue: Pending: set() .

Ich werde versuchen, die Docker-Compose-Datei mit dem Remote-Server zu synchronisieren und Docker-Compose als Problemumgehung direkt auf diesem Computer auszuführen.

Für mich hat es geholfen, Docker einfach neu zu starten.

Passiert ziemlich oft für mich, wenn ich versuche, von Bitbucket-Pipelines auf meine private Registrierung zuzugreifen. Funktioniert gut, wenn Sie vom lokalen PC aus pushen.
Das Neustarten von Docker kann eine Weile dauern, diese "Weile" dauert jedoch maximal 10 Minuten: c

upd. Das Setzen von DOCKER_CLIENT_TIMEOUT und COMPOSE_HTTP_TIMEOUT schien zu helfen, aber ich weiß nicht, wie lange

Ich habe angefangen, diese zu bekommen, seit ich mit aktiviertem Caching zu Docker Edge gewechselt bin

Dies geschieht für mich ziemlich konsequent, seit ich vor 2-3 Jahren angefangen habe, Docker zu verwenden. Nachdem ein Container eine Weile ausgeführt wurde, wird er zu einem Zombie und die gesamte Docker-Engine muss neu gestartet werden, damit die Dinge wieder reagieren. Dies fühlt sich wie ein Ressourcenleck an, da die Leerlaufzeit für das erlebte Verhalten sehr relevant zu sein scheint.

Wenn keine Container oder nur für kurze Zeit ausgeführt werden, scheint alles tagelang oder wochenlang einwandfrei zu funktionieren. Sobald ich jedoch einen Container einige Stunden lang laufen lasse, reagiert er nicht mehr. Ich muss ihn in der Befehlszeile zwangsweise stoppen, und jeder Versuch, mit docker oder docker-compose zu kommunizieren, schlägt einfach fehl mit einer Auszeit. Ein Neustart ist die einzige funktionierende Lösung.

Ausgabe von 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

Ausgabe von 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

Ausgabe von 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.

Ich hatte das gleiche Problem, auch wenn ich die Ressourcen von 4 GB RAM, 1 GB Swap auf 6 GB RAM, 2 GB Swap erhöht habe.

Ich stehe auch vor dem gleichen Problem

auch mit dem gleichen Problem

Ich habe das gleiche Problem unter Ubuntu 18.04 LTS (8 GB RAM) mit HTTPS.

Ich kann Container mit docker-compose up , aber nach der Bereitstellung kann ich Container mit docker-compose down nicht mehr stoppen. Ein Neustart des Docker-Daemons oder ein Neustart der VM haben sich als unwirksam erwiesen. Das Hinzufügen von Timeout-Umgebungsvariablen ( DOCKER_CLIENT_TIMEOUT , COMPOSE_HTTP_TIMEOUT ) hat ebenfalls nichts bewirkt.

Ich kann mit Containern einzeln interagieren und sie stoppen, ich kann Container inspizieren, an sie anhängen und alles andere, aber ich kann sie nicht docker-compose Befehl

Die Fehlermeldung ist immer dieselbe:

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

Ich hatte das gleiche Problem, als ich Folgendes in meiner docker-compose.yml hatte:

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

Der Fehler war verschwunden, als ich Anführungszeichen um "10" hinzufügte. In den Dokumenten wird angegeben, dass die Werte für max-file und max-size Zeichenfolge sein müssen, aber immer noch. Die Fehlermeldung ist ziemlich irreführend.

Ich hatte das gleiche Problem, als ich Folgendes in meiner docker-compose.yml hatte:

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

Der Fehler war verschwunden, als ich Anführungszeichen um "10" hinzufügte. In den Dokumenten wird angegeben, dass die Werte für max-file und max-size Zeichenfolge sein müssen, aber immer noch. Die Fehlermeldung ist ziemlich irreführend.

Du rettest meinen Tag. Ich danke dir sehr!

Ich hatte das gleiche Problem, als ich Folgendes in meiner docker-compose.yml hatte:

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

Der Fehler war verschwunden, als ich Anführungszeichen um "10" hinzufügte. In den Dokumenten wird angegeben, dass die Werte für max-file und max-size Zeichenfolge sein müssen, aber immer noch. Die Fehlermeldung ist ziemlich irreführend.

Ich konfiguriere den Protokollierungstreiber auf Docker-Daemon-Ebene. Ich verwende fluentd als Protokollierungstreiber, daher funktioniert dieses Update leider nicht für mich. = /

habe das versucht

export DOCKER_CLIENT_TIMEOUT=120
export COMPOSE_HTTP_TIMEOUT=120

und es scheint das Problem vorerst zu beheben

Andere in diesem Thread erwähnte Lösungen:

• Starten Sie Docker neu
• Erhöhen Sie die Docker-CPU und den Speicher

Nun, nichts hat für mich funktioniert, außer der Timeout-Option, ein großes Lob an Sie.

Ich erhalte dies, seit ich ein in NFS bereitgestelltes Verzeichnis in einem meiner Container verwende. Dieses NFS-gemountete Verzeichnis befindet sich auf einer langsamen Verbindung (an einem Remotestandort mit einer Verbindung mit geringer Bandbreite). Könnte das das Problem sein?

Ich erlebe dies sehr häufig auf dem Mac Docker 2.4.0.0 in zwei verschiedenen Projekten mit unterschiedlichen Konfigurationen von docker-compose.yml. Ich kann mich nicht erinnern, dass es jemals vor ~ 1 Woche passiert ist, als ich auf 2.4.0.0 aktualisiert habe. Gibt es eine Regression?

Ich habe versucht, das Timeout auf 600 zu erhöhen, den Arbeitsspeicher auf 16 GB zu erhöhen und auf 4 GB zu wechseln, Docker neu zu starten, mein gesamtes Macbook neu zu starten. Es scheint nichts zu funktionieren, außer es immer wieder zufällig zu versuchen, dann wird es gelegentlich funktionieren. Aber dann, wenn ich das nächste Mal einen Container neu starten oder neu erstellen muss, das gleiche Problem :(

Begann dies auch mit 2.4.0.0 auf dem Mac zu sehen. Problemumgehung für mich ist, Docker neu zu starten, aber später wieder darauf zu stoßen.

Hier gilt das gleiche! Mit dem Update auf 2.4.0 starten unsere Setups manchmal gar nicht mit den genannten Read timed out. -Fehlern, manchmal starten nur einige Container, andere werfen diesen Fehler aus. Ich denke schon an ein Downgrade!

Nur um zu erwähnen: Dieses Problem betrifft sowohl Setups mit NFS-Freigaben als auch Projekte mit "normalen" gemounteten Volumes

Gleiches Problem hier, auch auf dem Mac und nach dem 2.4.0-Update. Ich versuche gerade, ob ein Downgrade hilft.

Update: Ein Downgrade auf die vorherige Version, Löschen des Caches und erneutes Erstellen behebt das Problem.

Ich habe dieses Problem auch kürzlich gesehen (Mac, 2.4.0.0), als ich es noch nie zuvor gesehen habe. Das Ausführen von docker image prune hat das Problem für ein paar Tage behoben, aber jetzt ist es wieder da.

Seit dem 2.4.0-Update (unter Mac OS Mojave 10.14.5) trat dieser Timeout-Fehler häufig auf.

Dies wird seit dem Update auf Docker Desktop 2.4.0.0 (48506) unter MacOS Catalina auch häufiger angezeigt.

Ich habe die gleichen Timeout-Probleme seit 2.4.0.0 unter Mac OS. Ich hatte dieses Problem noch nie zuvor.
Ich habe den Edge Build 2.4.1.0 (48583) ausprobiert, habe aber immer noch das gleiche Problem.

Ich habe das gleiche Problem und ein Neustart von Docker hat es für MacOs Catalina (10.15.5) und Docker Version 2.4.0.0 behoben

Das gleiche hier, hatte das Problem vor dem Update auf Docker Desktop 2.4.0.0 nicht.
Das Neustarten des Docker-Desktops funktioniert, ist jedoch nur eine Problemumgehung.

Gleiches hier, auch ab v2.4.0

Update: Ein Downgrade auf die vorherige Version, Löschen des Caches und erneutes Erstellen behebt das Problem.

Werde das versuchen. Ich bin mir nicht mal sicher, wie es gemacht wird. Ich nehme an, es ist durch Deinstallieren und Herunterladen einer früheren Version?

Ja, ich habe die Version 2.4 deinstalliert und die Version 2.3 heruntergeladen / neu installiert. Jetzt funktioniert es, ich kann meine Container wie gewohnt starten.
Ich habe die 2.3 von dort bekommen: https://docs.docker.com/docker-for-mac/release-notes/#docker -desktop-community-2302

Ja, ich kann bestätigen, dass es auch für mich den Unterschied gemacht hat. Auf jeden Fall ist v2.4 hier irgendwie schuld.

Wenn dieses Problem aufgrund langsamer Netzwerkbedingungen regelmäßig auftritt, sollten Sie COMPOSE_HTTP_TIMEOUT auf einen höheren Wert setzen (aktueller Wert: 60).

Wie genau ist 1 Gbit / s ein langsames Netzwerk?

Das Downgrade hat auch bei mir funktioniert. Für diejenigen, die Docker über Homebrew verwalten

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

Wenn dieses Problem aufgrund langsamer Netzwerkbedingungen regelmäßig auftritt, sollten Sie COMPOSE_HTTP_TIMEOUT auf einen höheren Wert setzen (aktueller Wert: 60).

Wie genau ist 1 Gbit / s ein langsames Netzwerk?

In meinem Fall geschah dies aufgrund eines NFS-gemounteten Netzlaufwerks.
Die Hauptursache für die "langsame" Netzwerkgeschwindigkeit war die Verwendung von NFS, nicht die Geschwindigkeit der physischen Verbindung.
Aber es zeigt definitiv, dass es ein Problem in der Implementierung gibt und ich wäre überrascht, wenn das Ändern von HTTP_TIMEOUT es lösen würde.

Hier gilt das gleiche. Deutliche Verlangsamung bei der Containererstellung, was zu dem oben genannten HTTP-Timeout-Fehler unter Docker für Mac v2.4 führt. Das Setzen von COMPOSE_HTTP_TIMEOUT = 120 hat funktioniert, aber die Langsamkeit bei der Containererstellung ist immer noch ein neues Problem. Ein Downgrade auf v2.3 behebt dies ebenfalls.

Ich kann das gleiche Problem bestätigen, seit ich es auf Docker für Mac v2.4 installiert habe.
Ich kann auch in Leerlaufzeiten einen signifikanten Anstieg des RAM- und CPU-Verbrauchs bestätigen, wenn der Docker-Daemon ausgeführt wird. Aber ich denke, es hat nichts damit zu tun, das Paket selbst zu komponieren.

Ich hatte das gleiche Problem. Deinstallierte 2.40 und installierte 2.3 über den von @ddesrousseaux erwähnten

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

Dieses Problem besteht weiterhin in Docker v. 2.4.3.0 .

Ich habe auch von 2.4 auf 2.3 herabgestuft, um die massiven Langsamkeitsprobleme in der Version 2.4 zu umgehen. Gerne stellen wir alle Protokolle zur Verfügung, die nützlich sein könnten, um zu debuggen, was hier vor sich geht.

In Anlehnung an das oben Gesagte begann dies in 2.4.2.x für mich. Beim Upgrade von 2.3 hat sich etwas geändert.

Ich habe einen Test in einer Linux-Umgebung durchgeführt und hatte ein ähnliches Problem. Ich habe die neueste Docker-Compose-Binärdatei (v1.27.4) installiert und hatte das gleiche Timeout-Problem, das ihr meldet.

Nach dem Downgrade auf 1.27.2, das auch in Docker für Mac 2.3 verfügbar ist, ist das Problem verschwunden.

Gleiches Problem mit der aktuellen Version unter Ubuntu 20.04.

Mein Problem war, dass ich Docker und Docker-Compose mit Snap und Apt installiert habe. Ich habe sie deinstalliert, neu gestartet und dann die offiziellen Installationsanweisungen unter https://docs.docker.com/engine/install/ubuntu/ und https://docs.docker.com/compose/install/ befolgt.

Seit dem 2.4.0-Update treten immer noch häufig Timeout-Fehler auf, die in 2.5.0 noch nicht behoben sind

Ja, das gleiche hier. Es hat in den letzten 2 Jahren gut für mich funktioniert. Aber vor 2 Monaten plötzlich, wann immer ich möchte, 1 Instanz und ein anderes Docker-Projekt starten, das es wirft:
für Apache UnixHTTPConnectionPool (host = 'localhost', port = None): Zeitüberschreitung beim Lesen.

Durch einen Neustart von Docker wird das Problem behoben. Aber es ist ein echtes Problem, wenn ich an einem Tag mehrmals zwischen Projekten wechseln muss

Das gleiche Problem seit 2.4 zu treffen, 300% CPU zu allen Zeiten, 2.5 hat nicht geholfen, auf 2.3 zurückgestuft und die Dinge sind in Ordnung. Dies auf dem neuesten MacBook mit i7 CPU und 32 g RAM

Ich habe gerade ein Upgrade auf die letzte Docker für Mac-Version (v2.5.0.1) durchgeführt und das Problem scheint gelöst zu sein.
Kein UnixHTTPConnection Fehler mehr und keine 100% CPU-Auslastung mehr.

Ich bin mir nicht sicher, ob jemand anderes dies bestätigen kann.

Wie hast du das bekommen? Wenn Sie Docker auf dem Mac öffnen und "Nach Updates suchen" ausführen, wird weiterhin angezeigt, dass ich die neueste Version 2.4.2.0 habe.

Ich habe gerade ein Upgrade auf die letzte Docker für Mac-Version (v2.5.0.1) durchgeführt und das Problem scheint gelöst zu sein.
Kein UnixHTTPConnection Fehler mehr und keine 100% CPU-Auslastung mehr.

Ich bin mir nicht sicher, ob jemand anderes dies bestätigen kann.

Ich habe gerade das Problem in Version 2.5.0.1 erlebt. Ein Neustart von Docker scheint das Problem (zumindest vorübergehend) zu beheben.

Wie hast du das bekommen? Wenn Sie Docker auf dem Mac öffnen und "Nach Updates suchen" ausführen, wird weiterhin angezeigt, dass ich die neueste Version 2.4.2.0 habe.

Ich kann Ihnen keinen Screenshot zeigen, da ich bereits ein Upgrade durchgeführt habe, aber ich denke, Sie haben möglicherweise Probleme, Updates von Ihrem Computer zu erhalten, da seit mehr als einer Woche eine frühere Version 2.5.0 verfügbar ist.

Sie können dies in den Versionshinweisen zu Docker für Mac überprüfen (und von dort aus jedes neue Installationsprogramm herunterladen).

Ich lasse Edge laufen. Das erklärt es wahrscheinlich.

Kann bestätigen, dass v2.5.0.1 zumindest geringfügig besser ist. Keine Timeouts mehr bei jedem Start und seit dem Update heute Morgen noch nicht mehr aufgetreten. Die Startzeit des Containers scheint jedoch immer noch viel langsamer als 2,3 zu sein.

Bearbeiten: Nach ungefähr 4 oder 5 Neustarts meines Docker-Compose-Projekts sind gerade wieder Timeout-Fehler aufgetreten. Außerdem ist mit 2.5.0.1 ein neuer Fehler aufgetreten: Cannot start service <container name>: error while creating mount source path <local mount path>: mkdir <local mount path>: file exists

Kann bestätigen, dass v2.5.0.1 zumindest geringfügig besser ist. Keine Timeouts mehr bei jedem Start und seit dem Update heute Morgen noch nicht mehr aufgetreten. Die Startzeit des Containers scheint jedoch immer noch viel langsamer als 2,3 zu sein.

Bearbeiten: Nach ungefähr 4 oder 5 Neustarts meines Docker-Compose-Projekts sind gerade wieder Timeout-Fehler aufgetreten. Außerdem ist mit 2.5.0.1 ein neuer Fehler aufgetreten: Cannot start service <container name>: error while creating mount source path <local mount path>: mkdir <local mount path>: file exists

OK, ich habe auch immer noch Probleme mit der Version 2.5.0.1. Die CPU-Auslastung ist im Vergleich zu Version 2.3.x immer noch zu hoch, und die Geschwindigkeit ist auch ziemlich langsam.

Kann jemand vom Docker-Team dies anerkennen und abwägen?

Gott, 4 Jahre sind vergangen, dieses Problem ist immer noch nicht gelöst und es passiert mir die ganze Zeit