compose: Compose error "HTTP request took too long to complete"

By simply restarting the docker service via sudo service docker restart I was able to get the aforementioned error to go away when running docker-compose up.

Note: I did not touch the tty=true parameter as suggested, as I wanted to avoid a quick fix.

I get the same error message.

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

My docker-compose.yml file does not mention tty so this isn’t the problem for me.

Increasing the timeout does nothing.

The only things that work for me are:

1. Retry my docker-compose command. It will eventually work. I often need 2 retries, sometimes more.
2. Restart the docker daemon. (This takes 5 minutes or more.) Then run docker-compose and it usually works.

The fact that it takes so long for me to restart the docker daemon is interesting. Is docker doing something in the background that causes docker-compose to throw this error?

I am running:

ubuntu version 16.04
docker version 1.12.3, build 6b644ec
docker-compose version 1.9.0, build 2585387

UPDATE: I upgraded to docker version 1.12.5 but it did not help.

@aaronjensen I can confirm that removing the tty: true line from the docker-compose.yaml file resolved the issue for me. As a workaround for the tty, I defined TERM=xterm to the containers environment. Do you see any issues with that?

Encountered this fun bug on macOS - fixed with docker-compose restart followed by a docker-compose up

Restarting docker daemon did the trick. My env is MacOS 10.13.4

I faced the same problem and solved it by just restarting the docker services, sudo service docker restart after that i started the docker docker-compose up -d and it works.

The docker-compose up times out.

To reproduce:

mkdir ~/myapp
cd ~/myapp
curl -L "https://raw.githubusercontent.com/bitnami/bitnami-docker-rails/master/docker-compose.yml" > docker-compose.yml
docker-compose up
...
...
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).

Flushing old docker images seems to fix this. So something like,

docker rmi $(docker images --quiet --filter "dangling=true")

After running this, I didn’t see the timeout error anymore (on Ubuntu anyway).

Is anything happening with this issue? We are seeing it all the time now and increasing the timeout doesn’t seem to work.

@sameersbn try disabling tty. I believe this is a dupe of https://github.com/docker/compose/issues/3106

still no real solution for this issue ?

(i’m on MAc OSX too)

The latest reports seem related to https://github.com/moby/moby/issues/35933

I’m going to close this as the thread is a hodgepodge of unrelated issues:

• the tty issue that was fixed in 1.16.0: #3106
• Host resources issue (CPU or RAM limitations makes Engine unresponsive) - the solution is to upgrade the physical machine running the payload or to use clustering to distribute the load between several machines - for the most part that’s out of scope for Compose to manage. Running docker system prune might help free up some disk space / inodes if that’s the issue.
• Legitimately slow / choppy network conditions: this is resolved by increasing the timeout value as the error message suggests.
• Unresponsive container operations (will usually show up while running docker-compose up but might occur with other commands as well): currently being addressed at the engine level https://github.com/moby/moby/issues/35933 (my original assumption that this was a Mac OS specific problem was mistaken - sorry about that)

If there’s anything that isn’t addressed by this list now or in the future with the same symptoms, please open a new thread.

Still have the same issue on 17.12

ERROR: An HTTP request took too long to complete. Retry with --verbose to obtain debug information.

Client:
 Version:      1.13.1
 API version:  1.26
 Go version:   go1.6.2
 Git commit:   092cba3
 Built:        Thu Nov  2 20:40:23 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.12.0-ce
 API version:  1.35 (minimum version 1.12)
 Go version:   go1.9.2
 Git commit:   c97c6d6
 Built:        Wed Dec 27 20:12:29 2017
 OS/Arch:      linux/amd64
 Experimental: false

I’m having the same problem using appcontainers/wordpress recipe on OSX 10.11.6 running docker app 1.12.0-a with 2CPUs and 6Gb RAM. Loading process takes ages for every request.

Furthermore running:

docker compose up

I got this error:

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

Experiencing this issue. I’m running daemonised containers using the command

$ docker-compose up -d

And then tailing the logs using

$ docker-compose logs -f

After about a min, I get the error

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

If I provide a huge value for COMPOSE_HTTP_TIMEOUT, like 10000, then it kind of works for that whole time. Guessing, not measured

I’m not sure the exactly how COMPOSE_HTTP_TIMEOUT is used, but guessing since its a timeout value, its used as any other timeout. Can’t we disable it by setting it to 0 (I have tried setting it to 0, doesn’t work)? Shouldn’t no timeout be the default?

Versions

---

Docker

$ docker version
Client:
 Version:      17.09.0-ce
 API version:  1.32
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:40:09 2017
 OS/Arch:      darwin/amd64

Server:
 Version:      17.09.0-ce
 API version:  1.32 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:45:38 2017
 OS/Arch:      linux/amd64
 Experimental: true
docker-compose 1.16.1, build 6d1ac21

Docker Compose

$ docker-compose version
docker-compose version 1.16.1, build 6d1ac21
docker-py version: 2.5.1
CPython version: 2.7.12
OpenSSL version: OpenSSL 1.0.2j  26 Sep 2016

Restarting docker daemon worked for me on MacOS as suggested by @WernerRaath 4 years ago!

I had a docker-compose.yml with a big port range being forwarded (20k ports) in one of my services. Then I got this error message. I fixed it by reducing the port range to just 300 ports, then it worked fine again.

On Mac, what I did was going to the docker icon (upper right corner) and clicked restart, maybe is not the best solution, but it´s the fastest one

After several consultation of the topic (hoping there would be an out-of-the-box solution), I’m joining the conversation.

I experience the issue also. I never used the tty: true option (I’m not even clear of what it does). But as @shin- suggests, I can pretty much tell this is memory related:

I’m working on a micro-serviced project and often have up to 4 compose process running at the same time on a not-so-powerful machine (4Gb RAM 😕).

Sometimes they’ll start without issue, sometimes I get the error. Individually they all work.

I really don’t have a solution here, only few comments and questions:

• In this case, the error message should be different, ideally with some information about how much memory uses each docker process, what’s available etc. but at least something like You may not have enough memory on your system
• Will increasing the timeout help in that case? The fact that a machine lacks of memory usually slows everything down, but doesn’t prevent the action from happening (or in that case the machine usually freezes)
• How can I have more info about docker & memory usage?
• The suggestion of executing service docker restart doesn’t help since this will take down all already running containers

Thanks, ❤️ docker & compose.

@shin- I’m seeing this issue as well, on a Mac. Versions:

• Mac OS version 10.12.3
• docker version 17.03.0-ce-mac2
• docker-compose version 1.11.2
• docker-py version 2.1.0
• CPython version 2.7.12

My machine was not under high load, there is plenty of RAM, plenty of disk space, etc. My docker-compose file also doesn’t mention tty, but I was using docker-compose run. Increasing COMPOSE_HTTP_TIMEOUT only increased the time before it failed.

After restarting the Docker daemon, it started working again.

I have the same issue, I have tried all the comments above but did not work for me. I finally use one of suggestion above, just restart the docker and resolved the issue.

By simply restarting the docker service via sudo service docker restart I was able to get the aforementioned error to go away when running docker-compose up.

Note: I did not touch the tty=true parameter as suggested, as I wanted to avoid a quick fix.

Fixed Issue Thanks

By simply restarting the docker service via sudo service docker restart I was able to get the aforementioned error to go away when running docker-compose up.

Note: I did not touch the tty=true parameter as suggested, as I wanted to avoid a quick fix.

Can anyone explain why does it work ^^

None of the suggestions here actually work for me.

# docker --version
Docker version 18.09.0, build 4d60db4
# docker-compose --version
docker-compose version 1.22.0, build f46880fe

docker restart hang without response:

# sudo service docker restart
Redirecting to /bin/systemctl restart docker.service

I ran into this issue as well; have to sudo service docker restart to get docker commands to work again. I checked top but didn’t see cpu high usage etc.

No tty: true option in docker-compose.yml

I did notice my inode usage is quite high at 95%

df -ih
Filesystem     Inodes IUsed IFree IUse% Mounted on
udev             493K   390  492K    1% /dev
tmpfs            494K   537  494K    1% /run
/dev/xvda1       1.3M  1.2M   70K   95% /
tmpfs            494K     1  494K    1% /dev/shm
tmpfs            494K     3  494K    1% /run/lock
tmpfs            494K    16  494K    1% /sys/fs/cgroup
tmpfs            494K     4  494K    1% /run/user/1000

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.1 LTS
Release:        16.04
Codename:       xenial


docker-compose version
docker-compose version 1.11.0, build 6de1806
docker-py version: 2.0.2
CPython version: 2.7.13
OpenSSL version: OpenSSL 1.0.1t  3 May 2016


docker version
Client:
 Version:      1.13.0
 API version:  1.25
 Go version:   go1.7.3
 Git commit:   49bf474
 Built:        Tue Jan 17 09:58:26 2017
 OS/Arch:      linux/amd64

Server:
 Version:      1.13.0
 API version:  1.25 (minimum version 1.12)
 Go version:   go1.7.3
 Git commit:   49bf474
 Built:        Tue Jan 17 09:58:26 2017
 OS/Arch:      linux/amd64
 Experimental: false

Coincidentally I think there is some serious memory leak; not sure if it is with docker-compose itself but I notice my system memory usage was ~70% before and now it is at ~17% after restart.

Restarting docker solves it everytime too

Maybe try checking this out https://github.com/docker/compose/issues/4459. It mentions that the values need to be enclosed in quotes. Also here, https://docs.docker.com/compose/compose-file, the docker compose version 3 requires that all boolean values be enclosed in quotes. tty option is set to true or false.

By simply restarting the docker service via sudo service docker restart I was able to get the aforementioned error to go away when running docker-compose up.

Note: I did not touch the tty=true parameter as suggested, as I wanted to avoid a quick fix.

Oh god! Why! the answer to everything is restart! BTW thanks 😃

I had this issue and it turns out that Docker had its “update ready, install now?” dialogue open. After updating Docker and then restarting Docker desktop, the issue went away.

@leovujanic Thanks. Using quotes solved the problem

I just started having this problem as well with docker-compose commands failing with HTTP request took too long. And I am not forwarding many ports.

Docker version 19.03.4, build 9013bf5
docker-compose version 1.24.1, build 4667896b

EDIT: It appears that upgrading docker-compose to docker-compose version 1.25.4, build 8d51620a fixed the issue for me.

This is still an issue after the reset to defaults. @shin- Since this doesn’t seem to be a compose issue, is there a good place to get this in front of the docker team? I’d love to help. At this point, my docker development workflows have ground to almost a halt with all the constant daemon restarting.

I started experiencing the same issue on OSX 10.13.2 (high sierra) after the update to docker 17.12.0-ce and compose 1.18.0. At this point, I’m able to issue docker-compose up once, maybe twice before all docker-compose commands (up, restart, run, exec) hang and exit with this error. docker-compose restart has the same behavior. At this point, the only way I can rescue the situation is the restart docker completely.

@shin- I’m sure there are multiple issues at play here. Last time, after restarting Docker for Mac, the issue went away, so I didn’t get a chance to test if the daemon was responsive.

I hadn’t seen the issue again until today. I am able to launch new containers using the regular docker command, but not through docker-compose. All the circumstances I described previously are still true - the machine isn’t under heavy load, there’s plenty of memory (the Docker for Mac VM RAM usage is also much lower than its limit), etc.

This probably is a docker engine issue, but it only seems to be manifesting through docker compose.

using TERM=xterm still produces exit code 0 when using docker-compose up

I’m running into the same issue frequently. Did you fix it?

BTW: I’m using Docker 1.11.2 and docker-compose 1.7.1