compose: UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)

tried this

export DOCKER_CLIENT_TIMEOUT=120
export COMPOSE_HTTP_TIMEOUT=120

and it seems to fix the issue for now

Other solutions people mentioned in this thread:

• Restart Docker
• Increase Docker CPU & memory

FWIW: For the people landing here through search engine finding their resolvement, I’ve been able to fix this simply by the did you try turning it off and on again? method; I’ve restarted my Docker Mac OS client.

restarting Docker works to me.

God,4 years passed,this issue still not solved,and it happens to me all the time

restarting Docker works to me.

@rodrigo-brito restarting is not a solution…

Restart is not a fix guys… How to avoid this for good?

A simple sudo service docker restart solves this for me consistently every time it occurs.

This started happening to me on Docker for Mac since I updated to Docker 3.0.0 today (whenever I do docker-compose up). Restarting Docker for Mac fixes it, but only allows me to do docker-compose up a few times before having to restart it again.

+1 I am seeing this timeout issue every single week, usually after an idle weekend, while I was trying to connect to me containers, it timed out… I have to terminate the running docker proc and restart it to work around…

From different attempts at working around this, I found something that might shed some light on a possible fix:

At first my scenario looked a bit like this:

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

My mounted path included many directories with big, static files that I didn’t really need mounted in terms of code reloading. So i ended up swapping for something like this:

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

This left out of the runtime mounting all my big static files, which made the service start way faster.

What I understand from this is: the more files you mount, especially the larger they are (images in the MBs instead of source files in the Bs/KBs), loading times go up by a lot.

Hope this helps

I’m seeing exactly the same problem with latest beta for Mac. Same error if I run docker-compose create

Could this be related to having one very large layer in the image? (a very lengthy npm install operation that takes about a minute to be flattened into a layer when docker builds the image)

Happinging with a 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).

Forget the stupid “turn it off and on again” advice or systemctl restart docker.service, they won’t fix the problem, it’ll happen again in the future. You need to configure docker to wait longer for the task that’s taking too much time, that’s all. Add these parameters into your docker service file under the [Service] section:

Environment="DOCKER_CLIENT_TIMEOUT=120"
Environment="COMPOSE_HTTP_TIMEOUT=120"

just happend to our server, open issue since 2016, wtf

restarting Docker works to me.

@rodrigo-brito restarting is not a solution…

my man.

Happened to me because of a large port range, it actually creates one rule per port…

I got the same issue after adding loki plugin.

docker plugin install grafana/loki-docker-driver:latest --alias loki --grant-all-permissions

What I did was disabled the plugin:

docker plugin disable loki --force

and then I was able to stop the containers without issues.

docker-compose down

I just enabled it back before going up again.

docker plugin enable loki
docker-compose up -d

I hope it works for some of you at least.

Okay this is ridiculous, but this Stackoverflow answer is what actually fixed it for me.

If you have any logging: options: max-file: 10 entries in your docker-compose.yml, try making them strings:

logging:
  options:
    #max-file: 10  # bad
    max-file: '10' # good

EDIT:

$ docker version
Client: Docker Engine - Community
 Cloud integration: 1.0.12
 Version:           20.10.5
 API version:       1.41
 Go version:        go1.13.15
 Git commit:        55c4c88
 Built:             Tue Mar  2 20:13:00 2021
 OS/Arch:           darwin/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.5
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       363e9a8
  Built:            Tue Mar  2 20:15:47 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.4
  GitCommit:        05f951a3781f4f2c1911b05e61c160e9c30eaa8e
 runc:
  Version:          1.0.0-rc93
  GitCommit:        12644e614e25b05da6fd08a38ffa0cfe1903fdec
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

I’m experiencing this very frequently on Mac, Docker 2.4.0.0, in two different projects with different docker-compose.yml configs. I don’t recall it ever happening before ~1 week ago which is when I upgraded to 2.4.0.0. Is there a regression?

I’ve tried increasing the timeout to 600, increasing RAM to 16GB & swap to 4GB, restarting Docker, restarting my entire Macbook, nothing seems to work, except randomly trying again and again then it will occasionally work. But then the next time I need to restart or rebuild a container, same problem 😦

Same issue here, also on mac and after the 2.4.0 update. I’m currently trying if downgrading helps.

Update: downgrading to the previous version, deleting cache and rebuilding fixes the issue.

3 years open this ticket and still unresolved. The problem still occurs even if we increase the client connection to 120 sec.

+1 on that, I am running stress testing on my instance which runs 4 containers and docker hangs even for docker ps -a so i’m trying to restart the containers but i am getting UnixHTTPConnectionPool(host='localhost', port=None): Read timed out and

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)

Only if im restarting the docker service it seems to be resolved, any ideas?

Okay this is ridiculous, but this Stackoverflow answer is what actually fixed it for me.

If you have any logging: options: max-file: 10 entries in your docker-compose.yml, try making them strings:

logging:
  options:
    #max-file: 10  # bad
    max-file: '10' # good

Ridiculous is right. Holy moly, I’ve been trying to fix this issue all afternoon. Thanks!

simple restart of docker solved this for me…

encountering this issue as well, still no solution???

Had been running 2.3.0.5 to avoid this issue, but after the latest MacOS upgrade to 11.3, Docker 2.3.x won’t run anymore. Now running 3.3.1 and experiencing this issue.

I had this same issue. Was running 2.3.0.5 for a long time because all upgrades failed to run our docker compose setup. After upgrading to macOS 11.3 (from 10.x), Docker stopped working completely. I tried the latest 3.x without any good results. So now I’ve downgraded even further to 2.2.0.5 and this version works for me again. What a complete mess. Maybe we should go back to Vagrant…

I faced the same issue and it’s solved for me when I removed dangling images using the below command docker rmi $(docker images --filter "dangling=true" -q --no-trunc)

I have this same issue, but the only thing that fixes it for me is downgrading to 2.3.0.5.

I tried 2.4.0.0 and today 2.5.0.1, but those do not work for my setup. My setup has a docker-compose file with 41 docker images that all start together. 2.3 starts them fine. The newer versions break the startup process after successfully starting around 30 images. After that I cannot even start one extra via command line or docker dashboard. Docker engine seems unresponsive and gives the timeouts. Increasing timeout time or restarting docker/macOS does not help. Docker already has access to 6 CPUs, 16GB RAM, 1GB swap and 60GB SSD (8GB used). OS: macOS Catalina 10.15.7

I’m still experiencing frequently timeout errors since the 2.4.0 update that are still not fixed in 2.5.0

I resolved my issue with the following commands: docker volume prune docker system prune (only one of these commands might be enough, but cannot reproduce for the moment…)

We’re seeing this timeout when running a container via docker-compose or via the docker-py library (times out even after we bump the timeout to 2 minutes); however, we don’t see the error when we run via the Docker CLI (container starts instantly). We also only see the issue on a Linux CI server and not on our Macs. We’re working on building out a minimal reproducible example.

+1

`Restarting web-jenkins_jenkins_1 …

ERROR: for web-jenkins_jenkins_1 UnixHTTPConnectionPool(host=‘localhost’, port=None): Read timed out. (read timeout=130) 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: 120).`

i restart docker, it solved. but every day i need to restart

Having this issue “sometimes” on EC2 instance when trying to deploy with Gitlab Runner. Any help?

I have been plagued by this for months. Running Docker 3.3 on MacOS Big Sur. Usually, I just restart docker when it happens (about once / day).

Today though, it happen 5 times in 1 hour so I wanted to try and sort it once and for all.

In docker settings, I enabled “Use gRPC FUSE for file sharing” (I remembered this fixing something Mac related in the past) and it hasn’t happened since. 🤞

I hope this helps someone else.

@beporter Unfortunately, it doesn’t work for me. I don’t have logging configured in my docker-compose.yml and even explicitly adding it still results in the same problem.

@rvanbaalen @angelomelonas My colleagues and me have downgraded to 2.3.0.5 because of this.

Yes I uninstalled the 2.4 and downloaded/reinstalled the 2.3. Now it works, I can start my containers as usual. I got the 2.3 from there: https://docs.docker.com/docker-for-mac/release-notes/#docker-desktop-community-2302

Also started having frequently this timeout error since the 2.4.0 update (on Mac OS Mojave 10.14.5)

Same here! With update to 2.4.0 our setups sometimes do not start at all with the mentioned Read timed out. errors, sometimes only some containers start up, others throw this error. I am already thinking about a downgrade!

Just to mention: This issue affects both setups using NFS shares as well as projects using “normal” mounted volumes

I was having the same issue when I had the following in my docker-compose.yml:

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

The error was gone when I added quotes around “10”. This is stated in docs that the values for max-file and max-size must be string, but still. The error message is quite misleading.

For me, it helped to just restart docker.

I got this error due to low memory issues

I tried below command echo 1 > /proc/sys/vm/drop_caches

After which everything worked properly

FYI, downgrading to 2.2.0.5 worked for me.

@JoeCap08055 I reverted back to Docker Desktop 2.5.0.1 and I don’t have the issue.

I faced same issue, even I increased resource from 4GB RAM, 1GB swap to 6GB RAM, 2GB swap.

+1 restarting docker worked for me as well.

Thanks @gvilarino, I believe the big files mounting is the cause of this issue on my linux server. Your snippet could be a workaround if the big files are not needed in container.

However, I wonder why mounting is slow in Docker? Maybe it triggers disk copy? But why?

@patsevanton If you still have the issue with a recent version of Compose v2, open a new issue with a example to reproduce it

For my case, it is aws cloudwatch log component failed, and container cannot start. check your docker daemon log, it can tell what failed and why it cannot start, resolve that problem first.

journalctl -u docker.service 

Everyone could have different failure reason.

On macOS, I spent hours on this issue and what worked for me was to upgrade Docker Dekstop to v4.1.1.

Before that I had tried to restart the docker client, docker services, I increased the timeout values of DOCKER_CLIENT_TIMEOUT , COMPOSE_HTTP_TIMEOUT, I gave a lot of memory and CPUs to Docker, I pruned every images/volumes/containers, I uninstalled Docker entirely. Nothing worked. Then I simply updated Docker Desktop to v4.1.1 and the error message went away.

Had been running 2.3.0.5 to avoid this issue, but after the latest MacOS upgrade to 11.3, Docker 2.3.x won’t run anymore. Now running 3.3.1 and experiencing this issue.

I can confirm the same problem since I installed on Docker for Mac v2.4. I can also confirm a significant increase of RAM and CPU consumption even in idle moments, just with Docker daemon running. But I guess it has nothing to with compose package itself.

Same here. Significant slowdown in container creation, resulting in the aforementioned HTTP timeout error on Docker for Mac v2.4. Setting COMPOSE_HTTP_TIMEOUT=120 worked, but the container creation slowness is still a new issue. Downgrading to v2.3 also fixes this.

This has been happening pretty consistently for me since I started using Docker 2-3 years ago. After a container has been running for a while, it becomes a zombie and the entire Docker engine needs to be restarted for things to become responsive again. This feels like a resource leak of some kind, since idle time seems to be very relevant for the experienced behaviour.

If no containers are running, or they only run for a short amount of time, everything seems to be working fine for days or weeks. But as soon as I let a container run for a few hours, it becomes unresponsive, I have to force-stop it in the command line and any attempt at communicating with docker or docker-compose just fails with a timeout. A restart is the only working solution.

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

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

I started getting these since switching to Docker Edge with Caching on

We are having multiple issues with docker-compose, too.

After setting MaxSessions 500 in sshd_config (see #6463) we now also get read time outs. Setting both timeouts to 120 seconds resolved the issue for the next DOCKER_HOST=xxx@yyy docker-compose up -d run.

During the second run the machine load went as high as 30 (sic!) before the docker-compose command failed due to timeouts. A docker restart did does not solve this problem, not even temporarily. The Server is an AWS EC2 instance with enough CPU/Disk/NetIO etc, the compose file includes 1 traefik and 3 services with mailhog, so nothing special here. Running docker-compose up -d with the same docker-compose.yml file directly on the server works reliably and as expected. Running with --verbose shows over thousand consecutive lines containing compose.parallel.feed_queue: Pending: set().

I will try to rsync the docker-compose file to the remote server and run docker-compose directly on that machine as a workaround.

We had this issue and it appears (for us) to be related to a named volume with a lot of files. I don’t understand it, but it is the case for us that a docker-compose (edited for brevity) that has a service:

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

   volumes:
       - serviceA_volume:

Inside the Dockerfile for serviceA is the seemingly harmless and ineffectual command:

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

Notice that this changes the owner recursively in /srvA/folder which in the named volume is a large filesystem with 100K’s of files. However, this happens when the image is built and that folder is empty. It appears using the named volume inherits the permissions of the image local file and then proceeds to change the named volumes permissions.

This is pretty edge and probably not the same problem everyone else is having but it was our problem (toggling the line toggles the error). The upshot is that this http timeout is probably resulting from multiple causes.

I found a neat solution to this (on MacOS)

The reason why this kept happening to me was that Docker had to little memory available.

Increasing the memory from 2GB up to 8GB solved the issue for me.

Just a FYI, with my case only retrying with docker-compose tends to resolve it. I don’t think I ever restarted dockerd, this issue doesn’t persist for me.

On Fri, Aug 2, 2019 at 1:39 PM Alex notifications@github.com wrote:

Yep, constantly running into this issue myself. I agree restarting is not a solution, but nothing else seems to do the trick 😕

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/docker/compose/issues/3927?email_source=notifications&email_token=AABY7EH4MVKGI56ZLEIUV5TQCQMHBA5CNFSM4CPDX2D2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3NQBTI#issuecomment-517669069, or mute the thread https://github.com/notifications/unsubscribe-auth/AABY7EA3NTUP5SNZRTFWFEDQCQMHBANCNFSM4CPDX2DQ .

Same exact error here

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 restarting also fixed it for me.

@titpetric can confirm I’m also having this issue.

@rodrigo-brito - I’ve been getting this error for a little while now and restarting docker deamon have been solving the issue - no more since I added another service to my project.

@cherrot I wouldn’t say I’m extremely proficient in the subject, but I believe this has to do with the storage driver used by Docker and how it works internally for keeping layers in order. Use docker info to see what storage driver your daemon is using (probably aufs, which is the slowest) and depending on your host OS, you may change it so something else (overlay being a better choice, if supported). There are faster alternatives like LCFS but they aren’t commercially supported by Docker so you’d be on your own there.

Does it happen if you turn off your WiFi? Could be related to https://github.com/docker/docker-py/issues/1076.

Another theory, if your service has tty: True enabled, could be #3106