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を実行した場合も同じエラー

これは、画像に1つの非常に大きなレイヤーがあることに関連している可能性がありますか？ （Dockerがイメージをビルドするときにレイヤーにフラット化されるのに約1分かかる非常に長いnpm install操作）

また、WindowsとMacの両方で6つのコンテナー[docker-composeバージョン1.8.1、ビルド878cff1]を含むdocker作成ファイル[バージョン1.12.2-rc1-beta27（ビルド：12496）]を使用してこの問題が発生しています。
179c18cae7]

dockerで使用できるリソースを増やすと、発生する可能性が低くなるようです（タイムアウト変数を拡張する場合と同様）が、排除されることはありません。

また、いくつかの大きなレイヤー（240MBが最大で、メインのパッケージインストールコマンド）があり、いくつかのコンテナーにまたがる120MBのファイルを含むホストディレクトリにバインドしています。

これを回避するためのさまざまな試みから、可能な修正に光を当てる可能性のあるものを見つけました。

最初、私のシナリオは次のようになりました。

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

これにより、すべての大きな静的ファイルをマウントするランタイムが省略され、サービスの開始がはるかに速くなりました。

これから私が理解しているのは、マウントするファイルが多いほど、特にファイルが大きいほど（B / KBのソースファイルではなくMBの画像）、読み込み時間が大幅に長くなるということです。

お役に立てれば

+1
このタイムアウトの問題は毎週、通常はアイドル状態の週末の後に、コンテナに接続しようとしたときにタイムアウトになりました...
回避するには、実行中のdockerprocを終了して再起動する必要があります。

+1
コンテナが1日経っても応答しなくなったため、コンテナを再起動しようとするたびに発生します。 コンテナを止めようとしているので、私のケースがマウントに関係しているかどうかはわかりません。

nginx conatiner、 Up 47 hoursハッピングします。
Docker for 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に感謝します。大きなファイルのマウントが私のLinuxサーバーでのこの問題の原因であると思います。 コンテナに大きなファイルが必要ない場合は、スニペットが回避策になる可能性があります。

しかし、Dockerでのマウントが遅いのはなぜですか？ 多分それはディスクコピーをトリガーしますか？ しかし、なぜ？

@cherrotこのテーマに非常に精通しているとは言えませんが、これはDockerで使用されるストレージドライバーと、レイヤーを整理するために内部でどのように機能するかに関係していると思います。 docker infoを使用して、デーモンが使用しているストレージドライバー（おそらく最も遅いaufs ）を確認し、ホストOSによっては、別のように変更する場合があります（ overlayサポートされている場合は、 LCFSのようなより高速な代替手段がありますが、Dockerによって商業的にサポートされていないため、自分でそこにいることになります。

このタイムアウトも発生しています。 また、使用しているボリュームが原因のようです。

一部のSMBネットワーク共有にアクセスするには、いくつかのコンテナーが必要です。 そこで、これらの共有をホストシステムにマウントし、コンテナー内にバインドマウントしました。 ただし、Windows ServerとLinuxホスト間の通信が停止することがあり（https://access.redhat.com/solutions/1360683を参照）、これによりコンテナーの開始または停止がブロックされ、しばらくするとタイムアウトになります。

まだ修正はありません。 SMBをサポートする、またはSMBでのストール通信の問題を解消するボリュームプラグインを探しています。 しかし、実際の解決策はまだありません。

FWIW：検索エンジンを介してここに到着した人々が解決策を見つけた場合、_これをオフにしてからもう一度オンにしてみましたか？_メソッドでこれを修正することができました。 Docker MacOSクライアントを再起動しました。

+1、4つのコンテナーを実行するインスタンスでストレステストを実行していて、 docker ps -aでもDockerがハングするため、コンテナーを再起動しようとしていますが、
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を再起動すると、解決しました。 しかし、毎日再起動する必要があります

Dockerを再起動するとうまくいきます。

+1の再起動ドッカーも私のために働いた。

かなり大きなDockerイメージを構築し、それをリモートレジストリにプッシュしようとしたときに、この問題が発生しました。 Dockerの再起動は適切な解決策ではありませんでしたが、 https ：

@ rodrigo-brito-しばらくの間このエラーが発生し、docker deamonを再起動することで問題が解決しました-プロジェクトに別のサービスを追加してから、もう問題は解決していません。

同じ問題がありますが、セットアップはかなり簡単です。
サイズが164MBのイメージに基づくverdaccio3コンテナーは1つだけです。
これは非常に残念です：/

2015年からMBPPro13を使用しています

ポート範囲が広いために私に起こりましたが、実際にはポートごとに1つのルールが作成されます。

単純なsudo service docker restart 、発生するたびに一貫してこれを解決します。

私にも起こりました。私の場合は、Azure DevOpsでdocker-compose push （アプリを実行しようとさえしていません）です。

私の他のビルドはdocker-composeを使用していませんが、プレーンなdocker push

dockuntu 18.04.1 docker.ioバージョンのdockerを削除し、docker-ce18.09.0をインストールしました
問題はなくなりました。

代わりに、 docker-composeプッシュステップを個別のプッシュに変換しました。

docker-composeまたはdocker-pyライブラリを介してコンテナを実行すると、このタイムアウトが発生します（タイムアウトを2分に上げた後でもタイムアウトします）。 ただし、Docker CLIを介して実行してもエラーは表示されません（コンテナーは即座に起動します）。 また、この問題はLinux CIサーバーでのみ発生し、Macでは発生しません。 私たちは、最小限の再現可能な例の構築に取り組んでいます。

macosホスト上のdebianVMのdocker-compose killでこの問題が発生した場合

log-driverでdockerを起動したときに同じエラーが発生しました：rsyslogポートが利用できない場合のsyslog。
Error starting container 0ba2fb9540ec6680001f90dce56ae3a04b831c8146357efaab79d4756253ec8b: UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)

Dockerを再起動するとうまくいきます。

@ rodrigo-britoの再起動は解決策ではありません...

ポート範囲が広いために私に起こりましたが、実際にはポートごとに1つのルールが作成されます。

私にとってもまったく同じことです。 エラー後、dockerデーモンは枯渇するまでメモリを消費し続けます。 システムが死ぬ前にsystemctl stop dockerする必要があります。 （Dockerバージョン18.09.3、ビルド774a1f4）

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

dockerを再起動するだけで、これは解決しました...

この問題は、最近のdocker-ceバージョンでもまだ存在しているようです。 私は最大5つのコンテナーを開始していますが、遅いコンテナーには、NFS共有を指すDockerボリュームマウントがあります。 ポートを公開するコンテナはありません。これが有効なエラーであるかどうか誰かが判断しましたか（ port=Noneは疑わしいようです）？

~~~
クライアント：
バージョン：18.09.5
APIバージョン：1.39
Goバージョン：go1.10.8
Gitコミット：e8ff056dbc
構築：2019年4月11日木曜日04:44:28
OS / Arch：linux / amd64
実験的：誤り

サーバー：Dockerエンジン-コミュニティ
エンジン：
バージョン：18.09.5
APIバージョン：1.39（最小バージョン1.12）
Goバージョン：go1.10.8
Gitコミット：e8ff056
構築：2019年4月11日木曜日04:10:53
OS / Arch：linux / amd64
実験的：誤り
~~~

--verboseからの出力をさらに追加しました。 ここでは何の役にも立たないと思いますが、コンテナ作成操作が長時間待機していると長い間言っているだけです。 次のメッセージが約1x /秒で出力されるため、ポーリングを使用しているようです。

〜compose.parallel.feed_queue：保留中：set（）〜

接続はdocker.sockで行われるため、localhost / port = Nodeは少し赤いニシンだと思います。したがって、どこかに隠されたnilエラーではありません。 これはdocker内で追跡する必要があると思いますが、ここでのこのリクエストのdocker-compose処理が最適ではありません。

Docker-composeには、ログに記録できるある種のリクエストIDがないようです。そのため、どのリクエストが停止しているかがわかります。 たとえば、タイムアウト内にapiコンテナを作成できなかったのはわかっていますが、リクエストログはまったく役に立ちません。 多分誰か他の人がここにいくつかの情報を追加することができます：

~~~
urllib3.connectionpool._make_request：http：// localhost：None "POST /v1.25/containers/create?name=api-memcache HTTP / 1.1" 201 90
urllib3.connectionpool._make_request：http：// localhost：None "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable：docker create_container-> {'Id'： '22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f'、
「警告」：なし}
compose.cli.verbose_proxy.proxy_callable：dockerdisconnect_container_from_network->なし
compose.cli.verbose_proxy.proxy_callable：docker inspect_container <-（ '22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f'）
compose.cli.verbose_proxy.proxy_callable：docker connect_container_to_network <-（ 'ba67095c5ea718af13a09798bc2f5ab24f5d0b54ce684b6f4cb248ab705df900'、 'proxy'、aliases = ['redis'、 'ba67095c5ea7']、ipv4_
urllib3.connectionpool._make_request：http：// localhost：None "GET /v1.25/containers/22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f/json HTTP / 1.1" 200なし
urllib3.connectionpool._make_request：http：// localhost：None "POST /v1.25/containers/create?name=api HTTP / 1.1" 201 90
compose.cli.verbose_proxy.proxy_callable：docker create_container-> {'Id'： '1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec'、
「警告」：なし}
compose.cli.verbose_proxy.proxy_callable：docker inspect_container <-（ '1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec'）
compose.parallel.feed_queue：保留中：set（）
urllib3.connectionpool._make_request：http：// localhost：None "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
urllib3.connectionpool._make_request：http：// localhost：None "POST /v1.25/networks/proxy/connect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable：docker 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：dockerdisconnect_container_from_network->なし
compose.cli.verbose_proxy.proxy_callable：dockerconnect_container_to_network->なし
compose.cli.verbose_proxy.proxy_callable：dockerdisconnect_container_from_network <-（ '22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f'、 'proxy'）
compose.cli.verbose_proxy.proxy_callable：docker connect_container_to_network <-（ '7d81ef23610f1b8f7ac95837cbf6c9eef977b5b0846fea24be5c7054e471df39'、 'proxy'、aliases = ['comments'、 '7d81ef23610f']、aliases = ['comments'、 '7d81ef23610f']
compose.cli.verbose_proxy.proxy_callable：docker inspect_container-> JSON .. ..
urllib3.connectionpool._make_request： http：// localhost ：None "POST /v1.25/containers/create?name=api-comments-db HTTP / 1.1" 201 90
compose.cli.verbose_proxy.proxy_callable：docker start <-（ 'ba67095c5ea718af13a09798bc2f5ab24f5d0b54ce684b6f4cb248ab705df900'）
compose.parallel.feed_queue：保留中：set（）
compose.parallel.feed_queue：保留中：set（）
compose.cli.verbose_proxy.proxy_callable：dockerdisconnect_container_from_network <-（ '1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec'、 'proxy'）
compose.cli.verbose_proxy.proxy_callable：docker create_container-> {'Id'： 'ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af'、
「警告」：なし}
urllib3.connectionpool._make_request： http：// localhost ：None "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
urllib3.connectionpool._make_request： http：// localhost ：None "POST /v1.25/networks/proxy/connect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable：docker inspect_container <-（ 'ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af'）
compose.cli.verbose_proxy.proxy_callable：dockerdisconnect_container_from_network->なし
compose.parallel.feed_queue：保留中：set（）
compose.cli.verbose_proxy.proxy_callable：dockerconnect_container_to_network->なし
compose.cli.verbose_proxy.proxy_callable：docker connect_container_to_network <-（ '22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f'、 'proxy'、aliases = ['memcache'、 '22b774d0451c']、ip
compose.parallel.feed_queue：保留中：set（）
urllib3.connectionpool._make_request： http：// localhost ：None "GET /v1.25/containers/ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af/json HTTP / 1.1" 200なし
urllib3.connectionpool._make_request： http：// localhost ：None "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable：docker start <-（ '7d81ef23610f1b8f7ac95837cbf6c9eef977b5b0846fea24be5c7054e471df39'）
compose.parallel.feed_queue：保留中：set（）
compose.cli.verbose_proxy.proxy_callable：dockerdisconnect_container_from_network->なし
compose.cli.verbose_proxy.proxy_callable：docker inspect_container-> JSON .. ..
urllib3.connectionpool._make_request： http：// localhost ：None "POST /v1.25/networks/proxy/connect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable：docker connect_container_to_network <-（ '1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec'、 'proxy'、aliases = ['api'、 '1b67251d4941' = ['api'、 '1b67251d4941']、ip
compose.cli.verbose_proxy.proxy_callable：dockerdisconnect_container_from_network <-（ 'ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af'、 'proxy'）
compose.cli.verbose_proxy.proxy_callable：dockerconnect_container_to_network->なし
compose.cli.verbose_proxy.proxy_callable：docker start <-（ '22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f'）
compose.parallel.feed_queue：保留中：set（）
urllib3.connectionpool._make_request：http：// localhost：None "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
urllib3.connectionpool._make_request：http：// localhost：None "POST /v1.25/networks/proxy/connect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable：dockerdisconnect_container_from_network->なし
compose.cli.verbose_proxy.proxy_callable：dockerconnect_container_to_network->なし
compose.cli.verbose_proxy.proxy_callable：docker connect_container_to_network <-（ 'ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af'、 'proxy'、aliases = ['ff8c5cc4cb87'、 'proxy'、aliases = ['ff8c5cc4cb87'、 'commentsなし）
compose.cli.verbose_proxy.proxy_callable：docker start <-（ '1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec'）
urllib3.connectionpool._make_request：http：// localhost：None "POST /v1.25/networks/proxy/connect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable：dockerconnect_container_to_network->なし
compose.cli.verbose_proxy.proxy_callable：docker start <-（ 'ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af'）
compose.parallel.feed_queue：保留中：set（）
compose.parallel.feed_queue：保留中：set（）
compose.parallel.feed_queue：保留中：set（）
compose.parallel.feed_queue：保留中：set（）
..。
-約30行省略
..。
APIコメントの作成...完了
compose.cli.verbose_proxy.proxy_callable：dockerstart->なし
compose.parallel.parallel_execute_iter：終了した処理：ServiceName（project = 'api'、service = 'comments'、number = 1）
compose.parallel.feed_queue：保留中：set（）
compose.parallel.parallel_execute_iter：終了した処理：
compose.parallel.feed_queue：保留中：set（）
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：dockerstart->なし
compose.parallel.parallel_execute_iter：処理が終了しました：ServiceName（project = 'api'、service = 'memcache'、number = 1）
compose.parallel.feed_queue：保留中：set（）
compose.parallel.parallel_execute_iter：終了した処理：
compose.parallel.feed_queue：保留中：set（）
compose.parallel.feed_queue：保留中：set（）
compose.parallel.feed_queue：保留中：set（）
compose.parallel.feed_queue：保留中：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：dockerstart->なし
api-comments-dbの作成...完了
compose.parallel.feed_queue：保留中：set（）
compose.parallel.parallel_execute_iter：終了した処理：
compose.parallel.feed_queue：保留中：set（）
compose.parallel.feed_queue：保留中：set（）
compose.parallel.feed_queue：保留中：set（）
compose.parallel.feed_queue：保留中：set（）
compose.parallel.feed_queue：保留中：set（）
-〜15行省略
api-redisの作成...完了
compose.parallel.feed_queue：保留中：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：dockerstart->なし
compose.parallel.parallel_execute_iter：終了した処理：ServiceName（project = 'api'、service = 'redis'、number = 1）
compose.parallel.feed_queue：保留中：set（）
compose.parallel.parallel_execute_iter：終了した処理：

compose.parallel.feed_queue：保留中：set（）

--100行以上を省略
compose.parallel.parallel_execute_iter：失敗：ServiceName（project = 'api'、service = 'api'、number = 1）
compose.parallel.feed_queue：保留中：set（）

エラー：APIの場合UnixHTTPConnectionPool（host = 'localhost'、port = None）：読み取りがタイムアウトしました。 （読み取りタイムアウト= 60）
compose.parallel.parallel_execute_iter：失敗しました：
compose.parallel.feed_queue：保留中：set（）

エラー：APIの場合UnixHTTPConnectionPool（host = 'localhost'、port = None）：読み取りがタイムアウトしました。 （読み取りタイムアウト= 60）
compose.cli.errors.log_timeout_error：HTTPリクエストが完了するのに時間がかかりすぎました。 --verboseを指定して再試行し、デバッグ情報を取得します。
ネットワークの状態が遅いためにこの問題が定期的に発生する場合は、COMPOSE_HTTP_TIMEOUTをより高い値（現在の値：60）に設定することを検討してください。
~~~

@titpetricは、私もこの問題を抱えていることを確認できます。

私見この問題は、docker-compose側ではなく、docker側にあります。 誰かがdockerdeamonのデバッグログをオンにして、そこでの遅延を特定し、アップストリームで問題を報告する必要があります。 それがなければ、これを簡単に再現できるかどうかはわかりません。

誰かが時間を割いてくれるなら、ボリュームマウント用に完全にロードされたフォルダを作成してこれを複製することをお勧めします（約100000以上のファイル/フォルダがあるものが必要です）、問題の信頼できる再現かどうかを確認します達成することができます。 Dockerデーモン、またはカーネルバインドマウント自体が、iノードデータの一部を事前にキャッシュしている可能性があります。 これは...残念です。

ネットワークファイルシステム（samba、nfs）の場合、tcpdumpでこれを確認することもできます。

ここで同じ正確なエラー

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（host = 'localhost'、port = None）：読み取りがタイムアウトしました。 （読み取りタイムアウト= 60）

作成ファイルのポートの不一致または割り当てが原因ですか？

はい、常にこの問題に直面しています。 再起動は解決策ではないことに同意しますが、他に何もうまくいかないようです：/

参考までに、私の場合はdocker-composeで再試行するだけで解決する傾向があります
それ。 dockerdを再起動したことはないと思います。この問題は、
私。

13:39アレックスで金、2019年8月2日に[email protected]書きました：

はい、常にこの問題に直面しています。 再起動はそうではないことに同意します
解決策ですが、他に何もうまくいかないようです：/

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/docker/compose/issues/3927?email_source=notifications&email_token=AABY7EH4MVKGI56ZLEIUV5TQCQMHBA5CNFSM4CPDX2D2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AABY7EA3NTUP5SNZRTFWFEDQCQMHBANCNFSM4CPDX2DQ
。

私もこの問題に直面しています:(
UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)

ここでも同じ問題が発生しますが、Dockerを再起動すると実際にハングします。 唯一の方法は、ドッカーを殺す/または再起動することであるが、それは解決することはできません。

@bitbrainうん、これは私にもかなり前から起こっている。

私はこれに対するきちんとした解決策を見つけました（MacOS上で）

これが私に起こり続けた理由は、Dockerが利用可能なメモリをほとんど必要としなかったためです。

メモリを2GBから8GBに増やすと、問題が解決しました。

docker-compose upを実行してからdocker-compose downを数回実行した後、このエラーが発生していました。 私はこのスレッドですべてを試しました。 リソースをバンピングし、Macを再起動して、最新のDockerを再インストールします。 ボックスを再起動した後、 docker-compose upを再度実行できましたが、これらのコマンドを数回繰り返した後、このエラーに戻り、 docker-compose upを実行できません

私の問題は、コンテナの1つがポート80にもバインドされていたときに、ポート80にバインドされていた別のサービス（ pow ）との競合であったようです。powをアンインストールしましたが、3日間問題は発生していません。

3年間このチケットを開きますが、まだ解決されていません。 クライアント接続を120秒に増やしても、問題は引き続き発生します。

私たちのサーバーに起こったばかり、2016年以来の未解決の問題、wtf

Dockerを再起動するとうまくいきます。

@ rodrigo-britoの再起動は解決策ではありません...

私の男。

また、これを今経験しています。 野生。

docker-composeupまたはdocker-composedownを試したときに同じ問題が発生します。 mysqldサービスを停止して解決し、コンテナが起動したらmysqlを起動します。 RAMの使用率は20％です。

Macv2.1.0.5用のDockerデスクトップコミュニティの実行

私はこの問題に遭遇し、Dockerに割り当てられるメモリの量を増やす（そしてCPUの量を減らす）ことで解決しました。
これは、Docker->環境設定->詳細設定で実行できます。
特定のセットアップのために、8CPUと2GBRAMから4CPUと16GBRAMに変更しました。

Ubuntu Server 18.04LTSでこの問題が発生しました。 dockerを再起動しても、同様に環境変数を設定しても問題は解決しません。 何か案は？

@bpogodzinski Dockerでメモリ設定を増やしようとしましたか？ 2GBから8GBに増やしたところ、問題は解決しました。

一般的に、この問題は、コンテナーがDockerで構成された使用可能なメモリーよりも多くのメモリーを必要とし、その後、処理がハングした場合に発生するようです。

この問題が発生しましたが、（私たちにとっては）多くのファイルがある名前付きボリュームに関連しているようです。 私はそれを理解していませんが、サービスを備えたdocker-compose（簡潔にするために編集）は私たちの場合です：

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

   volumes:
       - serviceA_volume:

serviceAのDockerfileの中には、一見無害で効果のないコマンドがあります。

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

これにより、/ srvA / folderの所有者が再帰的に変更されることに注意してください。これは、名前付きボリュームでは、100Kのファイルを含む大規模なファイルシステムです。 ただし、これは、イメージがビルドされ、そのフォルダーが空の場合に発生します。 名前付きボリュームを使用しているように見えますが、イメージローカルファイルのアクセス許可を継承してから、名前付きボリュームのアクセス許可の変更に進みます。

これはかなりエッジがあり、おそらく他の人が抱えている問題と同じではありませんが、それは私たちの問題でした（行を切り替えるとエラーが切り替わります）。 結果として、このhttpタイムアウトはおそらく複数の原因が原因です。

私の場合、dockerを再起動しても問題は解決せず、リソースを増やしても問題は解決しました。

私の経験から、この問題は、通常の機能ではRAMの量は完全に問題ないが、dockerまたはdocker-compose操作では不十分であることが判明した小さなクラウドインスタンスでよく発生します。 RAMは簡単に増やすことができますが、小さなVMのコストはおそらく大幅に増加します。

いずれの場合も、スワップパーティションまたはスワップファイルを追加することで、この問題は解決しました。

ちょうどラズベリーパイで私に起こりました。 大量のファイルなどを含むボリュームはありません。
実際、私はしばらくの間、そのラズベリーにこれらのコンテナをスポーンしてきました（1、2年笑）。
何が変わったのかわからない。
少し「突然」のようです。

MacOのDockerデスクトップ2.2.0.3でも問題が発生します🙁

次のコマンドで問題を解決しました。
docker volume prune
docker system prune
（これらのコマンドの1つだけで十分かもしれませんが、現時点では再現できません...）

次のコマンドで問題を解決しました。
docker volume prune
docker system prune
（これらのコマンドの1つだけで十分かもしれませんが、現時点では再現できません...）

@amaumontのソリューションは経過とともに戻ってくると思います。
他の誰もが言っているように、dockerを再起動することは適切な解決策ではなく、バンドエイドです。

docker-composeにも複数の問題があります。

sshd_configでMaxSessions 500を設定した後（＃6463を参照）、読み取りタイムアウトも発生します。
両方のタイムアウトを120秒に設定すると、次のDOCKER_HOST=xxx<strong i="8">@yyy</strong> docker-compose up -d実行の問題が解決しました。

2回目の実行中に、タイムアウトが原因でdocker-composeコマンドが失敗する前に、マシンの負荷が30 （sic！）に達しました。 Dockerを再起動しても、一時的であってもこの問題は解決しませんでした。
サーバーは十分なCPU /ディスク/ NetIOなどを備えたAWSEC2インスタンスであり、作成ファイルには1つのtraefikとmailhogを使用した3つのサービスが含まれているため、ここでは特別なことは何もありません。 同じdocker-compose.ymlファイルを使用してdocker-compose up -dをサーバー上で直接実行すると、確実に期待どおりに機能します。
--verboseを指定して実行すると、 compose.parallel.feed_queue: Pending: set()を含む1000を超える連続した行が表示されます。

回避策として、docker-composeファイルをリモートサーバーにrsyncし、そのマシンで直接docker-composeを実行してみます。

私にとっては、dockerを再起動するだけで済みました。

bitbucketパイプラインからプライベートレジストリにプッシュしようとすると、かなり頻繁に発生します。 ローカルPCからプッシュするときにうまく機能します。
dockerを再起動するとしばらくは役立つ場合がありますが、この「while」は最大10分間続きます：c

upd。 DOCKER_CLIENT_TIMEOUTとCOMPOSE_HTTP_TIMEOUTを設定すると効果があるようですが、どのくらいの期間かわかりません

キャッシュをオンにしてDockerEdgeに切り替えてから、これらを取得し始めました

これは、2〜3年前にDockerを使い始めて以来、かなり一貫して発生しています。 コンテナがしばらく実行された後、それはゾンビになり、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 Mojave10.14.6。

同じ問題に直面しましたが、リソースを4GB RAM、1GBスワップから6GB RAM、2GBスワップに増やしました。

私も同じ問題に直面しています

同じ問題を抱えている

HTTPSを使用するUbuntu18.04 LTS（8 GB RAM）で同じ問題に直面しています。

docker-compose upでコンテナを生成することはできますが、一度デプロイすると、 docker-compose downコンテナを停止することはできません。 dockerデーモンの再起動または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デーモンレベルでログドライバーを構成しています。 私はロギングドライバーとしてfluentdを使用しているので、残念ながらこの修正は私には機能しません。 = /

これを試しました

export DOCKER_CLIENT_TIMEOUT=120
export COMPOSE_HTTP_TIMEOUT=120

今のところ問題は解決しているようです

このスレッドで言及されている他のソリューション：

• Dockerを再起動します
• DockerのCPUとメモリを増やす

まあ、タイムアウトオプションを除いて、私には何もうまくいきませんでした、あなたへの称賛。

コンテナの1つでNFSマウントされたディレクトリを使い始めてから、これが発生します。 そのNFSマウントされたディレクトリは、低速リンク上にあります（低帯域幅接続のあるリモートロケーション内）。 それが問題でしょうか？

これは、MacのDocker 2.4.0.0で、docker-compose.yml構成が異なる2つの異なるプロジェクトで頻繁に発生しています。 2.4.0.0にアップグレードした約1週間前に起こったことを覚えていません。 回帰はありますか？

タイムアウトを600に増やし、RAMを16GBに増やしてスワップを4GBに増やし、Dockerを再起動し、Macbook全体を再起動しようとしましたが、ランダムに何度も試行する以外は何も機能しないようです。 しかし、次にコンテナを再起動または再構築する必要があるときは、同じ問題が発生します:(

Macでも2.4.0.0でこれを見始めました。 私の回避策はdockerを再起動することですが、後で再び発生します。

こっちも一緒！ 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）以降、このタイムアウトエラーが頻繁に発生し始めました。

MacOSCatalinaでDockerDesktop 2.4.0.0（48506）に更新してから、これが頻繁に発生しています。

Mac OSの2.4.0.0以降、同じタイムアウトの問題が発生します。 私はこれまでこの問題を経験したことがありません。
エッジビルド2.4.1.0（48583）を試しましたが、それでも同じ問題が発生します。

同じ問題が発生し、Dockerを再起動するとMacOs Catalina（10.15.5）とdockerバージョン2.4.0.0で修正されました

ここでも同じですが、Dockerデスクトップ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はどのくらい遅いネットワークですか？

ダウングレードも私のために働いた。 Homebrewを介してDockerを管理している人向け

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を変更することでそれが解決されるとしたら驚きます。

こっちも一緒。 Docker for Mac v2.4で前述のHTTPタイムアウトエラーが発生する、コンテナー作成の大幅な速度低下。 COMPOSE_HTTP_TIMEOUT = 120の設定は機能しましたが、コンテナー作成の速度低下は依然として新しい問題です。 v2.3にダウングレードすると、これも修正されます。

Docker for Mac v2.4にインストールしてから、同じ問題を確認できます。
また、Dockerデーモンを実行しているだけで、アイドル状態でもRAMとCPUの消費量が大幅に増加していることを確認できます。 しかし、composeパッケージ自体とは何の関係もないと思います。

私はこれと同じ問題を抱えていました。 @ddesrousseauxによって言及されたリンクから2.40をアンインストールし、2.3をインストールしました。コンテナの起動時に、非常に遅いまたはタイムアウトが発生しなくなりました。

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

この問題は、Docker v。 2.4.3.0も引き続き存在します。

また、2.4リリースでの大幅な速度低下の問題を回避するために2.4から2.3にダウングレードしました。 ここで何が起こっているかをデバッグするのに役立つかもしれないログを提供してください。

上記を反映して、これは私にとって2.4.2.xで起こり始めました。 2.3からのアップグレードで何かが変更されました。

Linux環境でテストを行ったところ、同様の問題が発生しました。 最新のdocker-composeバイナリ（v1.27.4）をインストールしましたが、皆さんが報告しているのと同じタイムアウトの問題がありました。

Docker for Mac 2.3で利用可能なものと同じ1.27.2にダウングレードした後、問題は解消されました。

Ubuntu20.04の現在のバージョンと同じ問題。

私の問題は、dockerとdocker-composeをsnapとaptでイ​​ンストールしたことでした。 それらをアンインストールして再起動し、 https：//docs.docker.com/engine/install/ubuntu/およびhttps://docs.docker.com/compose/install/の公式インストール手順に従いました

2.5.0ではまだ修正されていない2.4.0アップデート以降、タイムアウトエラーが頻繁に発生します。

はい、ここでも同じです。 過去2年間、私にとっては問題なく機能していました。 しかし、2か月前に突然、1つのインスタンスを作成し、別のDockerプロジェクトを開始したい場合は次のようになります。
apacheの場合UnixHTTPConnectionPool（host = 'localhost'、port = None）：読み取りがタイムアウトしました。

Dockerを再起動すると、問題が修正されます。 しかし、1日に複数回プロジェクトを切り替える必要がある場合は本当に苦痛です

2.4以降、同じ問題が発生し、常に300％のCPU、2.5は役に立たず、2.3にダウングレードされ、問題はありません。 これは、i7CPUと32GRAMを搭載した最新のMacBookに搭載されています

最後のDockerfor Macバージョン（v2.5.0.1）にアップグレードしたところ、問題は解決したようです。
UnixHTTPConnectionエラーがなくなり、CPUが100％使用されなくなりました。

他の誰かがそれを確認できるかどうかわからない。

どうやってそれを手に入れたの？ MacでDockerを開いて「アップデートの確認」を実行すると、最新の2.4.2.0がまだあると表示されます。

最後のDockerfor Macバージョン（v2.5.0.1）にアップグレードしたところ、問題は解決したようです。
UnixHTTPConnectionエラーがなくなり、CPUが100％使用されなくなりました。

他の誰かがそれを確認できるかどうかわからない。

v2.5.0.1で問題が発生しました。 dockerを再起動すると、（少なくとも一時的に）問題が解決するようです。

どうやってそれを手に入れたの？ MacでDockerを開いて「アップデートの確認」を実行すると、最新の2.4.2.0がまだあると表示されます。

すでにアップグレードしているため、スクリーンショットを表示できませんが、以前のv2.5.0バージョンが1週間以上利用可能であるため、コンピューターから更新を取得するのに問題があると思います。

Docker for Macのリリースノートで確認でき

Edgeを実行しています。 それはおそらくそれを説明しています。

v2.5.0.1が少なくともわずかに優れていることを確認できます。 起動のたびにタイムアウトが発生することはなくなり、今朝の更新以降、まだタイムアウトに遭遇していません。 ただし、コンテナの起動時間は2.3よりもはるかに遅いようです。

編集： docker-composeプロジェクトを約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

v2.5.0.1が少なくともわずかに優れていることを確認できます。 起動のたびにタイムアウトが発生することはなくなり、今朝の更新以降、まだタイムアウトに遭遇していません。 ただし、コンテナの起動時間は2.3よりもはるかに遅いようです。

編集： docker-composeプロジェクトを約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

OK、2.5.0.1バージョンでもまだいくつかの問題に直面しています。 CPU使用率はv2.3.xと比較してまだ高すぎ、速度もかなり遅いです。

Dockerチームの誰かがこれを認めて検討することはできますか？

神様、4年経ちましたが、この問題はまだ解決されていません、そしてそれはいつも私に起こります