compose: All docker-compose (but not docker) commands time out: "An http request took too long to complete."
I’m getting the following error when running docker-compose
commands:
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).
Once I start getting the errors, I consistently get the errors for docker-compose commands until I restart Docker via the toolbar menu.
- Turning off wifi doesn’t help
- Adding these entries to /etc/hosts doesn’t help:
127.0.0.1 localunixsocket.local
127.0.0.1 localunixsocket
127.0.0.1 localunixsocket.lan
- Docker diagnose comes up clean
- Stopping all other containers than the 3 needed for this app doesn’t help. All remaining containers are healthy.
ping localhost
worksdocker container ls
(and other docker commands) works instantly- I can successfully telnet into all my running containers’ published ports
- I can use my app via the browser without any problems
- No docker updates available (“Docker 17.12.0-ce-mac49 is currently the newest version available.”)
- I have no reference to
tty
in my docker-compose.yml or Dockerfile files
OS: macOS High Sierra version 10.13.2 (17C205) Processor: 3.4 GHz Intel Core i5 Memory: 40 GB 2400 MHz DDR4 (I’m not using anywhere near that much)
My docker diagnostics ID is 0F286399-29FA-49AB-A3E7-669DB39AD08B
Docker for Mac: version: 17.12.0-ce-mac49 (d1778b704353fa5b79142a2055a2c11c8b48a653) macOS: version 10.13.2 (build: 17C205) logs: /tmp/0F286399-29FA-49AB-A3E7-669DB39AD08B/20180128-105656.tar.gz [OK] db.git [OK] vmnetd [OK] dns [OK] driver.amd64-linux [OK] virtualization VT-X [OK] app [OK] moby [OK] system [OK] moby-syslog [OK] kubernetes [OK] env [OK] virtualization kern.hv_support [OK] slirp [OK] osxfs [OK] moby-console [OK] logs [OK] docker-cli [OK] menubar [OK] disk
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 2
- Comments: 27
It needs to be before the subcommand (ie
docker-compose --verbose up
instead ofdocker-compose up --verbose
)@su-narthur @shin- I think this was closed too hastily. I’ve been getting this off and on since January of this year. But not on Mac, on Ubuntu. First on 16.04, then on 17.04, 17.10 and now on 18.04 - and my verbose output hangs at the exact same spot as @su-narthur 's, during container inspection.
In case anyone else faces this : restarting docker for mac resolved this for me.
@Anushkasharma Yes, restarting Docker for Mac does resolve it temporarily, but that can really slow you down if you have containers that take a while to start up.
@shin- Same as when there isn’t an issue and you add the
--verbose
argument–it gives you the command’s usage sincedocker-compose
commands don’t seem to support that argument.Hey folks, sorry for the late follow-up. Given that the
docker container inspect
command hangs identically, all signs point to this being an engine issue. I see that a report has been made here https://github.com/docker/for-linux/issues/397 (thanks @Routhinator ), which people should follow and contribute to in order to see it resolved.I’m going to close this again as this is not a Compose 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.
@su-narthur Sounds like this is an issue with Docker For Mac in this case. Do you mind creating an issue on the docker/for-mac repo with the information you provided here? It might be worth running another diagnostic with the latest info as well.
@su-narthur Thanks! If you run
docker container inspect 6c927f8d3ce359352f193a0d85b7bafc8d9a2ab3f83fd590e2617c6c010a65bd
, do you see any lag / slowdown or error show up?@shin- Ok, it happened again, and here is the verbose version:
Did you do this? If so, can you share the output?