Compose error "HTTP request took too long to complete"

[sameersbn]

Lately I've been noticing the following error message quite frequently with 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).

Increasing the COMPOSE_HTTP_TIMEOUT only seems to delay the error. Is this a known issue and/or is there a workaround for this?

I'm using ubuntu 16.04, please find below the output of docker-compose version and docker version. I'd also like to note that I see this issue with docker for mac beta, docker-machine, etc.

$ docker-compose version
docker-compose version 1.7.1, build 6c29830
docker-py version: 1.8.1
CPython version: 2.7.11+
OpenSSL version: OpenSSL 1.0.2g-fips  1 Mar 2016

$ docker version
Client:
 Version:      1.11.2
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   b9f10c9
 Built:        Wed Jun  1 22:00:43 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.11.2
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   b9f10c9
 Built:        Wed Jun  1 22:00:43 2016
 OS/Arch:      linux/amd64

[shin-]

What command is timing out?

[sameersbn]

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

[sameersbn]

any ideas?

[aaronjensen]

@sameersbn try disabling tty. I believe this is a dupe of #3106

[Fortiz2305]

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

[aaronjensen]

@Fortiz2305 no workaround afaik, see my above comment: #3633 (comment)

[sameersbn]

@aaronjensen thanks for the info. will try it out and get back.

[sameersbn]

@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?

[aaronjensen]

@sameersbn to be honest, I have no idea what the difference between those things would be. If it works for you, great 😄

[karneaud]

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

[a-barbieri]

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

[WernerRaath]

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.

[cecton]

Hello everybody,

My colleagues encountered that issue recently and I did not. But I may have find an important hint 🎉

It's indeed linked to the tty parameter. The applications that run with tty are able to print colors and this is what I get when I do a docker-compose up:

import-concepts_1  | minfo] Packaging /app/target/scala-2.10/import-concepts_2.10-1.3.0.jar ...[0minfo] Done packaging.[33mwarn] there were 2 feature warning(s); re-run with -feature for details
import-concepts_1  | ntains 72 documentable templates[33mwarn] one warning found
import-concepts_1  | minfo] Main Scala API documentation successful.
import-concepts_1  | minfo] Packaging /app/target/scala-2.10/import-concepts_2.10-1.3.0-javadoc.jar ...
import-concepts_1  | minfo] Done packaging.
import-concepts_1  | Starting server. Type Ctrl+D to exit logs, the server will remain in background)
import-concepts_1  |
import-concepts_1  | ver process ID is 115
import-concepts_1  | fo] play - Application started (Prod)
import-concepts_1  | fo] play - Listening for HTTP on /0:0:0:0:0:0:0:0:9000

Here, the application doesn't crash. Notice also that the logs are truncated.

But if in another terminal I do this:

docker-compose logs -f import-concepts

I get this:

import-concepts_1  | [info] Loading global plugins from /root/.sbt/0.13/plugins
import-concepts_1  | [info] Loading project definition from /app/project
import-concepts_1  | [info] Set current project to import-concepts (in build file:/app/)
import-concepts_1  | [info] Packaging /app/target/scala-2.10/import-concepts_2.10-1.3.0-sources.jar ...
import-concepts_1  | [info] Done packaging.
import-concepts_1  | [info] Wrote /app/target/scala-2.10/import-concepts_2.10-1.3.0.pom
import-concepts_1  | [info] Main Scala API documentation to /app/target/scala-2.10/api...
import-concepts_1  | [info] Packaging /app/target/import-concepts-1.3.0-assets.jar ...
import-concepts_1  | [info] Done packaging.
import-concepts_1  | [info] Packaging /app/target/scala-2.10/import-concepts_2.10-1.3.0.jar ...
import-concepts_1  | [info] Done packaging.
import-concepts_1  | [warn] there were 2 feature warning(s); re-run with -feature for details
import-concepts_1  | model contains 72 documentable templates
import-concepts_1  | [warn] one warning found
import-concepts_1  | [info] Main Scala API documentation successful.
import-concepts_1  | [info] Packaging /app/target/scala-2.10/import-concepts_2.10-1.3.0-javadoc.jar ...
import-concepts_1  | [info] Done packaging.
import-concepts_1  |
import-concepts_1  | (Starting server. Type Ctrl+D to exit logs, the server will remain in background)
import-concepts_1  |
import-concepts_1  | Play server process ID is 115
import-concepts_1  | [info] play - Application started (Prod)
import-concepts_1  | [info] play - Listening for HTTP on /0:0:0:0:0:0:0:0:9000
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).

It crashes every time after ~1.5 min. You can't see it on github but the [info] are in orange on the terminal.

As you can see, as soon as there are colors, it can crash.

Hope this will help.

---

Update: I deactivated all the colors of the application, docker-compose still crashes.

[J-Fricke]

Removing tty=true from my compose file seems to initially have solved this for me. I had added it in to solve another issue and that must have been sorted by another change to our Docker setup, as it does not seem to be required now. I'll follow up in a few days to report if this fix sticks for me.

[adaviding]

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.

[shin-]

@adaviding Is your Docker Engine running on a machine that is experiencing high load or has little available memory / disk space? How many containers do you typically have running?

[mbyio]

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

[shin-]

@michael-younkin When you start getting that error with docker-compose, is the daemon otherwise responsive (e.g. can you execute operations through the CLI)? If not, it's probable there is an issue with the Docker For Mac software, or the Docker Engine that's causing the daemon to refuse connections from clients, including Compose.

[augnustin]

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.

[AnthonyWC]

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.

[shin-]

@AnthonyWC This is most definitely an engine issue. Can you report it on their issue tracker? https://github.com/docker/docker/issues

[mbyio]

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

[ctrlaltdylan]

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

[twbecker]

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

[hackaprende]

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

[dev-drprasad]

@leovujanic Thanks. Using quotes solved the problem

[noahtallen]

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.

[cosmos-sajal]

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

[Namanm1994]

Honestly, I could not find the tty which is advised to change in docker compose file.
I could not restart the service, as I am working on a server which is used by 20+ people.
As well, I do not think everytime this issue arises we should restart docker service.
I checked docker-compose up --verbose. It gave an option with no color. since the tty issue also seems to be related to color. Tried the below command, it worked, I will update in a week if it works fine, or earlier if it doesn't.
docker-compose up --no-color
It worked but color is not displaced, so it's workaround(as color doesn't matter). But by this, I am not sure of the cause of the issue as well why no color tag works. As well better solution for this must be available.
EDIT:
I used the docker-compose up --no-color, it is not a permanent solution. I as well used docker-compose up --force-recreate, this as well works at times, doesn't the other times. I found it to be random.
Lastly, instead of restarting the docker service, which seemed not an option in my case, Deleting most of the images (unused) and docker containers (unused) kind of worked. docker-compose up started to work. No error : HTTP request took too long. As well docker-compose up response time increased a lot.

[ytsurk]

In my case (beside restarting the docker service), it helped removing the dns settings from daemon.json ..

[UglyWillDuckling]

Maybe try checking this out #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.

[fil-monterey]

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

[Choongkyu]

after never having had issue for a few months, I've run into this issue at least three times in the last hour between spinning up and spinning down compose on macos. There haven't been any updates nor are there any available. I'm currently on Docker Desktop 3.2.2 and engine 20.10.5

[AshwinParmar]

Make sure any docker updates available, If available install it (Requires root privileges), and restart the docker will fix the issue.

[vpetersson]

Just to chime in here. I had the same issue on macOS with Docker Engine 20.10.5. The root cause for me was insufficient memory. By default Docker Desktop for Mac only allocates 2GB RAM. My stack required a lot more than that, which is how I ran across this error.

[YutaoChow]

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 ^^

[marcellodesales]

Getting this behavior in an EC host with docker and engine...

[quroom]

You saved my time!

[wsw70]

In my case (beside restarting the docker service), it helped removing the dns settings from daemon.json ..

Thank you for that - this led me to have a look at my daemon.json and realize that I changed it some time ago to point to a grafana endpoint. I reverted back to journald and everything seems to be fixed.

I do not know why this would have an impact and if it will be long term though.

[wallehazz]

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

[Git-66]

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.

[WernerRaath]

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 ^^

I'm not sure of the specifics, but my guess would be that something unexpected happened at System.d startup, probably some race condition when the config needs to be read from somewhere. The tty=true condition would probably come from a config and the fact that one has to set it manually occasionally indicates that the config was probably not read

[fuji246]

Thanks, I restart everything, the previous error is gone, now another error:

rver_1  | [Nest] 52  - 03/30/2022, 10:21:32 PM     LOG [InstanceLoader] ServerInfoModule dependencies initialized +1ms
immich_postgres  | 2022-03-30 22:21:32.225 UTC [32] FATAL:  database "immich" does not exist
immich_server_1  | [Nest] 52  - 03/30/2022, 10:21:32 PM   ERROR [TypeOrmModule] Unable to connect to the database. Retrying (1)...
immich_server_1  | error: database "immich" does not exist
immich_server_1  |     at Parser.parseErrorMessage (/usr/src/app/node_modules/pg-protocol/dist/parser.js:287:98)
immich_server_1  |     at Parser.handlePacket (/usr/src/app/node_modules/pg-protocol/dist/parser.js:126:29)
immich_server_1  |     at Parser.parse (/usr/src/app/node_modules/pg-protocol/dist/parser.js:39:38)
immich_server_1  |     at Socket.<anonymous> (/usr/src/app/node_modules/pg-protocol/dist/index.js:11:42)
immich_server_1  |     at Socket.emit (node:events:526:28)
immich_server_1  |     at addChunk (node:internal/streams/readable:315:12)
immich_server_1  |     at readableAddChunk (node:internal/streams/readable:289:9)
immich_server_1  |     at Socket.Readable.push (node:internal/streams/readable:228:10)
immich_server_1  |     at TCP.onStreamRead (node:internal/stream_base_commons:190:23)
immich_postgres  | 2022-03-30 22:21:35.348 UTC [33] FATAL:  database "immich" does not exist

[tiwariayush700]

Restarting docker solves it everytime too

[zhongpengqun]

For me, it works after executed docker system prune -a & systemctl restart docker

[jeffryjdelarosa]

COMPOSE_HTTP_TIMEOUT=200 docker-compose up