Compose: UnixHTTPConnectionPool (host = 'localhost', port = None): Waktu pembacaan habis. (baca timeout = 60)

mencoba ini

export DOCKER_CLIENT_TIMEOUT=120
export COMPOSE_HTTP_TIMEOUT=120

dan tampaknya masalah tersebut telah diperbaiki untuk saat ini

Solusi lain yang disebutkan orang di utas ini:

• Mulai ulang Docker
• Tingkatkan CPU & memori Docker

Apakah itu terjadi jika Anda mematikan WiFi Anda? Bisa terkait dengan https://github.com/docker/docker-py/issues/1076.

Teori lain, jika layanan Anda mengaktifkan tty: True , bisa jadi # 3106

Saya melihat masalah yang persis sama dengan versi beta terbaru untuk Mac. Kesalahan yang sama jika saya menjalankan docker-compose create

Mungkinkah ini terkait dengan memiliki satu lapisan yang sangat besar pada gambar? (operasi npm install yang sangat panjang yang membutuhkan waktu sekitar satu menit untuk diratakan menjadi lapisan saat pekerja galangan membuat gambar)

Kami juga melihat masalah ini menggunakan file pembuatan buruh pelabuhan dengan 6 kontainer [docker-compose versi 1.8.1, build 878cff1] di windows dan mac [Versi 1.12.2-rc1-beta27 (build: 12496)
179c18cae7]

Meningkatkan sumber daya yang tersedia untuk buruh pelabuhan tampaknya mengurangi kemungkinan hal itu terjadi (seperti halnya memperpanjang vars batas waktu), tetapi itu tidak pernah dihilangkan.

Kami juga memiliki beberapa layer berukuran besar (240MB adalah yang terbesar, perintah instal paket utama) dan kami mengikat ke direktori host dengan 120MB file di beberapa kontainer.

Dari berbagai upaya untuk mengatasi ini, saya menemukan sesuatu yang mungkin menjelaskan beberapa kemungkinan perbaikan:

Awalnya skenario saya terlihat seperti ini:

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

Jalur yang saya pasang menyertakan banyak direktori dengan file statis yang besar yang sebenarnya tidak saya perlukan untuk dipasang dalam hal pemuatan ulang kode. Jadi saya akhirnya menukar sesuatu seperti ini:

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

Ini meninggalkan keluar dari runtime pemasangan semua file statis besar saya, yang membuat layanan start cara yang lebih cepat.

Apa yang saya pahami dari ini adalah: semakin banyak file yang Anda pasang, terutama semakin besar (gambar dalam MB, bukan file sumber di B / KB), waktu pemuatan meningkat pesat.

Semoga ini membantu

+1
Saya melihat masalah batas waktu ini setiap minggu, biasanya setelah akhir pekan menganggur, ketika saya mencoba menghubungkan ke kontainer saya, waktunya habis ...
Saya harus menghentikan proc buruh pelabuhan yang sedang berjalan dan memulai ulang untuk mengatasi ....

+1
Itu terjadi pada saya setiap kali saya mencoba memulai ulang kontainer karena mereka tidak merespons lagi setelah satu hari. Saya tidak yakin apakah kasing saya ada hubungannya dengan pemasangan karena saya mencoba menghentikan kontainer.

Happing dengan nginx conatiner, Up 47 hours .
Docker untuk 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).

Terima kasih @gvilarino , saya yakin file besar yang menggunung adalah penyebab masalah ini di server linux saya. Cuplikan Anda bisa menjadi solusi jika file besar tidak diperlukan dalam penampung.

Namun, saya bertanya-tanya mengapa pemasangan lambat di Docker? Mungkin itu memicu salinan disk? Tapi kenapa?

@cherrot Saya tidak akan mengatakan saya sangat mahir dalam subjek, tetapi saya percaya ini ada hubungannya dengan driver penyimpanan yang digunakan oleh Docker dan bagaimana cara kerjanya secara internal untuk menjaga agar lapisan tetap teratur. Gunakan docker info untuk melihat driver penyimpanan apa yang digunakan daemon Anda (mungkin aufs , yang paling lambat) dan tergantung pada OS host Anda, Anda dapat mengubahnya jadi sesuatu yang lain ( overlay menjadi pilihan yang lebih baik, jika didukung). Ada alternatif yang lebih cepat seperti LCFS tetapi tidak didukung secara komersial oleh Docker sehingga Anda akan berada di sana sendiri.

Kami juga melihat batas waktu ini. Sepertinya juga karena volume yang kami gunakan.

Kami membutuhkan beberapa wadah untuk mengakses beberapa jaringan berbagi SMB. Jadi kami memasang bagian tersebut di sistem host, dan mengikatnya di dalam penampung. Tetapi terkadang komunikasi antara Windows Server dan host Linux kami terhenti (lihat https://access.redhat.com/solutions/1360683) dan ini memblokir awal atau penghentian penampung kami yang hanya akan kehabisan waktu setelah beberapa saat.

Saya belum mendapatkan perbaikan. Saya mencari plugin volume yang mendukung SMB, atau untuk menghilangkan masalah komunikasi stall di SMB. tapi belum ada solusi nyata.

FWIW: Untuk orang-orang yang masuk ke sini melalui mesin pencari menemukan penyelesaian mereka, saya telah dapat memperbaikinya hanya dengan _Apakah Anda mencoba mematikannya dan mengaktifkannya lagi? _ Metode; Saya telah memulai ulang klien Docker Mac OS saya.

+1 untuk itu, saya menjalankan pengujian stres pada instans saya yang menjalankan 4 kontainer dan buruh pelabuhan hang bahkan untuk docker ps -a jadi saya mencoba untuk memulai ulang kontainer tetapi saya mendapatkan
UnixHTTPConnectionPool(host='localhost', port=None): Read timed out dan

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)

Hanya jika saya me-restart layanan docker sepertinya sudah terselesaikan, ada ide?

+1

`Memulai ulang web-jenkins_jenkins_1 ...

EROR: untuk web-jenkins_jenkins_1 UnixHTTPConnectionPool (host = 'localhost', port = None): Waktu pembacaan habis. (baca timeout = 130)
KESALAHAN: Permintaan HTTP membutuhkan waktu terlalu lama untuk diselesaikan. Coba lagi dengan --verbose untuk mendapatkan informasi debug.
Jika Anda mengalami masalah ini secara teratur karena kondisi jaringan yang lambat, pertimbangkan untuk menyetel COMPOSE_HTTP_TIMEOUT ke nilai yang lebih tinggi (nilai saat ini: 120) .`

saya restart buruh pelabuhan, itu diselesaikan. tapi setiap hari saya harus restart

memulai ulang Docker bekerja untuk saya.

1 restart buruh pelabuhan juga bekerja untuk saya.

Saya mengalami masalah ini saat membangun image Docker yang sangat besar dan kemudian mencoba mendorongnya ke registry jarak jauh. Memulai ulang Docker bukanlah solusi yang dapat diterapkan, tetapi jawaban @bodaz ditujukan untuk saya: https://github.com/docker/compose/issues/3927#issuecomment -245948736

@ rodrigo-brito - Saya telah mendapatkan kesalahan ini sebentar sekarang dan memulai ulang docker deamon telah menyelesaikan masalah - tidak lebih sejak saya menambahkan layanan lain ke proyek saya.

Saya memiliki masalah yang sama, tetapi saya memiliki pengaturan yang cukup sederhana.
Saya hanya memiliki satu wadah verdaccio 3 berdasarkan gambar berukuran 164 MB.
Ini sangat mengecewakan: /

Saya menggunakan MBP Pro 13 dari 2015

Terjadi pada saya karena jangkauan port yang besar, ini sebenarnya membuat satu aturan per port ....

sudo service docker restart menyelesaikan ini untuk saya secara konsisten setiap kali itu terjadi.

Baru saja terjadi pada saya, dalam kasus saya docker-compose push (bahkan tidak mencoba menjalankan aplikasi) di Azure DevOps.

Build saya yang lain tidak menggunakan docker-compose tetapi biasa docker push

Saya menghapus versi docker kubuntu 18.04.1 docker.io dan menginstal docker-ce 18.09.0
Masalah hilang.

Saya baru saja mengubah langkah push docker-compose menjadi dorongan individu.

Kami melihat batas waktu ini saat menjalankan container melalui docker-compose atau melalui library docker-py (waktu habis bahkan setelah kami meningkatkan batas waktu menjadi 2 menit); namun, kami tidak melihat kesalahan saat kami menjalankan melalui Docker CLI (penampung dimulai secara instan). Kami juga hanya melihat masalah di server CI Linux dan bukan di Mac kami. Kami sedang membangun contoh minimal yang dapat direproduksi.

Mengalami masalah ini dengan docker-compose kill pada VM debian pada host macos, instal langsung dari buruh pelabuhan. (Docker versi 18.09.0, build 4d60db4)

Saya mengalami kesalahan yang sama saat memulai buruh pelabuhan dengan log-driver: syslog ketika port rsyslog tidak tersedia.
Error starting container 0ba2fb9540ec6680001f90dce56ae3a04b831c8146357efaab79d4756253ec8b: UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)

memulai ulang Docker bekerja untuk saya.

@ rodrigo-brito memulai ulang bukanlah solusi ...

Terjadi pada saya karena jangkauan port yang besar, ini sebenarnya membuat satu aturan per port ....

Hal yang sama persis bagiku. Setelah error, daemon buruh pelabuhan terus memakan memori sampai habis. Saya perlu systemctl stop docker sebelum sistem saya mati. (Docker versi 18.09.3, build 774a1f4)

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

restart sederhana dari buruh pelabuhan menyelesaikan ini untuk saya ...

Tampaknya masalah tersebut masih ada di versi buruh pelabuhan baru-baru ini. Saya memulai ~ 5 kontainer, dengan yang lambat memiliki mount volume buruh pelabuhan yang mengarah ke berbagi NFS. Tidak ada kontainer yang mengekspos port apapun, apakah seseorang mengetahui apakah ini adalah kesalahan yang valid ( port=None tampak mencurigakan)?

~~~
Klien:
Versi: 18.09.5.0
Versi API: 1.39.0
Go versi: go1.10.8
Git commit: e8ff056dbc
Dibangun: Kam 11 Apr 04:44:28 2019
OS / Arch: linux / amd64
Eksperimental: salah

Server: Mesin Docker - Komunitas
Mesin:
Versi: 18.09.5.0
Versi API: 1.39 (versi minimum 1.12)
Go versi: go1.10.8
Git commit: e8ff056
Dibangun: Kam 11 Apr, 04:10:53 2019
OS / Arch: linux / amd64
Eksperimental: salah
~~~

Menambahkan beberapa keluaran lagi dari --verbose . Saya tidak berpikir ada yang berguna di sini, itu hanya mengatakan untuk waktu yang lama bahwa beberapa operasi pembuatan kontainer menunggu untuk waktu yang lama. Ternyata itu menggunakan polling, karena pesan berikut dicetak sekitar 1x / detik:

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

The localhost / port = Node adalah sedikit red herring menurut saya, karena koneksi dilakukan dengan docker.sock, jadi itu bukan kesalahan nil yang disembunyikan di suatu tempat. Saya pikir ini perlu dilacak di dalam buruh pelabuhan, bukan bahwa penanganan penulisan buruh pelabuhan atas permintaan ini di sini optimal.

Docker-compose sepertinya kehilangan semacam id permintaan yang bisa dicatat, jadi kita akan tahu permintaan mana yang terhenti. Misalnya, saya tahu bahwa container api saya tidak dapat dibuat dalam waktu tunggu, tetapi log permintaan tidak membantu sama sekali. Mungkin orang lain bisa menambahkan beberapa info di sini:

~~~
urllib3.connectionpool._make_request: http: // localhost: Tidak ada "POST /v1.25/containers/create?name=api-memcache HTTP / 1.1" 201 90
urllib3.connectionpool._make_request: http: // localhost: Tidak ada "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: docker create_container -> {'Id': '22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f',
'Warnings': Tidak Ada}
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network -> Tidak ada
compose.cli.verbose_proxy.proxy_callable: docker inspect_container <- ('22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f')
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network <- ('ba67095c5ea718af13a09798bc2f5ab24f5d0b54ce684b6f4cb248ab705df900' links, 'proxy', aliases = ['redis_local = ba67095', 'ipvips = tidak ada, link67095)
urllib3.connectionpool._make_request: http: // localhost: None "GET /v1.25/containers/22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f/json HTTP / 1.1" 200 Tidak ada
urllib3.connectionpool._make_request: http: // localhost: Tidak ada "POST /v1.25/containers/create?name=api HTTP / 1.1" 201 90
compose.cli.verbose_proxy.proxy_callable: docker create_container -> {'Id': '1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec',
'Warnings': Tidak Ada}
compose.cli.verbose_proxy.proxy_callable: docker inspect_container <- ('1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec')
compose.parallel.feed_queue: Tertunda: set ()
urllib3.connectionpool._make_request: http: // localhost: Tidak ada "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
urllib3.connectionpool._make_request: http: // localhost: Tidak ada "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: Tidak ada "GET /v1.25/containers/1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec/json HTTP / 1.1" 200 Tidak ada
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network -> Tidak ada
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network -> Tidak ada
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', aliases = ['comments],' ipvips ', aliases = [' comments], ipvips = None]
compose.cli.verbose_proxy.proxy_callable: docker inspect_container -> JSON ...
urllib3.connectionpool._make_request: http: // localhost : Tidak ada "POST /v1.25/containers/create?name=api-comments-db HTTP / 1.1" 201 90
compose.cli.verbose_proxy.proxy_callable: buruh pelabuhan mulai <- ('ba67095c5ea718af13a09798bc2f5ab24f5d0b54ce684b6f4cb248ab705df900')
compose.parallel.feed_queue: Tertunda: set ()
compose.parallel.feed_queue: Tertunda: 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',
'Warnings': Tidak Ada}
urllib3.connectionpool._make_request: http: // localhost : Tidak ada "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
urllib3.connectionpool._make_request: http: // localhost : Tidak ada "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 -> Tidak ada
compose.parallel.feed_queue: Tertunda: set ()
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network -> Tidak ada
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network <- ('22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f', 'proxy', aliases = ['22bcache_tidak ada, alamat ipv4 =' 22bcache 'tidak ada)
compose.parallel.feed_queue: Tertunda: set ()
urllib3.connectionpool._make_request: http: // localhost : None "GET /v1.25/containers/ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af/json HTTP / 1.1" 200 Tidak ada
urllib3.connectionpool._make_request: http: // localhost : Tidak ada "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: buruh pelabuhan mulai <- ('7d81ef23610f1b8f7ac95837cbf6c9eef977b5b0846fea24be5c7054e471df39')
compose.parallel.feed_queue: Tertunda: set ()
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network -> Tidak ada
compose.cli.verbose_proxy.proxy_callable: docker inspect_container -> JSON ...
urllib3.connectionpool._make_request: http: // localhost : Tidak ada "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 = ['link_v4]', 'proxy', aliases = 'ipv_
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network <- ('ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af', 'proxy')
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network -> Tidak ada
compose.cli.verbose_proxy.proxy_callable: buruh pelabuhan mulai <- ('22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f')
compose.parallel.feed_queue: Tertunda: set ()
urllib3.connectionpool._make_request: http: // localhost: Tidak ada "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
urllib3.connectionpool._make_request: http: // localhost: Tidak ada "POST /v1.25/networks/proxy/connect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network -> Tidak ada
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network -> Tidak ada
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network <- ('ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af', 'proxy', aliases = ['alamat_komentar = d875cc], alamat tautan = d875' alamat tautan ', alamat ipb4' Tidak ada)
compose.cli.verbose_proxy.proxy_callable: buruh pelabuhan mulai <- ('1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec')
urllib3.connectionpool._make_request: http: // localhost: Tidak ada "POST /v1.25/networks/proxy/connect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network -> Tidak ada
compose.cli.verbose_proxy.proxy_callable: buruh pelabuhan mulai <- ('ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af')
compose.parallel.feed_queue: Tertunda: set ()
compose.parallel.feed_queue: Tertunda: set ()
compose.parallel.feed_queue: Tertunda: set ()
compose.parallel.feed_queue: Tertunda: set ()
...
- dihilangkan ~ 30 baris
...
Membuat api-comments ... selesai
compose.cli.verbose_proxy.proxy_callable: docker start -> Tidak ada
compose.parallel.parallel_execute_iter: Pemrosesan selesai: ServiceName (project = 'api', service = 'comments', number = 1)
compose.parallel.feed_queue: Tertunda: set ()
compose.parallel.parallel_execute_iter: Pemrosesan selesai:
compose.parallel.feed_queue: Tertunda: set ()
Membuat api-memcache ... selesai
urllib3.connectionpool._make_request: http: // localhost: Tidak Ada "POST /v1.25/containers/22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f/start HTTP / 1.1" 204 0
compose.cli.verbose_proxy.proxy_callable: docker start -> Tidak ada
compose.parallel.parallel_execute_iter: Pemrosesan selesai: ServiceName (project = 'api', service = 'memcache', number = 1)
compose.parallel.feed_queue: Tertunda: set ()
compose.parallel.parallel_execute_iter: Pemrosesan selesai:
compose.parallel.feed_queue: Tertunda: set ()
compose.parallel.feed_queue: Tertunda: set ()
compose.parallel.feed_queue: Tertunda: set ()
compose.parallel.feed_queue: Tertunda: 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 -> Tidak ada
Membuat api-comments-db ... selesai
compose.parallel.feed_queue: Tertunda: set ()
compose.parallel.parallel_execute_iter: Pemrosesan selesai:
compose.parallel.feed_queue: Tertunda: set ()
compose.parallel.feed_queue: Tertunda: set ()
compose.parallel.feed_queue: Tertunda: set ()
compose.parallel.feed_queue: Tertunda: set ()
compose.parallel.feed_queue: Tertunda: set ()
- dihilangkan ~ 15 baris
Membuat api-redis ... selesai
compose.parallel.feed_queue: Tertunda: set ()
urllib3.connectionpool._make_request: http: // localhost: Tidak Ada "POST /v1.25/containers/ba67095c5ea718af13a09798bc2f5ab24f5d0b54ce684b6f4cb248ab705df900/start HTTP / 1.1" 204 0
compose.cli.verbose_proxy.proxy_callable: docker start -> Tidak ada
compose.parallel.parallel_execute_iter: Pemrosesan selesai: ServiceName (project = 'api', service = 'redis', number = 1)
compose.parallel.feed_queue: Tertunda: set ()
compose.parallel.parallel_execute_iter: Pemrosesan selesai:

compose.parallel.feed_queue: Tertunda: set ()

- 100+ baris dihilangkan
compose.parallel.parallel_execute_iter: Gagal: ServiceName (project = 'api', service = 'api', number = 1)
compose.parallel.feed_queue: Tertunda: set ()

EROR: untuk api UnixHTTPConnectionPool (host = 'localhost', port = None): Waktu pembacaan habis. (baca timeout = 60)
compose.parallel.parallel_execute_iter: Gagal:
compose.parallel.feed_queue: Tertunda: set ()

EROR: untuk api UnixHTTPConnectionPool (host = 'localhost', port = None): Waktu pembacaan habis. (baca timeout = 60)
compose.cli.errors.log_timeout_error: Permintaan HTTP membutuhkan waktu terlalu lama untuk diselesaikan. Coba lagi dengan --verbose untuk mendapatkan informasi debug.
Jika Anda mengalami masalah ini secara teratur karena kondisi jaringan yang lambat, pertimbangkan untuk menyetel COMPOSE_HTTP_TIMEOUT ke nilai yang lebih tinggi (nilai saat ini: 60).
~~~

@titpetric dapat mengonfirmasi bahwa saya juga mengalami masalah ini.

IMHO masalah ini ada di sisi buruh pelabuhan, bukan di sisi buruh pelabuhan. Seseorang harus mengaktifkan logging debug di docker deamon dan menunjukkan penundaan di sana, dan mengajukan masalah ke upstream. Saya tidak yakin seseorang dapat mereproduksi ini dengan mudah tanpa itu.

Jika seseorang bersedia meluangkan waktu, saya sarankan untuk mereplikasi ini dengan membuat folder yang dimuat penuh untuk volume mount (sesuatu dengan sekitar 100000+ file / folder harus dilakukan), untuk melihat apakah reproduksi masalah yang andal bisa tercapai. Sepertinya daemon buruh pelabuhan, atau mount kernel bind itu sendiri, menyimpan beberapa data inode sebelumnya. Yang ... sangat disayangkan.

Sebuah tcpdump mungkin juga mengkonfirmasi hal ini dalam kasus sistem berkas jaringan (samba, nfs).

Kesalahan yang sama persis di sini

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)

Memulai ulang Docker juga memperbaikinya untuk saya.

Restart bukanlah perbaikan guys .....
Bagaimana cara menghindari ini untuk selamanya?

Menghadapi masalah yang sama. Mendapatkan error di bawah ini untuk semua container buruh pelabuhan dari rekan organisasi:

EROR: untuk DNS UnixHTTPConnectionPool (host = 'localhost', port = None): Waktu pembacaan habis. (baca timeout = 60)

Apakah karena beberapa port mismatch atau assignment di file compose?

Ya, saya sendiri selalu mengalami masalah ini. Saya setuju memulai ulang bukanlah solusi, tetapi sepertinya tidak ada yang bisa melakukan trik: /

Sekadar info, dengan kasus saya hanya mencoba ulang dengan penulisan galangan cenderung terselesaikan
Itu. Saya rasa saya tidak pernah memulai ulang dockerd, masalah ini tidak berlanjut selama
saya.

Pada hari Jumat, 2 Agustus 2019 pukul 13.39 Alex [email protected] menulis:

Ya, saya sendiri selalu mengalami masalah ini. Saya setuju memulai ulang tidak
solusi, tapi sepertinya tidak ada yang berhasil: /

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/docker/compose/issues/3927?email_source=notifications&email_token=AABY7EH4MVKGI56ZLEIUV5TQCQMHBA5CNFSM4CPDX2D2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3NQBTI#issuecomment-517669069 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/AABY7EA3NTUP5SNZRTFWFEDQCQMHBANCNFSM4CPDX2DQ
.

Saya juga menghadapi masalah ini :(
UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)

Masalah yang sama di sini, juga memulai ulang Docker benar-benar macet. Satu-satunya cara adalah untuk membunuh Docker / atau restart tapi itu tidak bisa menjadi solusi.

@bitbrain yup ini telah terjadi pada saya juga untuk beberapa waktu.

Saya menemukan solusi yang bagus untuk ini (di MacOS)

Alasan mengapa ini terus terjadi pada saya adalah karena Docker memiliki sedikit memori yang tersedia.

Meningkatkan memori dari 2GB hingga 8GB memecahkan masalah bagi saya.

Saya mendapatkan kesalahan ini setelah menjalankan docker-compose up dan kemudian docker-compose down beberapa kali. Saya mencoba segalanya di utas ini. Menabrak sumber daya, memulai ulang mac saya dan menginstal ulang Docker terbaru. Saya bisa mendapatkan docker-compose up berjalan lagi setelah me-reboot kotak saya tetapi setelah bersepeda perintah tersebut beberapa kali akan kembali ke kesalahan ini dan saya tidak bisa menjalankan docker-compose up .

Masalah saya tampaknya berkonflik dengan layanan lain ( pow ) yang mengikat ke port 80 ketika salah satu kontainer saya juga mengikat ke port 80. Saya mencopot pow dan tidak mengalami masalah selama tiga hari sekarang.

3 tahun membuka tiket ini dan masih belum terselesaikan. Masalah masih terjadi meskipun kami meningkatkan koneksi klien menjadi 120 detik.

baru saja terjadi ke server kami, buka masalah sejak 2016, wtf

memulai ulang Docker bekerja untuk saya.

@ rodrigo-brito memulai ulang bukanlah solusi ...

lelaki ku.

Juga mengalami ini sekarang. Liar.

Memiliki masalah yang sama saat mencoba docker-compose atau docker-compose down. Saya menyelesaikannya dengan menghentikan layanan mysqld dan setelah container habis, saya memulai mysql. RAM menggunakan 20%.

Menjalankan Komunitas Desktop Docker untuk Mac v2.1.0.5

Saya mengalami masalah ini dan menyelesaikannya dengan meningkatkan jumlah memori yang dialokasikan ke Docker (dan mengurangi jumlah CPU).
Anda dapat melakukan ini di Docker -> Preferensi -> Lanjutan.
Saya beralih dari 8 CPU & 2GB RAM menjadi 4 CPU & 16GB RAM untuk pengaturan khusus saya.

Mengalami masalah ini di Ubuntu Server 18.04 LTS. Memulai ulang buruh pelabuhan tidak memperbaiki masalah, demikian juga pengaturan variabel lingkungan. Ada ide?

@bpogodzinski sudahkah Anda mencoba untuk meningkatkan pengaturan Memori Anda di Docker? Saya meningkatkannya dari 2GB menjadi 8GB dan itu memperbaiki masalah saya.

Secara umum, masalah ini tampaknya terjadi ketika kontainer membutuhkan lebih banyak memori daripada memori yang tersedia yang dikonfigurasi di Docker dan kemudian barang-barang hang.

Kami mengalami masalah ini dan tampaknya (bagi kami) terkait dengan volume bernama dengan banyak file. Saya tidak memahaminya, tetapi bagi kami kasus docker-compose (diedit untuk singkatnya) yang memiliki layanan:

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

   volumes:
       - serviceA_volume:

Di dalam Dockerfile untuk layanan A adalah perintah yang tampaknya tidak berbahaya dan tidak efektif:

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

Perhatikan bahwa ini mengubah pemilik secara rekursif di / srvA / folder yang dalam volume bernama adalah sistem file besar dengan 100K file. Namun, ini terjadi saat gambar dibuat dan folder itu kosong. Tampaknya menggunakan volume bernama mewarisi izin dari file lokal gambar dan kemudian hasil untuk mengubah izin volume bernama.

Ini cukup rumit dan mungkin bukan masalah yang sama yang dialami orang lain tetapi itu adalah masalah kami (mengubah garis akan mematikan kesalahan). Hasilnya adalah bahwa waktu tunggu http ini mungkin disebabkan oleh berbagai penyebab.

Memulai ulang buruh pelabuhan tidak pernah menyelesaikan masalah dalam kasus saya, meningkatkan sumber daya pasti berhasil.

Dari pengalaman saya, masalah ini sering muncul pada instance cloud kecil di mana jumlah RAM baik-baik saja selama berfungsi biasa tetapi terbukti tidak mencukupi selama operasi docker atau docker-compose. Anda dapat dengan mudah meningkatkan RAM, tetapi itu mungkin akan meningkatkan biaya VM kecil secara drastis.

Dalam setiap kasus, menambahkan partisi swap atau bahkan file swap memecahkan masalah ini untuk saya!

Baru saja terjadi pada saya di raspberry pi. Tidak ada volume dengan banyak file atau apapun.
Sebenarnya saya telah memijahkan wadah ini pada raspberry itu untuk sementara waktu sekarang (satu atau dua tahun lol).
Tidak yakin apa yang berubah.
Sepertinya sedikit "tiba-tiba".

Masalah masih muncul di desktop buruh pelabuhan 2.2.0.3 di MacOs 🙁

Saya menyelesaikan masalah saya dengan perintah berikut:
docker volume prune
docker system prune
(hanya satu dari perintah ini yang mungkin cukup, tetapi tidak dapat mereproduksi untuk saat ini ...)

Saya menyelesaikan masalah saya dengan perintah berikut:
docker volume prune
docker system prune
(hanya satu dari perintah ini yang mungkin cukup, tetapi tidak dapat mereproduksi untuk saat ini ...)

Solusi @amaumont membantu, meskipun saya pikir ini akan terus datang kembali dari waktu ke waktu.
Seperti yang orang lain katakan, memulai kembali buruh pelabuhan bukanlah solusi yang tepat, itu bandaid.

Kami juga mengalami banyak masalah dengan docker-compose.

Setelah menyetel MaxSessions 500 di sshd_config (lihat # 6463) sekarang kita juga mendapatkan waktu tunggu pembacaan.
Menyetel kedua batas waktu ke 120 detik menyelesaikan masalah untuk lari DOCKER_HOST=xxx<strong i="8">@yyy</strong> docker-compose up -d .

Selama proses kedua, beban mesin naik hingga 30 (sic!) Sebelum perintah docker-compose gagal karena waktu tunggu. Restart buruh pelabuhan tidak menyelesaikan masalah ini, bahkan tidak untuk sementara.
Server adalah instance AWS EC2 dengan cukup CPU / Disk / NetIO dll, file penulisan menyertakan 1 traefik dan 3 layanan dengan mailhog, jadi tidak ada yang istimewa di sini. Menjalankan docker-compose up -d dengan file docker-compose.yml yang sama langsung di server bekerja dengan andal dan seperti yang diharapkan.
Berjalan dengan --verbose menunjukkan lebih dari seribu baris berturut-turut yang berisi compose.parallel.feed_queue: Pending: set() .

Saya akan mencoba untuk melakukan rsync file docker-compose ke server jarak jauh dan menjalankan docker-compose langsung di mesin itu sebagai solusi.

Bagi saya, itu membantu untuk memulai ulang buruh pelabuhan.

Sering terjadi saat saya mencoba melakukan push ke registri pribadi saya dari pipeline bitbucket. Bekerja dengan baik saat mendorong dari PC lokal.
Restart buruh pelabuhan dapat membantu untuk sementara waktu, namun "sementara" ini berlangsung selama 10 menit maks: c

upd. pengaturan DOCKER_CLIENT_TIMEOUT dan COMPOSE_HTTP_TIMEOUT sepertinya membantu, tapi saya tidak tahu untuk berapa lama

Saya mulai mendapatkan ini sejak beralih ke Docker Edge dengan Caching aktif

Ini telah terjadi cukup konsisten untuk saya sejak saya mulai menggunakan Docker 2-3 tahun yang lalu. Setelah container berjalan beberapa saat, container menjadi zombie dan seluruh mesin Docker perlu di-restart agar semuanya menjadi responsif lagi. Ini terasa seperti kebocoran sumber daya, karena waktu menganggur tampaknya sangat relevan untuk perilaku yang dialami.

Jika tidak ada kontainer yang berjalan, atau hanya berjalan dalam waktu singkat, semuanya tampaknya berfungsi dengan baik selama berhari-hari atau berminggu-minggu. Tetapi segera setelah saya membiarkan wadah berjalan selama beberapa jam, itu menjadi tidak responsif, saya harus menghentikannya secara paksa di baris perintah dan setiap upaya untuk berkomunikasi dengan docker atau docker-compose hanya gagal dengan batas waktu. Mulai ulang adalah satu-satunya solusi yang berfungsi.

Keluaran 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

Keluaran 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

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

Saya menghadapi masalah yang sama, bahkan saya meningkatkan sumber daya dari RAM 4GB, swap 1GB menjadi RAM 6GB, swap 2GB.

Saya juga menghadapi masalah yang sama

juga mengalami masalah yang sama

Saya telah menghadapi masalah yang sama di Ubuntu 18.04 LTS (RAM 8 GB) menggunakan HTTPS.

Saya dapat menghasilkan kontainer dengan docker-compose up , namun setelah diterapkan saya tidak dapat menghentikan kontainer dengan docker-compose down . Memulai ulang daemon buruh pelabuhan atau me-reboot VM terbukti tidak efektif. Menambahkan variabel lingkungan batas waktu ( DOCKER_CLIENT_TIMEOUT , COMPOSE_HTTP_TIMEOUT ) juga tidak melakukan apa pun.

Saya dapat berinteraksi dengan dan menghentikan container satu per satu, saya dapat memeriksa container, melampirkannya, dan apa pun, tetapi saya tidak dapat menghentikan atau membunuhnya menggunakan perintah docker-compose .

Pesan kesalahannya selalu sama:

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

Saya mengalami masalah yang sama ketika saya memiliki yang berikut di docker-compose.yml saya:

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

Kesalahan hilang ketika saya menambahkan tanda kutip sekitar "10". Ini dinyatakan dalam dokumen bahwa nilai untuk max-file dan max-size harus berupa string, tetapi tetap. Pesan kesalahannya cukup menyesatkan.

Saya mengalami masalah yang sama ketika saya memiliki yang berikut di docker-compose.yml saya:

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

Kesalahan hilang ketika saya menambahkan tanda kutip sekitar "10". Ini dinyatakan dalam dokumen bahwa nilai untuk max-file dan max-size harus berupa string, tetapi tetap. Pesan kesalahannya cukup menyesatkan.

Anda menyelamatkan hari saya. Terima kasih banyak!

Saya mengalami masalah yang sama ketika saya memiliki yang berikut di docker-compose.yml saya:

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

Kesalahan hilang ketika saya menambahkan tanda kutip sekitar "10". Ini dinyatakan dalam dokumen bahwa nilai untuk max-file dan max-size harus berupa string, tetapi tetap. Pesan kesalahannya cukup menyesatkan.

Saya sedang mengkonfigurasi driver logging di tingkat daemon buruh pelabuhan. Saya menggunakan fluentd sebagai driver logging saya, jadi sayangnya perbaikan ini tidak akan berhasil untuk saya. = /

mencoba ini

export DOCKER_CLIENT_TIMEOUT=120
export COMPOSE_HTTP_TIMEOUT=120

dan tampaknya masalah tersebut telah diperbaiki untuk saat ini

Solusi lain yang disebutkan orang di utas ini:

• Mulai ulang Docker
• Tingkatkan CPU & memori Docker

Tidak ada yang berhasil untuk saya, kecuali opsi batas waktu, pujian untuk Anda.

Saya mendapatkan ini sejak saya mulai menggunakan direktori yang dipasang NFS di dalam salah satu wadah saya. Direktori yang dipasang di NFS berada pada tautan yang lambat (di lokasi terpencil yang memiliki koneksi bandwidth rendah). Mungkinkah itu masalahnya?

Saya sangat sering mengalami ini di Mac, Docker 2.4.0.0, dalam dua proyek berbeda dengan konfigurasi docker-compose.yml yang berbeda. Saya tidak ingat itu pernah terjadi sebelumnya ~ 1 minggu yang lalu ketika saya meningkatkan ke 2.4.0.0. Apakah ada regresi?

Saya telah mencoba meningkatkan batas waktu menjadi 600, meningkatkan RAM menjadi 16GB & menukar menjadi 4GB, memulai ulang Docker, memulai ulang seluruh Macbook saya, sepertinya tidak ada yang berfungsi, kecuali mencoba secara acak lagi dan lagi kemudian sesekali akan berfungsi. Tapi kemudian lain kali saya perlu memulai ulang atau membangun kembali kontainer, masalah yang sama :(

Mulai melihat ini dengan 2.4.0.0 di Mac juga. Solusi bagi saya adalah memulai ulang buruh pelabuhan tetapi akan mengalaminya lagi nanti.

Sama disini! Dengan update ke 2.4.0 setup kami terkadang tidak dimulai sama sekali dengan kesalahan Read timed out. disebutkan, terkadang hanya beberapa kontainer yang memulai, yang lain menampilkan kesalahan ini. Saya sudah memikirkan tentang penurunan peringkat!

Sekadar menyebutkan: Masalah ini memengaruhi kedua pengaturan yang menggunakan saham NFS serta proyek yang menggunakan volume terpasang "normal"

Masalah yang sama di sini, juga di mac dan setelah pembaruan 2.4.0. Saya sedang mencoba jika menurunkan versi membantu.

Perbarui: menurunkan ke versi sebelumnya, menghapus cache, dan membangun kembali memperbaiki masalah.

Saya juga baru-baru ini mulai melihat masalah ini (Mac, 2.4.0.0), padahal saya belum pernah melihatnya sebelumnya. Menjalankan docker image prune membuat masalah hilang selama beberapa hari, tetapi sekarang masalah itu kembali lagi.

Juga mulai sering mengalami kesalahan batas waktu ini sejak pembaruan 2.4.0 (di Mac OS Mojave 10.14.5)

Juga melihat ini dengan frekuensi yang meningkat sejak memperbarui ke Docker Desktop 2.4.0.0 (48506) di MacOS Catalina.

Saya mendapatkan masalah batas waktu yang sama sejak 2.4.0.0 di Mac OS. Saya tidak pernah mengalami masalah ini sebelumnya.
Saya mencoba edge build 2.4.1.0 (48583) tetapi saya masih memiliki masalah yang sama.

Saya mendapat masalah yang sama dan me-reboot buruh pelabuhan memperbaikinya untuk MacOs Catalina (10.15.5) dan buruh pelabuhan versi 2.4.0.0

Sama di sini, tidak ada masalah sebelum memperbarui ke desktop Docker 2.4.0.0.
Memulai ulang desktop Docker berfungsi, tetapi itu hanya solusi.

Sama di sini, juga dimulai dengan v2.4.0

Perbarui: menurunkan ke versi sebelumnya, menghapus cache, dan membangun kembali memperbaiki masalah.

Akan mencobanya. Bahkan tidak yakin bagaimana itu dilakukan. Saya berasumsi itu dengan mencopot pemasangan dan mengunduh versi sebelumnya?

Ya, saya menghapus instalan 2.4 dan mengunduh / menginstal ulang 2.3. Sekarang berhasil, saya dapat memulai container saya seperti biasa.
Saya mendapatkan 2.3 dari sana: https://docs.docker.com/docker-for-mac/release-notes/#docker -desktop-community-2302

Yup, dapat dipastikan itu membuat perbedaan bagi saya juga. Jelas v2.4 yang harus disalahkan di sini.

Jika Anda mengalami masalah ini secara teratur karena kondisi jaringan yang lambat, pertimbangkan untuk menyetel COMPOSE_HTTP_TIMEOUT ke nilai yang lebih tinggi (nilai saat ini: 60).

Bagaimana tepatnya 1Gbps adalah jaringan yang lambat?

Menurunkan peringkat juga berhasil untuk saya. Bagi mereka yang mengelola Docker melalui Homebrew

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

Jika Anda mengalami masalah ini secara teratur karena kondisi jaringan yang lambat, pertimbangkan untuk menyetel COMPOSE_HTTP_TIMEOUT ke nilai yang lebih tinggi (nilai saat ini: 60).

Bagaimana tepatnya 1Gbps adalah jaringan yang lambat?

Dalam kasus saya, ini terjadi karena drive jaringan yang dipasang di NFS.
Akar penyebab "lambat" kecepatan jaringan adalah penggunaan NFS, bukan kecepatan link fisik.
Tapi itu jelas menunjukkan ada masalah dalam implementasi dan saya akan terkejut jika mengubah HTTP_TIMEOUT akan menyelesaikannya.

Sama disini. Perlambatan yang signifikan dalam pembuatan kontainer, mengakibatkan kesalahan waktu tunggu HTTP yang disebutkan di atas di Docker untuk Mac v2.4. Menyetel COMPOSE_HTTP_TIMEOUT = 120 berhasil, tetapi kelambatan pembuatan penampung masih menjadi masalah baru. Mendowngrade ke v2.3 juga memperbaiki ini.

Saya dapat mengonfirmasi masalah yang sama sejak saya menginstal di Docker untuk Mac v2.4.
Saya juga dapat mengonfirmasi peningkatan yang signifikan dari RAM dan konsumsi CPU bahkan di saat-saat idle, hanya dengan daemon Docker berjalan. Tapi saya rasa itu tidak ada hubungannya dengan paket compose itu sendiri.

Saya memiliki masalah yang sama. Menghapus 2.40 dan menginstal 2.3 dari tautan yang disebutkan oleh @ddesrousseaux dan saya tidak lagi memiliki kelambatan super atau batas waktu saat memulai kontainer.

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

Masalah ini masih ada di Docker v. 2.4.3.0 .

Saya juga telah menurunkan versi ke 2.3 dari 2.4 untuk mengatasi masalah kelambatan masif dalam rilis 2.4. Senang memberikan log apa pun yang mungkin berguna untuk men-debug apa yang terjadi di sini.

Menggemakan hal di atas, ini mulai terjadi di 2.4.2.x untuk saya. Sesuatu berubah dalam peningkatan dari 2.3.

Saya melakukan beberapa pengujian di lingkungan Linux, dan memiliki masalah serupa. Saya menginstal biner docker-compose terbaru (v1.27.4) dan memiliki masalah batas waktu yang sama seperti yang kalian laporkan.

Setelah melakukan downgrade ke 1.27.2, hal yang sama tersedia di Docker untuk Mac 2.3, masalahnya telah hilang.

Masalah yang sama dengan versi saat ini di Ubuntu 20.04.

Masalah saya adalah saya menginstal buruh pelabuhan dan buruh pelabuhan-menulis dengan snap dan apt. Saya mencopotnya, mem-boot ulang dan kemudian mengikuti instruksi pemasangan resmi di https://docs.docker.com/engine/install/ubuntu/ dan https://docs.docker.com/compose/install/

Saya masih sering mengalami kesalahan waktu tunggu sejak pembaruan 2.4.0 yang masih belum diperbaiki di 2.5.0

Ya, sama saja di sini. Itu bekerja dengan baik untuk saya selama 2 tahun terakhir. Tapi 2 bulan yang lalu tiba-tiba ketika saya ingin 1 contoh dan memulai proyek buruh pelabuhan lain itu melempar:
untuk apache UnixHTTPConnectionPool (host = 'localhost', port = None): Waktu pembacaan habis.

Memulai ulang Docker memperbaiki masalah. Tetapi sangat menyakitkan ketika saya harus beralih antar proyek beberapa kali dalam 1 hari

Mengalami masalah yang sama sejak 2.4, 300% cpu setiap saat, 2.5 tidak membantu, diturunkan kembali ke 2.3 dan semuanya baik-baik saja. Ini di macbook terbaru w / i7 cpu dan 32g ram

Saya baru saja memutakhirkan ke Docker terakhir untuk versi Mac (v2.5.0.1) dan masalahnya sepertinya sudah terpecahkan.
Tidak ada lagi kesalahan UnixHTTPConnection , dan tidak ada lagi penggunaan CPU 100%.

Tidak yakin apakah ada orang lain yang bisa mengonfirmasi itu.

Bagaimana cara kamu mendapatkan itu? Membuka Docker di Mac dan melakukan "Check for Updates" tetap menunjukkan bahwa saya memiliki yang terbaru, 2.4.2.0.

Saya baru saja memutakhirkan ke Docker terakhir untuk versi Mac (v2.5.0.1) dan masalahnya sepertinya sudah terpecahkan.
Tidak ada lagi kesalahan UnixHTTPConnection , dan tidak ada lagi penggunaan CPU 100%.

Tidak yakin apakah ada orang lain yang bisa mengonfirmasi itu.

Saya baru saja mengalami masalah di v2.5.0.1. Memulai ulang buruh pelabuhan tampaknya (setidaknya untuk sementara) menyelesaikan masalah.

Bagaimana cara kamu mendapatkan itu? Membuka Docker di Mac dan melakukan "Check for Updates" tetap menunjukkan bahwa saya memiliki yang terbaru, 2.4.2.0.

Saya tidak dapat menampilkan tangkapan layar apa pun karena saya sudah memutakhirkan, tetapi saya pikir Anda mungkin mengalami masalah saat mendapatkan pembaruan dari komputer Anda, karena sudah ada versi v2.5.0 sebelumnya yang tersedia selama lebih dari seminggu.

Anda dapat memeriksanya di catatan rilis Docker untuk Mac (dan ambil penginstal baru dari sana).

Saya menjalankan Edge. Itu mungkin menjelaskannya.

Dapat mengonfirmasi bahwa v2.5.0.1 setidaknya sedikit lebih baik. Tidak mendapatkan waktu tunggu di setiap boot lagi, dan belum mengalaminya sejak memperbarui pagi ini. Waktu boot kontainer masih tampak jauh lebih lambat dari 2.3.

Sunting: baru saja mengalami kesalahan batas waktu lagi, setelah sekitar 4 atau 5 memulai ulang proyek penulisan galangan saya. Juga mengalami kesalahan baru dengan 2.5.0.1: Cannot start service <container name>: error while creating mount source path <local mount path>: mkdir <local mount path>: file exists

Dapat mengonfirmasi bahwa v2.5.0.1 setidaknya sedikit lebih baik. Tidak mendapatkan waktu tunggu di setiap boot lagi, dan belum mengalaminya sejak memperbarui pagi ini. Waktu boot kontainer masih tampak jauh lebih lambat dari 2.3.

Sunting: baru saja mengalami kesalahan batas waktu lagi, setelah sekitar 4 atau 5 memulai ulang proyek penulisan galangan saya. Juga mengalami kesalahan baru dengan 2.5.0.1: Cannot start service <container name>: error while creating mount source path <local mount path>: mkdir <local mount path>: file exists

Oke, saya juga masih menghadapi beberapa masalah dengan versi 2.5.0.1. Penggunaan CPU masih terlalu tinggi dibandingkan dengan v2.3.x, dan kecepatannya juga lumayan lambat.

Adakah orang dari tim Docker yang mengetahui dan mempertimbangkan hal ini?

Tuhan, 4 tahun berlalu, masalah ini masih belum terselesaikan, dan itu terjadi pada saya sepanjang waktu