Compose: UnixHTTPConnectionPool (host = 'localhost'، port = None): انتهت مهلة القراءة. (مهلة القراءة = 60)

حاولت هذا

export DOCKER_CLIENT_TIMEOUT=120
export COMPOSE_HTTP_TIMEOUT=120

ويبدو أنه يعمل على حل المشكلة في الوقت الحالي

حلول أخرى ذكرها الأشخاص في هذا الموضوع:

• أعد تشغيل Docker
• زيادة Docker CPU والذاكرة

هل يحدث ذلك إذا قمت بإيقاف تشغيل WiFi الخاص بك؟ يمكن أن تكون مرتبطة بـ https://github.com/docker/docker-py/issues/1076.

نظرية أخرى ، إذا تم تمكين tty: True لخدمتك ، فيمكن أن تكون # 3106

أرى نفس المشكلة تمامًا مع أحدث إصدار تجريبي لنظام التشغيل Mac. نفس الخطأ إذا قمت بتشغيل docker-compose create

هل يمكن أن يكون هذا مرتبطًا بوجود طبقة واحدة كبيرة جدًا في الصورة؟ (عملية npm install طويلة جدًا تستغرق حوالي دقيقة ليتم تسويتها في طبقة عندما ينشئ عامل الإرساء الصورة)

نلاحظ أيضًا هذه المشكلة باستخدام ملف إنشاء عامل الإرساء مع 6 حاويات [إصدار docker-compose 1.8.1، build 878cff1] على كل من windows و mac [الإصدار 1.12.2-rc1-beta27 (الإصدار: 12496)
179c18cae7]

يبدو أن زيادة الموارد المتاحة لرسو السفن تقلل من فرصة حدوثها (كما هو الحال مع تمديد متغيرات المهلة) ، ولكن لم يتم القضاء عليها مطلقًا.

لدينا أيضًا بعض الطبقات الكبيرة (240 ميجابايت هو الأكبر ، أمر تثبيت الحزمة الرئيسي) ونحن ملزمون بدليل مضيف به 120 ميجابايت من الملفات عبر بضع حاويات.

من خلال محاولات مختلفة للتغلب على هذا ، وجدت شيئًا قد يلقي بعض الضوء على إصلاح محتمل:

في البداية بدا السيناريو الخاص بي مثل هذا قليلاً:

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

تضمن المسار المثبت لدي العديد من الدلائل التي تحتوي على ملفات كبيرة وثابتة لم أكن أحتاجها حقًا للتثبيت من حيث إعادة تحميل الكود. لذلك انتهى بي الأمر بالمبادلة بشيء مثل هذا:

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

هذا استبعاده من وقت تصاعد كل ما عندي من الملفات ثابت كبيرة، الأمر الذي جعل بداية الطريق خدمة أسرع.

ما أفهمه من هذا هو: كلما زاد عدد الملفات التي تقوم بتحميلها ، خاصةً كلما كانت أكبر (الصور في ميغابايت بدلاً من الملفات المصدر في Bs / KBs) ، تزداد أوقات التحميل كثيرًا.

أتمنى أن يساعدك هذا

+1
أرى مشكلة المهلة هذه كل أسبوع ، عادةً بعد عطلة نهاية أسبوع خاملة ، بينما كنت أحاول الاتصال بحاوياتي ، انتهت المهلة ...
لا بد لي من إنهاء عملية تشغيل عامل الإرساء وإعادة تشغيله للعمل حول ...

+1
يحدث ذلك لي في كل مرة أحاول فيها إعادة تشغيل الحاويات لأنها لم تعد تستجيب بعد يوم. لست متأكدًا مما إذا كانت حالتي تتعلق بالتركيب لأنني أحاول إيقاف الحاويات.

يحدث مع كوناتينر nginx ، Up 47 hours .
Docker لنظام التشغيل mac Version 17.03.1-ce-mac12 (17661) Channel: stable d1db12684b .

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

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

$ docker-compose kill nginx
Killing project_nginx_1 ... 

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

شكرًا gvilarino ، أعتقد أن تراكم الملفات الكبيرة هو سبب هذه المشكلة على خادم

ومع ذلك ، أتساءل لماذا يكون التثبيت بطيئًا في Docker؟ ربما يؤدي إلى نسخ القرص؟ لكن لماذا؟

cherrot لن أقول إنني بارع للغاية في هذا الموضوع ، لكنني أعتقد أن هذا له علاقة ببرنامج تشغيل التخزين الذي يستخدمه Docker وكيف يعمل داخليًا للحفاظ على الطبقات بالترتيب. استخدم docker info لمعرفة برنامج تشغيل التخزين الذي يستخدمه برنامجك الخفي (ربما aufs ، وهو أبطأ) واعتمادًا على نظام التشغيل المضيف ، يمكنك تغييره بحيث يكون هناك شيء آخر ( overlay كونها الخيار الأفضل، إذا كان معتمدا). هناك بدائل أسرع مثل LCFS لكنها غير مدعومة تجاريًا بواسطة Docker لذا ستكون بمفردك هناك.

نحن نشهد أيضًا هذا الوقت المستقطع. يبدو أيضًا أنه بسبب الأحجام التي نستخدمها.

نحتاج إلى بعض الحاويات للوصول إلى بعض مشاركات شبكة SMB. لذلك قمنا بتركيب هذه المشاركة على النظام المضيف ، وقمنا بتثبيتها داخل الحاوية. لكن في بعض الأحيان ، يتوقف الاتصال بين خادم Windows ومضيف Linux لدينا (راجع https://access.redhat.com/solutions/1360683) وهذا يمنع بدء أو إيقاف الحاوية الخاصة بنا والتي تنتهي مهلتها بعد فترة.

ليس لدي إصلاح حتى الآن. أنا أبحث عن مكون إضافي لوحدة التخزين يدعم SMB ، أو لجعل مشكلة اتصال المماطلة تختفي على SMB. لكن لا يوجد حل حقيقي حتى الآن.

FWIW: بالنسبة للأشخاص الذين وصلوا إلى هنا من خلال محرك البحث لإيجاد حلهم ، تمكنت من إصلاح هذا ببساطة عن طريق _ هل حاولت إيقاف تشغيله وتشغيله مرة أخرى؟ _ لقد أعدت تشغيل عميل Docker Mac OS الخاص بي.

+1 على ذلك ، أقوم بإجراء اختبار الإجهاد على المثيل الخاص بي الذي يعمل على تشغيل 4 حاويات ويتوقف عامل الإرساء حتى مقابل docker ps -a لذلك أحاول إعادة تشغيل الحاويات ولكني أحصل
UnixHTTPConnectionPool(host='localhost', port=None): Read timed out و

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

فقط في حالة إعادة تشغيل خدمة docker يبدو أنه قد تم حلها ، أي أفكار؟

+1

إعادة تشغيل web-jenkins_jenkins_1 ...

خطأ: لـ web-jenkins_jenkins_1 UnixHTTPConnectionPool (host = 'localhost' ، port = None): انتهت مهلة القراءة. (مهلة القراءة = 130)
خطأ: استغرق طلب HTTP وقتًا طويلاً حتى يكتمل. أعد المحاولة باستخدام --verbose للحصول على معلومات التصحيح.
إذا واجهت هذه المشكلة بانتظام بسبب ظروف الشبكة البطيئة ، ففكر في تعيين COMPOSE_HTTP_TIMEOUT على قيمة أعلى (القيمة الحالية: 120).

أعد تشغيل عامل ميناء ، تم حلها. لكن كل يوم أحتاج إلى إعادة التشغيل

إعادة تشغيل Docker يعمل بالنسبة لي.

+1 إعادة تشغيل عامل الإرساء عملت معي أيضًا.

واجهت هذه المشكلة أثناء إنشاء صورة Docker كبيرة جدًا ثم حاولت دفعها إلى سجل بعيد. لم تكن إعادة تشغيل Docker حلاً قابلاً للتطبيق ، لكن إجابة bodaz تناولتها لي: https://github.com/docker/compose/issues/3927#issuecomment -245948736

@ rodrigo-brito - لقد تلقيت هذا الخطأ لبعض الوقت الآن وأعيد تشغيل docker deamon أدى إلى حل المشكلة - ليس أكثر منذ أن أضفت خدمة أخرى إلى مشروعي.

لدي نفس المشكلة ، ولكن لدي إعداد بسيط إلى حد ما.
لدي حاوية واحدة فقط من نوع verdaccio 3 استنادًا إلى صورة بحجم 164 ميغابايت.
هذا محبط للغاية: /

أنا أستخدم MBP Pro 13 من عام 2015

حدث لي بسبب نطاق منفذ كبير ، فإنه في الواقع ينشئ قاعدة واحدة لكل منفذ ...

sudo service docker restart البسيط يحل هذا الأمر بالنسبة لي باستمرار في كل مرة يحدث فيها.

حدث معي أيضًا ، في حالتي docker-compose push (ولا حتى أحاول تشغيل التطبيق) على Azure DevOps.

لا تستخدم تصميماتي الأخرى إنشاء عامل الإرساء ولكن استخدام عادي docker push

لقد قمت بإزالة إصدار kubuntu 18.04.1 docker.io من Docker وقمت بتثبيت docker-ce 18.09.0
اختفت المشكلة.

لقد قمت للتو بتحويل خطوة الدفع docker-compose إلى دفعات فردية بدلاً من ذلك.

نشاهد هذه المهلة عند تشغيل حاوية عبر docker-compose أو عبر مكتبة docker-py (تنتهي المهلة حتى بعد أن نرفع المهلة إلى دقيقتين) ؛ ومع ذلك ، لا نرى الخطأ عند تشغيلنا عبر Docker CLI (تبدأ الحاوية على الفور). نرى أيضًا المشكلة على خادم Linux CI فقط وليس على أجهزة Mac الخاصة بنا. نحن نعمل على بناء مثال بسيط قابل للتكرار.

وجود هذه المشكلة مع docker-compose kill على debian VM على مضيف macos ، قم بالتثبيت مباشرة من docker. (إصدار Docker 18.09.0 ، الإصدار 4d60db4)

لقد واجهت نفس الخطأ عند بدء تشغيل عامل الإرساء باستخدام برنامج تشغيل السجل: سجل النظام عندما كان منفذ سجل rsyslog غير متاح.
Error starting container 0ba2fb9540ec6680001f90dce56ae3a04b831c8146357efaab79d4756253ec8b: UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)

إعادة تشغيل Docker يعمل بالنسبة لي.

@ إعادة تشغيل rodrigo-brito ليس حلاً ...

حدث لي بسبب نطاق منفذ كبير ، فإنه في الواقع ينشئ قاعدة واحدة لكل منفذ ...

نفس الشيء بالضبط بالنسبة لي. بعد الخطأ ، يواصل Docker daemon أكل الذاكرة حتى نفادها. أحتاج إلى systemctl stop docker قبل أن يموت نظامي. (إصدار Docker 18.09.3 ، الإصدار 774a1f4)

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

إعادة تشغيل عامل ميناء حل هذا بالنسبة لي ...

يبدو أن المشكلة لا تزال موجودة في إصدارات docker-ce الأخيرة. أبدأ حوالي 5 حاويات ، مع وجود حاوية بطيئة تحتوي على وحدة تخزين وحدة إرساء تشير إلى مشاركة NFS. لا توجد حاويات تكشف عن أي منفذ ، هل اكتشف أحد ما إذا كان هذا خطأ صالحًا (يبدو أن هذا الخطأ port=None مريب)؟

~~~
عميل:
الإصدار: 18.09.5.0
إصدار API: 1.39
إصدار Go: go1.10.8
الالتزام بوابة: e8ff056dbc
بني: الخميس 11 أبريل 04:44:28 2019
OS / Arch: لينكس / amd64
التجريبية: خطأ

الخادم: Docker Engine - Community
محرك:
الإصدار: 18.09.5.0
إصدار API: 1.39 (الحد الأدنى للإصدار 1.12)
إصدار Go: go1.10.8
Git الالتزام: e8ff056
تاريخ البناء: الخميس 11 إبريل 04:10:53 2019
OS / Arch: لينكس / amd64
التجريبية: خطأ
~~~

تمت إضافة المزيد من المخرجات من --verbose . لا أعتقد أن هناك أي شيء مفيد هنا ، فهو يقول فقط لفترة طويلة أن بعض عمليات إنشاء الحاويات تنتظر وقتًا طويلاً. يبدو أنه يستخدم الاستقصاء ، حيث تتم طباعة الرسالة التالية حوالي 1x / ثانية:

~compose.parallel.feed_queue: معلق: مجموعة ()~

the localhost / port = Node هو نوع من الرنجة الحمراء على ما أعتقد ، حيث يتم الاتصال باستخدام docker.sock ، لذلك ليس هناك خطأ خفي مخفي في مكان ما. أعتقد أن هذا سيحتاج إلى التعقب داخل عامل الإرساء ، وليس التعامل مع هذا الطلب هنا هو الأمثل.

يبدو أن Docker-compose يفتقد إلى نوع من معرف الطلب الذي يمكن تسجيله ، لذلك سنعرف الطلب الذي يتوقف. على سبيل المثال ، أعلم أن حاوية api لم يتم إنشاؤها خلال المهلة ، لكن سجل الطلب لا يساعد على الإطلاق. ربما يمكن لشخص آخر إضافة بعض المعلومات هنا:

~~~
urllib3.connectionpool._make_request: http: // localhost: بلا "POST /v1.25/containers/create؟name=api-memcache HTTP / 1.1" 201 90
urllib3.connectionpool._make_request: http: // localhost: لا شيء "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: docker create_container -> {'Id': '22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f'،
"تحذيرات": لا توجد}
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network -> لا شيء
compose.cli.verbose_proxy.proxy_callable: عامل ميناء inspect_container <- ('22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f')
compose.
urllib3.connectionpool._make_request: http: // localhost: None "GET /v1.25/containers/22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f/json HTTP / 1.1" 200 بلا
urllib3.connectionpool._make_request: http: // localhost: لا شيء "POST /v1.25/containers/create؟name=api HTTP / 1.1" 201 90
compose.cli.verbose_proxy.proxy_callable: عامل إرساء create_container -> {'Id': '1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec' ،
"تحذيرات": لا توجد}
compose.cli.verbose_proxy.proxy_callable: عامل ميناء inspect_container <- ('1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec')
compose.parallel.feed_queue: معلق: مجموعة ()
urllib3.connectionpool._make_request: http: // localhost: لا شيء "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
urllib3.connectionpool._make_request: http: // localhost: لا شيء "POST /v1.25/networks/proxy/connect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: عامل ميناء inspect_container -> JSON ...
urllib3.connectionpool._make_request: http: // localhost: None "GET /v1.25/containers/1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec/json HTTP / 1.1" 200 بلا
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network -> لا شيء
compose.cli.verbose_proxy.proxy_callable: عامل ميناء connect_container_to_network -> لا شيء
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network <- ('22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f'، 'proxy')
compose.
compose.cli.verbose_proxy.proxy_callable: عامل ميناء inspect_container -> JSON ...
urllib3.connectionpool._make_request: http: // localhost : بلا "POST /v1.25/containers/create؟name=api-comments-db HTTP / 1.1" 201 90
compose.cli.verbose_proxy.proxy_callable: بدء عامل الإرساء <- ('ba67095c5ea718af13a09798bc2f5ab24f5d0b54ce684b6f4cb248ab705df900')
compose.parallel.feed_queue: معلق: مجموعة ()
compose.parallel.feed_queue: معلق: مجموعة ()
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network <- ('1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec' ، "الوكيل")
compose.cli.verbose_proxy.proxy_callable: عامل ميناء create_container -> {'Id': 'ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af'،
"تحذيرات": لا توجد}
urllib3.connectionpool._make_request: http: // localhost : لا شيء "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
urllib3.connectionpool._make_request: http: // localhost : لا شيء "POST /v1.25/networks/proxy/connect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: عامل ميناء inspect_container <- ('ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af')
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network -> لا شيء
compose.parallel.feed_queue: معلق: مجموعة ()
compose.cli.verbose_proxy.proxy_callable: عامل ميناء connect_container_to_network -> لا شيء
compose.cli.verbose_proxy.proxy_callable: عامل ميناء connect_container_to_network <- ( '22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f'، 'الوكيل'، والأسماء المستعارة = [ 'memcache'، '22b774d0451c']، ipv4_address = بلا، ipv6_address = بلا، وصلات = []، link_local_ips = لا يوجد)
compose.parallel.feed_queue: معلق: مجموعة ()
urllib3.connectionpool._make_request: http: // localhost : None "GET /v1.25/containers/ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af/json HTTP / 1.1" 200 بلا
urllib3.connectionpool._make_request: http: // localhost : لا شيء "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: بدء عامل الإرساء <- ('7d81ef23610f1b8f7ac95837cbf6c9eef977b5b0846fea24be5c7054e471df39')
compose.parallel.feed_queue: معلق: مجموعة ()
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network -> لا شيء
compose.cli.verbose_proxy.proxy_callable: عامل ميناء inspect_container -> JSON ...
urllib3.connectionpool._make_request: http: // localhost : لا شيء "POST /v1.25/networks/proxy/connect HTTP / 1.1" 200 0
compose.
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network <- ('ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af'، "الوكيل")
compose.cli.verbose_proxy.proxy_callable: عامل ميناء connect_container_to_network -> لا شيء
compose.cli.verbose_proxy.proxy_callable: بدء عامل الإرساء <- ('22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f')
compose.parallel.feed_queue: معلق: مجموعة ()
urllib3.connectionpool._make_request: http: // localhost: لا شيء "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
urllib3.connectionpool._make_request: http: // localhost: لا شيء "POST /v1.25/networks/proxy/connect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network -> لا شيء
compose.cli.verbose_proxy.proxy_callable: عامل ميناء connect_container_to_network -> لا شيء
compose. لا شيء)
compose.cli.verbose_proxy.proxy_callable: بدء عامل الإرساء <- ('1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec')
urllib3.connectionpool._make_request: http: // localhost: لا شيء "POST /v1.25/networks/proxy/connect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: عامل ميناء connect_container_to_network -> لا شيء
compose.cli.verbose_proxy.proxy_callable: بدء عامل الإرساء <- ('ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af')
compose.parallel.feed_queue: معلق: مجموعة ()
compose.parallel.feed_queue: معلق: مجموعة ()
compose.parallel.feed_queue: معلق: مجموعة ()
compose.parallel.feed_queue: معلق: مجموعة ()
...
- تم حذف 30 سطرًا تقريبًا
...
إنشاء تعليقات API ... تم
compose.cli.verbose_proxy.proxy_callable: بدء عامل الإرساء -> لا شيء
compose.parallel.parallel_execute_iter: انتهاء المعالجة: اسم الخدمة (المشروع = 'api' ، الخدمة = 'التعليقات' ، الرقم = 1)
compose.parallel.feed_queue: معلق: مجموعة ()
compose.parallel.parallel_execute_iter: انتهاء المعالجة:
compose.parallel.feed_queue: معلق: مجموعة ()
إنشاء api-memcache ... انتهى
urllib3.connectionpool._make_request: http: // localhost: None "POST /v1.25/containers/22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f/start HTTP / 1.1" 204 0
compose.cli.verbose_proxy.proxy_callable: بدء عامل الإرساء -> لا شيء
compose.parallel.parallel_execute_iter: انتهاء المعالجة: اسم الخدمة (المشروع = 'api' ، الخدمة = 'memcache' ، الرقم = 1)
compose.parallel.feed_queue: معلق: مجموعة ()
compose.parallel.parallel_execute_iter: انتهاء المعالجة:
compose.parallel.feed_queue: معلق: مجموعة ()
compose.parallel.feed_queue: معلق: مجموعة ()
compose.parallel.feed_queue: معلق: مجموعة ()
compose.parallel.feed_queue: معلق: مجموعة ()
urllib3.connectionpool._make_request: http: // localhost: None "POST /v1.25/containers/ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af/start HTTP / 1.1" 204 0
compose.cli.verbose_proxy.proxy_callable: بدء عامل الإرساء -> لا شيء
إنشاء api-comments-db ... تم
compose.parallel.feed_queue: معلق: مجموعة ()
compose.parallel.parallel_execute_iter: انتهاء المعالجة:
compose.parallel.feed_queue: معلق: مجموعة ()
compose.parallel.feed_queue: معلق: مجموعة ()
compose.parallel.feed_queue: معلق: مجموعة ()
compose.parallel.feed_queue: معلق: مجموعة ()
compose.parallel.feed_queue: معلق: مجموعة ()
- تم حذف 15 سطرًا تقريبًا
إنشاء api-redis ... انتهى
compose.parallel.feed_queue: معلق: مجموعة ()
urllib3.connectionpool._make_request: http: // localhost: None "POST /v1.25/containers/ba67095c5ea718af13a09798bc2f5ab24f5d0b54ce684b6f4cb248ab705df900/start HTTP / 1.1" 204 0
compose.cli.verbose_proxy.proxy_callable: بدء عامل الإرساء -> لا شيء
compose.parallel.parallel_execute_iter: انتهاء المعالجة: اسم الخدمة (المشروع = 'api' ، الخدمة = 'redis' ، الرقم = 1)
compose.parallel.feed_queue: معلق: مجموعة ()
compose.parallel.parallel_execute_iter: انتهاء المعالجة:

compose.parallel.feed_queue: معلق: مجموعة ()

- تم حذف أكثر من 100 سطر
compose.parallel.parallel_execute_iter: فشل: اسم الخدمة (المشروع = 'api' ، الخدمة = 'api' ، الرقم = 1)
compose.parallel.feed_queue: معلق: مجموعة ()

خطأ: لـ api UnixHTTPConnectionPool (host = 'localhost' ، port = None): انتهت مهلة القراءة. (مهلة القراءة = 60)
compose.parallel.parallel_execute_iter: فشل:
compose.parallel.feed_queue: معلق: مجموعة ()

خطأ: لـ api UnixHTTPConnectionPool (host = 'localhost' ، port = None): انتهت مهلة القراءة. (مهلة القراءة = 60)
compose.cli.errors.log_timeout_error: استغرق طلب HTTP وقتًا طويلاً حتى يكتمل. أعد المحاولة باستخدام --verbose للحصول على معلومات التصحيح.
إذا واجهت هذه المشكلة بانتظام بسبب ظروف الشبكة البطيئة ، ففكر في تعيين COMPOSE_HTTP_TIMEOUT على قيمة أعلى (القيمة الحالية: 60).
~~~

titpetric يمكن أن يؤكد أنني أواجه هذه المشكلة أيضًا.

IMHO هذه المشكلة في جانب عامل الإرساء ، وليس جانب عامل الإرساء. يجب على شخص ما تشغيل تسجيل تصحيح الأخطاء على docker deamon وتحديد التأخيرات هناك ، وتقديم مشكلة في المنبع. لست متأكدًا من إمكانية إعادة إنتاج هذا بسهولة بدون ذلك.

إذا كان شخص ما على استعداد لاستغلال الوقت ، أقترح تكرار ذلك عن طريق إنشاء مجلد محمّل بالكامل لتركيب وحدة تخزين (شيء يحتوي على أكثر من 100000 ملف / مجلد يجب القيام به) ، لمعرفة ما إذا كان إعادة إنتاج موثوق للمشكلة يمكن تحقيقه. من المحتمل أن برنامج Docker daemon أو kernel bind mount نفسه يخزن بعض بيانات inode مسبقًا. وهو ... أمر مؤسف.

قد يؤكد tcpdump هذا أيضًا في حالة وجود نظام ملفات على الشبكة (samba ، nfs).

نفس الخطأ هنا بالضبط

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

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

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

إعادة تشغيل Docker تم إصلاحه أيضًا بالنسبة لي.

إعادة التشغيل ليس إصلاحا يا شباب .....
كيف تتجنب هذا للأبد؟

تواجه نفس المشكلة. الحصول على الخطأ أدناه لجميع حاويات Docker لأقران المنظمة:

خطأ: لـ DNS UnixHTTPConnectionPool (المضيف = 'localhost' ، المنفذ = بلا): انتهت مهلة القراءة. (مهلة القراءة = 60)

هل هو بسبب عدم تطابق بعض المنافذ أو التخصيص في ملف الإنشاء؟

نعم ، واجهت هذه المشكلة باستمرار بنفسي. أوافق على أن إعادة التشغيل ليست حلاً ، ولكن يبدو أن لا شيء آخر يفعل الحيلة: /

مجرد لمعلوماتك ، مع حالتي فقط إعادة المحاولة باستخدام عامل إنشاء يميل إلى الحل
عليه. لا أعتقد أنني قمت بإعادة تشغيل dockerd على الإطلاق ، فهذه المشكلة لا تزال قائمة
أنا.

في يوم الجمعة ، 2 أغسطس ، 2019 الساعة 1:39 مساءً ، كتب Alex [email protected] :

نعم ، واجهت هذه المشكلة باستمرار بنفسي. أوافق على إعادة التشغيل ليست كذلك
حلاً ، ولكن يبدو أن لا شيء آخر يفعل الحيلة: /

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/docker/compose/issues/3927؟email_source=notifications&email_token=AABY7EH4MVKGI56ZLEIUV5TQCQMHBA5CNFSM4CPDX2D2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW66
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AABY7EA3NTUP5SNZRTFWFEDQCQMHBANCNFSM4CPDX2DQ
.

أنا أيضًا أواجه هذه المشكلة :(
UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)

نفس المشكلة هنا ، إعادة تشغيل Docker معلقة بالفعل. الطريقة الوحيدة هي قتل Docker / أو إعادة التشغيل ولكن لا يمكن أن يكون هذا هو الحل.

bitbrain ، نعم ، لقد كان هذا يحدث لي أيضًا منذ بعض الوقت.

لقد وجدت حلاً أنيقًا لهذا (على نظام MacOS)

السبب في استمرار حدوث ذلك لي هو أن Docker كان لديه القليل من الذاكرة المتاحة.

أدت زيادة الذاكرة من 2 جيجابايت إلى 8 جيجابايت إلى حل المشكلة بالنسبة لي.

تلقيت هذا الخطأ بعد تشغيل docker-compose up ثم تشغيل docker-compose down مرتين. حاولت كل شيء في هذا الموضوع. ازدحام الموارد ، وإعادة تشغيل جهاز Mac الخاص بي وإعادة تثبيت Docker الأحدث. يمكنني تشغيل docker-compose up مرة أخرى بعد إعادة تشغيل الصندوق الخاص بي ، ولكن بعد إعادة تدوير هذه الأوامر عدة مرات ، ستعود إلى هذا الخطأ ولا يمكنني الحصول على docker-compose up للتشغيل.

يبدو أن مشكلتي كانت تتعارض مع خدمة أخرى ( pow ) كانت ملزمة للمنفذ 80 عندما كانت إحدى حاوياتي مرتبطة أيضًا بالمنفذ 80. لقد قمت بإلغاء تثبيت pow ولم أواجه مشكلة لمدة ثلاثة أيام الآن.

3 سنوات فتح هذه التذكرة وما زالت دون حل. لا تزال المشكلة تحدث حتى إذا قمنا بزيادة اتصال العميل إلى 120 ثانية.

فقط حدث لخادمنا ، العدد المفتوح منذ 2016 ، wtf

إعادة تشغيل Docker يعمل بالنسبة لي.

@ إعادة تشغيل rodrigo-brito ليس حلاً ...

رجلي.

أيضا تواجه هذا الآن. بري.

لديك نفس المشكلة عند محاولة تكوين عامل الإرساء أو تكوين عامل الإرساء. لقد قمت بحلها بإيقاف خدمة mysqld وبمجرد تشغيل الحاوية ، أبدأ mysql. ذاكرة الوصول العشوائي عند استخدام 20٪.

تشغيل مجتمع Docker Desktop Community لنظام التشغيل Mac v2.1.0.5

واجهت هذه المشكلة وتم حلها عن طريق زيادة حجم الذاكرة المخصصة لـ Docker (وتقليل كمية وحدات المعالجة المركزية).
يمكنك القيام بذلك في Docker -> Preferences -> Advanced.
انتقلت من 8 وحدات معالجة مركزية و 2 غيغابايت من ذاكرة الوصول العشوائي إلى 4 وحدات معالجة مركزية و 16 غيغابايت من ذاكرة الوصول العشوائي لإعداداتي الخاصة.

ركض في هذه المشكلة على Ubuntu Server 18.04 LTS. لا تؤدي إعادة تشغيل عامل الإرساء إلى حل المشكلة ، وكذلك تعيين متغيرات البيئة. أيه أفكار؟

bpogodzinski هل حاولت زيادة إعدادات الذاكرة في Docker؟ لقد زدتها من 2 غيغابايت إلى 8 غيغابايت وهذا أصلح المشكلة بالنسبة لي.

بشكل عام ، يبدو أن هذه المشكلة تحدث عندما تتطلب الحاويات ذاكرة أكثر من الذاكرة المتوفرة التي تم تكوينها في Docker ثم تتوقف الأشياء.

كانت لدينا هذه المشكلة ويبدو (بالنسبة لنا) أنها مرتبطة بمجلد مسمى به الكثير من الملفات. لا أفهم ذلك ، ولكن هذا هو الحال بالنسبة لنا أن عامل ميناء يؤلف (محرر للإيجاز) لديه خدمة:

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

   volumes:
       - serviceA_volume:

داخل Dockerfile for serviceA هو الأمر الذي يبدو غير ضار وغير فعال:

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

لاحظ أن هذا يغير المالك بشكل متكرر في / srvA / المجلد الذي يوجد في المجلد المسمى نظام ملفات كبير به 100 كيلوبايت من الملفات. ومع ذلك ، يحدث هذا عندما يتم إنشاء الصورة ويكون هذا المجلد فارغًا. يظهر باستخدام وحدة التخزين المسماة ترث أذونات ملف الصورة المحلي ثم تتابع تغيير أذونات وحدات التخزين المسماة.

هذه ميزة جميلة وربما لا تكون نفس المشكلة التي يواجهها أي شخص آخر ولكنها كانت مشكلتنا (تبديل الخط يؤدي إلى تبديل الخطأ). والنتيجة هي أن مهلة http هذه ربما تكون ناتجة عن أسباب متعددة.

لم تحل إعادة تشغيل عامل الإرساء المشكلة في حالتي ، مما أدى بالتأكيد إلى زيادة الموارد.

من واقع خبرتي ، تنشأ هذه المشكلة غالبًا في الحالات السحابية الصغيرة حيث يكون حجم ذاكرة الوصول العشوائي (RAM) جيدًا تمامًا أثناء الأداء العادي ولكنه يثبت أنه غير كافٍ أثناء عمليات إنشاء عامل الإرساء أو عامل الإرساء. يمكنك بسهولة زيادة ذاكرة الوصول العشوائي ، ولكن من المحتمل أن يؤدي ذلك إلى زيادة تكلفة جهاز افتراضي صغير بشكل كبير.

في كل حالة ، أدى إضافة قسم المبادلة أو حتى ملف المبادلة إلى حل هذه المشكلة بالنسبة لي!

فقط حدث لي على التوت باي. لا يوجد حجم به كمية هائلة من الملفات أو أي شيء.
في الواقع ، لقد كنت أقوم بوضع هذه الحاويات على هذا التوت لفترة من الوقت الآن (سنة أو سنتين لول).
لست متأكدا ما الذي تغير.
يبدو قليلا "من فراغ".

لا تزال المشكلة تظهر على docker desktop 2.2.0.3 على MacOs 🙁

لقد قمت بحل مشكلتي بالأوامر التالية:
docker volume prune
docker system prune
(قد يكون واحدًا فقط من هذه الأوامر كافياً ، لكن لا يمكن إعادة إنتاجه في الوقت الحالي ...)

لقد قمت بحل مشكلتي بالأوامر التالية:
docker volume prune
docker system prune
(قد يكون واحدًا فقط من هذه الأوامر كافياً ، لكن لا يمكن إعادة إنتاجه في الوقت الحالي ...)

ساعد حل amaumont ، على الرغم من أنني أعتقد أن هذا سيستمر في العودة مع
كما قال أي شخص آخر ، فإن إعادة تشغيل عامل الإرساء ليس حلاً مناسبًا ، إنه عصابة.

نواجه مشكلات متعددة في إنشاء عامل الإرساء أيضًا.

بعد تعيين MaxSessions 500 في sshd_config (انظر # 6463) ، نحصل الآن أيضًا على مهلات القراءة.
أدى تعيين المهلة على 120 ثانية إلى حل المشكلة للتشغيل التالي DOCKER_HOST=xxx<strong i="8">@yyy</strong> docker-compose up -d .

أثناء التشغيل الثاني ، ارتفع حمل الماكينة إلى 30 (كذا!) قبل فشل أمر Docker-compose بسبب انتهاء المهلة. لم تؤد إعادة تشغيل عامل الإرساء إلى حل هذه المشكلة ، ولا حتى مؤقتًا.
الخادم هو مثيل AWS EC2 به وحدة المعالجة المركزية / القرص / NetIO وما إلى ذلك ، ويشتمل ملف الإنشاء على ترافيك واحد و 3 خدمات مع البريد ، لذلك لا يوجد شيء مميز هنا. تشغيل docker-compose up -d بنفس ملف docker-compose.yml مباشرة على الخادم يعمل بشكل موثوق وكما هو متوقع.
يعرض التشغيل باستخدام --verbose أكثر من ألف سطر متتالي يحتوي على compose.parallel.feed_queue: Pending: set() .

سأحاول rsync ملف docker-compose إلى الخادم البعيد وتشغيل docker-compose مباشرة على هذا الجهاز كحل بديل.

بالنسبة لي ، لقد ساعدت فقط في إعادة تشغيل عامل الإرساء.

يحدث ذلك كثيرًا بالنسبة لي عند محاولة الدفع إلى السجل الخاص بي من خطوط أنابيب bitbucket. يعمل بشكل جيد عند الدفع من جهاز كمبيوتر محلي.
يمكن أن تساعد إعادة تشغيل عامل الإرساء لفترة ، ولكن هذا "while" يستمر لمدة 10 دقائق كحد أقصى: c

تحديث. يبدو أن تعيين DOCKER_CLIENT_TIMEOUT و COMPOSE_HTTP_TIMEOUT يساعد ، لكنني لا أعرف إلى متى

لقد بدأت في الحصول عليها منذ التبديل إلى Docker Edge مع تشغيل التخزين المؤقت

لقد كان هذا يحدث باستمرار بالنسبة لي منذ أن بدأت في استخدام Docker منذ 2-3 سنوات. بعد تشغيل الحاوية لفترة من الوقت ، تصبح زومبي ويجب إعادة تشغيل محرك Docker بأكمله حتى تستجيب الأشياء مرة أخرى. يبدو هذا وكأنه تسرب للموارد من نوع ما ، حيث يبدو أن وقت الخمول مناسب جدًا للسلوك المتمرس.

إذا لم تكن هناك حاويات قيد التشغيل ، أو كانت تعمل لفترة قصيرة من الوقت ، فيبدو أن كل شيء يعمل بشكل جيد لأيام أو أسابيع. ولكن بمجرد أن أترك حاوية تعمل لبضع ساعات ، فإنها تصبح غير مستجيبة ، ولا بد لي من إيقافها بالقوة في سطر الأوامر وأي محاولة للتواصل مع docker أو docker-compose تفشل للتو مع مهلة. إعادة التشغيل هي الحل العملي الوحيد.

ناتج docker-compose version

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

ناتج docker version

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

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

ناتج docker-compose config

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

macOS Mojave 10.14.6.

لقد واجهت نفس المشكلة ، حتى أنني قمت بزيادة الموارد من 4 جيجابايت من ذاكرة الوصول العشوائي ، ومبادلة 1 جيجابايت إلى 6 جيجابايت من ذاكرة الوصول العشوائي ، ومبادلة 2 جيجابايت.

انا ايضا اواجه نفس المشكلة

لديها نفس المشكلة

لقد كنت أواجه نفس المشكلة على Ubuntu 18.04 LTS (8 جيجابايت من ذاكرة الوصول العشوائي) باستخدام HTTPS.

أنا قادر على إنتاج حاويات بـ docker-compose up ، ولكن بمجرد النشر لا يمكنني إيقاف الحاويات بـ docker-compose down . ثبت أن إعادة تشغيل برنامج Docker daemon أو إعادة تشغيل VM غير فعال. إضافة متغيرات بيئة المهلة ( DOCKER_CLIENT_TIMEOUT ، COMPOSE_HTTP_TIMEOUT ) لم تفعل أي شيء أيضًا.

أنا قادر على التفاعل مع الحاويات وإيقافها بشكل فردي ، ويمكنني فحص الحاويات وإرفاقها وأي شيء آخر ، لكن لا يمكنني إيقافها أو قتلها باستخدام الأمر docker-compose .

رسالة الخطأ هي نفسها دائمًا:

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

كنت أواجه نفس المشكلة عندما كان لدي ما يلي في docker-compose.yml:

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

ذهب الخطأ عندما أضفت علامات الاقتباس حول "10". يذكر هذا في المستندات أن قيم max-file و max-size يجب أن تكون سلسلة ، لكن لا تزال. رسالة الخطأ مضللة تمامًا.

كنت أواجه نفس المشكلة عندما كان لدي ما يلي في docker-compose.yml:

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

ذهب الخطأ عندما أضفت علامات الاقتباس حول "10". يذكر هذا في المستندات أن قيم max-file و max-size يجب أن تكون سلسلة ، لكن لا تزال. رسالة الخطأ مضللة تمامًا.

أنت تحفظ يومي. شكرا جزيلا لك!

كنت أواجه نفس المشكلة عندما كان لدي ما يلي في docker-compose.yml:

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

ذهب الخطأ عندما أضفت علامات الاقتباس حول "10". يذكر هذا في المستندات أن قيم max-file و max-size يجب أن تكون سلسلة ، لكن لا تزال. رسالة الخطأ مضللة تمامًا.

أنا أقوم بتكوين برنامج تشغيل التسجيل على مستوى Docker daemon. أنا أستخدم fluentd كمشغل تسجيل الدخول الخاص بي ، لذلك للأسف لن يعمل هذا الإصلاح بالنسبة لي. = /

حاولت هذا

export DOCKER_CLIENT_TIMEOUT=120
export COMPOSE_HTTP_TIMEOUT=120

ويبدو أنه يعمل على حل المشكلة في الوقت الحالي

حلول أخرى ذكرها الأشخاص في هذا الموضوع:

• أعد تشغيل Docker
• زيادة Docker CPU والذاكرة

حسنًا ، لا شيء يعمل معي ، باستثناء خيار المهلة ، مجد لك.

أحصل على هذا منذ أن بدأت في استخدام دليل NFS المركب داخل إحدى حاوياتي. يوجد دليل NFS المُحمّل على ارتباط بطيء (في موقع بعيد يحتوي على اتصال نطاق ترددي منخفض). هل يمكن أن تكون هذه هي المشكلة؟

أواجه هذا كثيرًا على Mac ، Docker 2.4.0.0 ، في مشروعين مختلفين بتكوينات docker-compose.yml مختلفة. لا أتذكر أنه حدث من قبل قبل أسبوع واحد تقريبًا وهو عندما قمت بالترقية إلى 2.4.0.0. هل هناك انحدار؟

لقد حاولت زيادة المهلة إلى 600 ، وزيادة ذاكرة الوصول العشوائي إلى 16 غيغابايت والتبديل إلى 4 غيغابايت ، وإعادة تشغيل Docker ، وإعادة تشغيل جهاز Macbook بالكامل ، لا شيء يبدو أنه يعمل ، باستثناء المحاولة بشكل عشوائي مرارًا وتكرارًا ، ثم سيعمل أحيانًا. ولكن في المرة التالية التي أحتاج فيها إلى إعادة تشغيل حاوية أو إعادة بنائها ، نفس المشكلة :(

بدأت في رؤية هذا بـ 2.4.0.0 على Mac أيضًا. الحل البديل بالنسبة لي هو إعادة تشغيل عامل الإرساء ولكن سيتم تشغيله مرة أخرى لاحقًا.

كذلك هنا! مع التحديث إلى 2.4.0 ، لا تبدأ إعداداتنا في بعض الأحيان على الإطلاق بالأخطاء المذكورة Read timed out. ، وأحيانًا تبدأ بعض الحاويات فقط ، والبعض الآخر يظهر هذا الخطأ. أنا أفكر بالفعل في خفض المستوى!

فقط لذكر: تؤثر هذه المشكلة على كل من عمليات الإعداد التي تستخدم مشاركات NFS وكذلك المشاريع التي تستخدم وحدات التخزين المركبة "العادية"

نفس المشكلة هنا ، أيضًا على نظام التشغيل Mac وبعد التحديث 2.4.0. أحاول حاليًا إذا كان الرجوع إلى إصدار سابق يساعد.

تحديث: الرجوع إلى الإصدار السابق ، وحذف ذاكرة التخزين المؤقت وإعادة البناء يعمل على إصلاح المشكلة.

لقد بدأت مؤخرًا في رؤية هذه المشكلة (Mac ، 2.4.0.0) ، عندما لم أرها من قبل. أدى تشغيل docker image prune إلى اختفاء المشكلة لبضعة أيام ، لكنها عادت الآن مرة أخرى.

بدأ أيضًا في تكرار خطأ المهلة هذا منذ التحديث 2.4.0 (على Mac OS Mojave 10.14.5)

مشاهدة هذا أيضًا بتكرار متزايد منذ التحديث إلى Docker Desktop 2.4.0.0 (48506) على MacOS Catalina.

أحصل على نفس مشكلات المهلة منذ 2.4.0.0 على نظام التشغيل Mac OS. لم أواجه هذه المشكلة من قبل.
لقد جربت إصدار الحافة 2.4.1.0 (48583) ولكن لا يزال لدي نفس المشكلة.

حصلت على نفس المشكلة وأعدت عملية إعادة التشغيل Docker لنظام التشغيل MacOs Catalina (10.15.5) وإصدار docker 2.4.0.0

بالمثل هنا ، لم أواجه مشكلة قبل التحديث إلى Docker desktop 2.4.0.0.
تعمل إعادة تشغيل سطح مكتب Docker ، لكنها مجرد حل بديل.

نفس الشيء هنا ، يبدأ أيضًا بـ v2.4.0

تحديث: الرجوع إلى الإصدار السابق ، وحذف ذاكرة التخزين المؤقت وإعادة البناء يعمل على إصلاح المشكلة.

سأحاول ذلك. لست متأكدا كيف يتم ذلك. أفترض أنه من خلال إلغاء تثبيت وتنزيل إصدار سابق؟

نعم ، قمت بإلغاء تثبيت 2.4 وقمت بتنزيل / إعادة تثبيت الإصدار 2.3. الآن يعمل ، يمكنني بدء تشغيل حاوياتي كالمعتاد.
حصلت على 2.3 من هناك: https://docs.docker.com/docker-for-mac/release-notes/#docker -desktop-community-2302

نعم ، يمكنني التأكيد على أنها أحدثت الفارق بالنسبة لي أيضًا. بالتأكيد v2.4 هو المسؤول هنا بطريقة ما.

إذا واجهت هذه المشكلة بانتظام بسبب ظروف الشبكة البطيئة ، ففكر في تعيين COMPOSE_HTTP_TIMEOUT على قيمة أعلى (القيمة الحالية: 60).

كيف 1Gbps شبكة بطيئة ، بالضبط؟

عملت التخفيض بالنسبة لي كذلك. لأولئك الذين يديرون Docker عبر Homebrew

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

إذا واجهت هذه المشكلة بانتظام بسبب ظروف الشبكة البطيئة ، ففكر في تعيين COMPOSE_HTTP_TIMEOUT على قيمة أعلى (القيمة الحالية: 60).

كيف 1Gbps شبكة بطيئة ، بالضبط؟

في حالتي ، حدث هذا بسبب محرك أقراص شبكة مثبت على NFS.
كان السبب الجذري لسرعة الشبكة "البطيئة" هو استخدام NFS وليس سرعة الارتباط الفعلية.
لكنه يظهر بالتأكيد أن هناك مشكلة في التنفيذ وسأفاجأ إذا كان تغيير HTTP_TIMEOUT سيحل المشكلة.

كذلك هنا. تباطؤ كبير في إنشاء الحاوية ، مما أدى إلى خطأ مهلة HTTP المذكور أعلاه على Docker لنظام التشغيل Mac v2.4. إعداد COMPOSE_HTTP_TIMEOUT = نجح 120 ، لكن بطء إنشاء الحاوية لا يزال يمثل مشكلة جديدة. يؤدي الرجوع إلى الإصدار 2.3 إلى إصلاح هذا أيضًا.

يمكنني تأكيد نفس المشكلة منذ أن قمت بتثبيت Docker for Mac v2.4.
يمكنني أيضًا تأكيد زيادة كبيرة في استهلاك ذاكرة الوصول العشوائي ووحدة المعالجة المركزية حتى في لحظات الخمول ، فقط مع تشغيل Docker daemon. لكن أعتقد أنه لا علاقة له بتكوين الحزمة نفسها.

كان لدي نفس المشكلة. تم إلغاء تثبيت 2.40 وتثبيته 2.3 من الرابط المذكور بواسطة ddesrousseaux ولم يعد لدي بطء أو مهلات فائقة مع حاويات البدء.

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

لا تزال هذه المشكلة موجودة في Docker v. 2.4.3.0 .

لقد خفضت أيضًا إلى 2.3 من 2.4 إلى حل بديل لمشكلات البطء الهائلة في الإصدار 2.4. يسعدنا تقديم أي سجلات قد تكون مفيدة لتصحيح ما يحدث هنا.

بترديدًا لما سبق ، بدأ هذا يحدث في 2.4.2.x بالنسبة لي. شيء ما تغير في الترقية من 2.3.

لقد أجريت بعض الاختبارات في بيئة Linux ، وواجهت مشكلة مماثلة. لقد قمت بتثبيت أحدث نسخة ثنائية من عامل الإرساء (v1.27.4) وواجهت نفس مشكلة المهلة التي تبلغ عنها يا رفاق.

بعد الرجوع إلى الإصدار 1.27.2 ، وهو نفس الشيء المتاح في Docker لنظام التشغيل Mac 2.3 ، اختفت المشكلة.

نفس المشكلة مع الإصدار الحالي على Ubuntu 20.04.

كانت مشكلتي أنني قمت بتثبيت عامل الإرساء والتركيب مع snap and apt. لقد قمت بإلغاء تثبيتها وإعادة تشغيلها ثم اتبعت تعليمات التثبيت الرسمية على https://docs.docker.com/engine/install/ubuntu/ و https://docs.docker.com/compose/install/

ما زلت أواجه أخطاء انتهاء المهلة بشكل متكرر منذ التحديث 2.4.0 الذي لا يزال غير ثابت في 2.5.0

نعم ، نفس الشيء هنا. كانت تعمل بشكل جيد بالنسبة لي خلال العامين الماضيين. ولكن منذ شهرين ، فجأة عندما كنت أريد مثيلًا واحدًا وأبدأ مشروع عامل إرساء آخر ، فإنه يرمي:
من أجل apache UnixHTTPConnectionPool (host = 'localhost'، port = None): انتهت مهلة القراءة.

تؤدي إعادة تشغيل Docker إلى إصلاح المشكلة. ولكنه ألم حقيقي عندما يتعين علي التبديل بين المشاريع عدة مرات في يوم واحد

عند حدوث نفس المشكلة منذ 2.4 ، وحدة المعالجة المركزية 300٪ في جميع الأوقات ، 2.5 لم يساعد ، تم تخفيضه إلى 2.3 والأشياء على ما يرام. هذا على أحدث macbook w / i7 cpu و 32 g ram

لقد قمت للتو بالترقية إلى آخر إصدار من Docker لنظام التشغيل Mac (v2.5.0.1) ويبدو أن المشكلة قد تم حلها.
لا مزيد من الخطأ UnixHTTPConnection ، ولا مزيد من استخدام وحدة المعالجة المركزية بنسبة 100٪.

لست متأكدًا مما إذا كان أي شخص آخر يمكنه تأكيد ذلك.

كيف حصلت على هذا؟ لا يزال فتح Docker على Mac وإجراء "التحقق من وجود تحديثات" يشير إلى أن لدي الأحدث ، 2.4.2.0.

لقد قمت للتو بالترقية إلى آخر إصدار من Docker لنظام التشغيل Mac (v2.5.0.1) ويبدو أن المشكلة قد تم حلها.
لا مزيد من الخطأ UnixHTTPConnection ، ولا مزيد من استخدام وحدة المعالجة المركزية بنسبة 100٪.

لست متأكدًا مما إذا كان أي شخص آخر يمكنه تأكيد ذلك.

لقد واجهت المشكلة للتو في v2.5.0.1. يبدو أن إعادة تشغيل عامل الإرساء (على الأقل مؤقتًا) يحل المشكلة.

كيف حصلت على هذا؟ لا يزال فتح Docker على Mac وإجراء "التحقق من وجود تحديثات" يشير إلى أن لدي الأحدث ، 2.4.2.0.

لا يمكنني عرض أي لقطة شاشة لك منذ أن قمت بالترقية بالفعل ، ولكن أعتقد أنك قد تواجه بعض المشاكل في الحصول على التحديثات من جهاز الكمبيوتر الخاص بك ، حيث كان هناك إصدار سابق v2.5.0 متاح لأكثر من أسبوع.

يمكنك التحقق من ذلك في ملاحظات إصدار Docker for Mac (والحصول على أي مثبت جديد من هناك).

أنا أركض الحافة. ربما يفسر ذلك.

يمكن أن تؤكد أن الإصدار 2.5.0.1 أفضل بشكل هامشي على الأقل. لم تعد تحصل على مهلات في كل صندوق بعد الآن ، ولم تصادفه بعد منذ التحديث هذا الصباح. ومع ذلك ، لا يزال وقت تمهيد الحاوية يبدو أبطأ بكثير من 2.3.

تحرير: واجهت أخطاء المهلة مرة أخرى ، بعد حوالي 4 أو 5 عمليات إعادة تشغيل لمشروع إنشاء عامل الإرساء. حدث أيضًا خطأ جديد في 2.5.0.1: Cannot start service <container name>: error while creating mount source path <local mount path>: mkdir <local mount path>: file exists

يمكن أن تؤكد أن الإصدار 2.5.0.1 أفضل بشكل هامشي على الأقل. لم تعد تحصل على مهلات في كل صندوق بعد الآن ، ولم تصادفه بعد منذ التحديث هذا الصباح. ومع ذلك ، لا يزال وقت تمهيد الحاوية يبدو أبطأ بكثير من 2.3.

تحرير: واجهت أخطاء المهلة مرة أخرى ، بعد حوالي 4 أو 5 عمليات إعادة تشغيل لمشروع إنشاء عامل الإرساء. حدث أيضًا خطأ جديد في 2.5.0.1: Cannot start service <container name>: error while creating mount source path <local mount path>: mkdir <local mount path>: file exists

حسنًا ، ما زلت أواجه بعض المشكلات في إصدار 2.5.0.1. لا يزال استخدام وحدة المعالجة المركزية مرتفعًا جدًا مقارنةً بـ v2.3.x ، كما أن السرعة بطيئة جدًا.

هل يستطيع أي شخص من فريق Docker الاعتراف بهذا الأمر والتأثير فيه؟

يا الله ، مرت 4 سنوات ، لم تحل هذه القضية ، وهي تحدث لي طوال الوقت