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

What command is timing out?

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

any ideas?

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

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

@Fortiz2305 no workaround afaik, see my above comment: https://github.com/docker/compose/issues/3633#issuecomment-229340293

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

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

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

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

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

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.

Hello everybody,

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

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.

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.

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.

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

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

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

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

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, :heart: docker & compose.

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.

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

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

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

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

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

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

@patosai agreed. We were experiencing this on a build machine which had, unbeknownst to us, accumulated a lot of old images. Cleaning them up seems to have solved this issue for us.

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.

Didn't work for me @patosai. But @shabzkhan's solution of running with -d worked.

I believe we should now approach the problem in a different way, looking for reasons for this different behavior of deamonized containers.

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

still no real solution for this issue ?

(i'm on MAc OSX too)

Seeing this on a fresh Ubuntu 16.04.3 install, installing significant micro-services environment for mender. Nothing else has been run except the Docker install, no kernel parameters updated.

Pushed the timeout as high as 1920. I see another comment for as high as 10,000, trying that next.

UPDATE: The api gateway is restarting every 60 seconds. In the forums, there is discussion saying SSE4.2 instructions are required. Trying to learn more about this:

Distributor ID: Ubuntu
Description:    Ubuntu 16.04.3 LTS
Release:    16.04
Codename:   xenial

              total        used        free      shared  buff/cache   available
Mem:          15541        1116       12637          26        1787       14080
Swap:         15871           0       15871

Filesystem                     Inodes  IUsed      IFree IUse% Mounted on
udev                          1976001    516    1975485    1% /dev
tmpfs                         1989285    943    1988342    1% /run
/dev/mapper/wotan--vg-root   29483008 177454   29305554    1% /
tmpfs                         1989285      1    1989284    1% /dev/shm
tmpfs                         1989285      3    1989282    1% /run/lock
tmpfs                         1989285     16    1989269    1% /sys/fs/cgroup
/dev/sda1                      124928    303     124625    1% /boot
working                    3770678702      6 3770678696    1% /data
tmpfs                         1989285      4    1989281    1% /run/user/1000
tmpfs                         1989285      4    1989281    1% /run/user/1001

CONTAINER ID        IMAGE                                               COMMAND                  CREATED             STATUS                           PORTS                                 NAMES
594884d85aa7        mendersoftware/api-gateway:1.3.0                    "/entrypoint.sh"         19 minutes ago      Restarting (132) 7 seconds ago                                         integration130_mender-api-gateway_1
227e35c68067        mendersoftware/conductor:1.7.7                      "/srv/start_conducto…"   19 minutes ago      Up 19 minutes                    8080/tcp                              integration130_mender-conductor_1
e1419afde26c        mendersoftware/deviceadm:1.2.0                      "/usr/bin/deviceadm …"   19 minutes ago      Up 18 minutes                    8080/tcp                              integration130_mender-device-adm_1
401790f80860        mendersoftware/openresty:1.11.2.2-alpine            "/usr/local/openrest…"   19 minutes ago      Up 19 minutes                    0.0.0.0:9000->9000/tcp                integration130_storage-proxy_1
cdfe31bc341e        mendersoftware/deviceauth:1.3.0                     "/usr/bin/deviceauth…"   19 minutes ago      Up 18 minutes                    8080/tcp                              integration130_mender-device-auth_1
5eb982811225        mendersoftware/deployments:1.3.0                    "/entrypoint.sh --co…"   19 minutes ago      Up 19 minutes                    8080/tcp                              integration130_mender-deployments_1
88efed66903c        mendersoftware/inventory:1.2.0                      "/usr/bin/inventory …"   19 minutes ago      Up 18 minutes                    8080/tcp                              integration130_mender-inventory_1
9edf4b7b699d        mendersoftware/useradm:1.3.0                        "/usr/bin/useradm --…"   19 minutes ago      Up 18 minutes                    8080/tcp                              integration130_mender-useradm_1
31fc0d4c13e3        mendersoftware/dynomite:stable                      "/dynomite/startup.sh"   19 minutes ago      Up 19 minutes                    8101-8102/tcp, 22122/tcp, 22222/tcp   integration130_mender-dynomite_1
832e8a6d869f        mongo:3.4                                           "docker-entrypoint.s…"   19 minutes ago      Up 19 minutes                    27017/tcp                             integration130_mender-mongo-device-adm_1
e2e45c244a43        mendersoftware/minio:RELEASE.2016-12-13T17-19-42Z   "minio server /export"   19 minutes ago      Up 19 minutes                    9000/tcp                              integration130_minio_1
89c75c216aed        mongo:3.4                                           "docker-entrypoint.s…"   19 minutes ago      Up 19 minutes                    27017/tcp                             integration130_mender-mongo-useradm_1
ff3cb84fbdba        mendersoftware/elasticsearch:2.4                    "/docker-entrypoint.…"   19 minutes ago      Up 19 minutes                    9200/tcp, 9300/tcp                    integration130_mender-elasticsearch_1
d6fab68df50f        mendersoftware/mender-client-qemu:1.3.0             "./entrypoint.sh"        19 minutes ago      Up 19 minutes                    8822/tcp                              integration130_mender-client_1
6be20786a1ac        mongo:3.4                                           "docker-entrypoint.s…"   19 minutes ago      Up 19 minutes                    27017/tcp                             integration130_mender-mongo-deployments_1
206e6d298b81        mendersoftware/gui:1.3.0                            "/entrypoint.sh"         19 minutes ago      Up 19 minutes                    80/tcp                                integration130_mender-gui_1
dbddc5857728        mongo:3.4                                           "docker-entrypoint.s…"   19 minutes ago      Up 19 minutes                    27017/tcp                             integration130_mender-mongo-device-auth_1
02bc3bd2ea99        mongo:3.4                                           "docker-entrypoint.s…"   19 minutes ago      Up 19 minutes                    27017/tcp                             integration130_mender-mongo-inventory_1



md5-9b5c03b9aebfbbb10bf5ed5fc418fedd



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

Docker-compose restart worked for me.it started running my app.

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.

@jorihardman Does running docker image prune help?

@shin- It looks like that hangs too until restarting docker, and then it runs quickly just fine. This does seem to indicate that it's docker itself that's going unresponsive and not actually an issue with compose. I have this exception trace that came out of my compose log this morning.

Exception in thread Thread-19:
Traceback (most recent call last):
  File "threading.py", line 801, in __bootstrap_inner
  File "threading.py", line 754, in run
  File "compose/cli/log_printer.py", line 213, in watch_events
  File "compose/project.py", line 420, in events
  File "compose/container.py", line 42, in from_id
  File "site-packages/docker/utils/decorators.py", line 19, in wrapped
  File "site-packages/docker/api/container.py", line 760, in inspect_container
  File "site-packages/docker/utils/decorators.py", line 46, in inner
  File "site-packages/docker/api/client.py", line 191, in _get
  File "site-packages/requests/sessions.py", line 521, in get
  File "site-packages/requests/sessions.py", line 508, in request
  File "site-packages/requests/sessions.py", line 618, in send
  File "site-packages/requests/adapters.py", line 521, in send
ReadTimeout: UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)

I just used the "Reset to factory defaults" button in the docker preferences to see if any experimental features I enabled are an influence. I'll report back on whether that changed the behavior.

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.

None of the solutions here worked for me. It turned out that I compiled docker with one version of kernel and tried to run it on another version. During this process some kernel features do not satisfy with requirements of dockers, therefore docker hung on almost all commands and docker-compose could not start.

@jorihardman I'm guessing your issue is the same or similar to the one in #5620
The same thing applies: the best way to report this is to do so on the https://github.com/docker/for-mac repo with as much info as possible.

I get this issue on servers after they've been running for a few weeks and not on my Mac (so it's definitely not Mac-specific).

The timeout seems to happen on the network creation step when I spin up a new set of containers. If I override the COMPOSE_HTTP_TIMEOUT variable and set it to 300, usually the command succeeds and the containers start, but not until I first remove the network that was (partially) created during the command that timed out, or I end up getting warnings about duplicate networks.

CentOS 7, 3.10.0-693.11.6.el7.x86_64

## 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:41:23 2017
 OS/Arch:      linux/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:42:49 2017
 OS/Arch:      linux/amd64
 Experimental: false

## docker-compose version
docker-compose version 1.17.1, build 6d101fb
docker-py version: 2.5.1
CPython version: 2.7.13
OpenSSL version: OpenSSL 1.0.1t  3 May 2016

24 cores, 96GB ram, around 300 containers, load usually around 2.

@cafuego The Docker CE release notes mention several networking fixes that may be linked to what you're seeing ; if upgrading doesn't help, I would go ahead and report what you're seeing on the moby/moby repo as it seems likely that the issue happens at that level.

Thanks @shin- . I'll schedule an update and see how I go on 17.12 (it's been running fine on a less critical server :-)

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

Started happening also to me a while ago, despite using docker for the same project with the same setup much longer. I guess this is some kind of a regression in latest docker releases.

Only solution is pkill -9 docker. Restarting service doesn't work, seems like the daemon is completely stuck

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.

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

@sameersbn I just got the same problem with tty: true. Thanks my friend. Good to see you around :-)

I'm having these issues with a recent version.
Running 3-4 containers on a 4 core, 32 GB RAM linux box.

What timeout value do you recommend if I suspect the network?

Client:
 Version:      18.03.1-ce
 API version:  1.37
 Go version:   go1.9.5
 Git commit:   9ee9f40
 Built:        Thu Apr 26 07:17:20 2018
 OS/Arch:      linux/amd64
 Experimental: false
 Orchestrator: swarm

Server:
 Engine:
  Version:      18.03.1-ce
  API version:  1.37 (minimum version 1.12)
  Go version:   go1.9.5
  Git commit:   9ee9f40
  Built:        Thu Apr 26 07:15:30 2018
  OS/Arch:      linux/amd64
  Experimental: false

Same issue with Docker version 18.06.1-ce with some containers with tty enabled, restarting the docker service did the trick

well this happened because of the surveillance from my company. the networking configuration gets malfunctioning outside the company office. try to work offline

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

@davidgreisler I had the same issue. Tried to forward all passive ports of ProFTPD, which are a lot. Reducing this range to 10 ports fixed the problem for me.

$ docker version
Client: Docker Engine - Community
 Version:           19.03.1
 API version:       1.40
 Go version:        go1.12.5
 Git commit:        74b1e89
 Built:             Thu Jul 25 21:18:17 2019
 OS/Arch:           darwin/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.1
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.5
  Git commit:       74b1e89
  Built:            Thu Jul 25 21:17:52 2019
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.2.6
  GitCommit:        894b81a4b802e4eb2a91d1ce216b8817763c29fb
 runc:
  Version:          1.0.0-rc8
  GitCommit:        425e105d5a03fabd737a126ad93d62a9eeede87f
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

$ docker-compose version
docker-compose version 1.24.1, build 4667896b
docker-py version: 3.7.3
CPython version: 3.6.8
OpenSSL version: OpenSSL 1.1.0j  20 Nov 2018

Same problem on docker 18.09.7 build 2d0083d linux... docker-compose version 1.17.1
Maybe it is a problem in Docker not sure, but docker ps shows the container however docker-compose ps, down, up, restart etc all fail with An HTTP request took too long to complete.

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.

I am facing same issue.

error:

ERROR: for a5c0e5db52f5_anobis-prod  UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)

ERROR: for anobis  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.

In my case its NOT happening because of tty: true. Its happening after I added logging options in compose file. If I remove logging its working fine

version: "3"
services:
  anobis:
    image: anobis:${COMPOSE_PROJECT_NAME}
    build:
      context: .
      dockerfile: ./packages/anobis/Dockerfile
    ports:
      - ${PORT}:80
    volumes:
      - anobis_node_modules:/app/node_modules
    logging:
      options:
        max-file: 5
        max-size: 5m
    container_name: ${COMPOSE_PROJECT_NAME}
    tty: true
volumes:
  anobis_node_modules:

my docker-compose version:

docker-compose version 1.25.4, build 8d51620a

my 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

@dev-drprasad can you try with the following configuration?
~
logging:
options:
max-file: "5"
max-size: "5m"
~

I had a similar situation on the latest docker for mac (2.2.0.5) when using logging. It works fine if I specify values in quotes. In docs, quotes are also used. https://docs.docker.com/compose/compose-file/#logging

@leovujanic Thanks. Using quotes solved the problem

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.

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

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.

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

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.