compose: docker-compose build hangs
$ docker version
Client:
Version: 1.13.0
API version: 1.24 (downgraded from 1.25)
Go version: go1.7.3
Git commit: 49bf474
Built: Wed Jan 18 16:20:26 2017
OS/Arch: darwin/amd64
Server:
Version: 1.12.6
API version: 1.24 (minimum version )
Go version: go1.6.3
Git commit: d5236f0
Built: Fri Jan 20 05:47:10 2017
OS/Arch: linux/amd64
Experimental: false
I’m trying to use docker-compose build
but the command hangs:
$ docker-compose build --force-rm
Building integration-test-go
^CERROR: Aborting.
docker-compose.yml contains
version: '2'
services:
integration-test-go:
build:
context: go
dockerfile: go/Dockerfile
and go/.dockerignore has
bin/
coverage/
The same invocation via docker build
completes in about a minute:
$ time docker build --force-rm=true go
...
Step 10 : ADD ./Makefile $GOPATH/Makefile
---> 7291ce227751
Removing intermediate container e69e54d81655
Step 11 : ADD ./src/ $GOPATH/src/
---> 690cf13fd4ae
Removing intermediate container 9649280eddff
Successfully built 690cf13fd4ae
real 1m49.268s
user 0m3.688s
sys 0m2.501s
Any idea what’s going on here?
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 20
- Comments: 79
Had the issue, and as for @dmoliveira it was because of a too heavy repo.
Adding big files to
.dockerignore
solved it!Maybe a warning message when the
loading context
step takes more than x seconds would be helpful?Cheers
I have the same on Ubuntu 16.04
In docker log only one string
DEBU[0363] Calling GET /v1.22/version
At same time,
docker build -t latest .
works fineDocker version 17.05.0-ce, build 89658be
UPD: I have added .dockerignore file with
And my build was successfull. Seem like issue in context size, or file count.
One piece of info. For me is because of heavy files inside of the building image. Even if you use
docker-compose build --no-cache
it didn’t work. The solution was to put the heavy files in the.dockerignore
only to not pass to the building at*.Dockerfile
(e.g., my Solr cores with 100GB). After that, I could build very fast the image and access the files shared at volumes section ondocker-compose.yml
. I hope that help others. 😃@dukedave wow I was suffering from the same problem. Great job working that out.
Here’s a quick command for everyone:
Mystery solved - User error
I didn’t realize that the whole directory gets sent as “context” to the docker daemon. I had very large sql export files in the path (that are not copied to the container.) Moved them out of the build dir and all is well.
=================
Having the same problem, for the last week or so. docker-compose build hangs for about 20 minutes before completing. I added a .dockerignore file with .git entry. I don’t have any fifo. I tried the “chrome issue” fix, I’ve tried clearing the docker config auth. Nothing works. Considering going to virtualbox/toolkit. What else can I do?
My info:
$ docker version Client: Version: 17.03.1-ce API version: 1.27 Go version: go1.7.5 Git commit: c6d412e Built: Tue Mar 28 00:40:02 2017 OS/Arch: darwin/amd64
Server: Version: 17.03.1-ce API version: 1.27 (minimum version 1.12) Go version: go1.7.5 Git commit: c6d412e Built: Fri Mar 24 00:00:50 2017 OS/Arch: linux/amd64 Experimental: true
$ docker-compose version docker-compose version 1.11.2, build dfed245 docker-py version: 2.1.0 CPython version: 2.7.12 OpenSSL version: OpenSSL 1.0.2j 26 Sep 2016
Sweet mother of god.
There’s a SO post which mentions
docker-compose build
hangs when chrome is open (link)My colleague was using Safari and his was working. I told him to open chrome and try again. It failed
Armed with this knowledge, I was able to fix by:
rm -rf <my repository>
docker-compose
build 👍docker-compose
build 👍What. On. Earth.
Update This did not last. When I rebooted docker, it started to hang again.
Hey 😃
Just in case, I had the same problem but very different reason. In my docker-compose folder there’s a data folder that should have been ignored and is HUGE. The hanging was because of “sending context to the docker daemon” (more than 20G of context…), and this message was not displayed by
docker-compose --verbose
.Docker Black Magic™
I just realized that my context (actual folder) was too big. So I moved my dockerfile to another folder and change my
docker-compose.yml
:Argh, after much lamenting, it seems I was suffering from #4623 all along! I deleted my fifo pipes and it works perfectly.
The rest of this comment is somewhat redundant since I found the actual cause (⬆️) But I’ll leave it here for archival purposes (and so I don’t feel bad about how much time I spent writing it up 😊 ).
I’m seeing this also.
I was able to work around it by manually building the images with
docker
and tagging them with a name which matches the onedocker-compose
generates, e.g:Then I was able to
docker-compose up web
and have it start without hanging.I re-read the comments and here’s some relevant bits from my set up:
curl
approach here.build
. I’ve left it there for several hours and nothing.journalctl
. Nothing else is written when I try thebuild
.GET
calls at the bottom, then nothing.I’ve tried:
~/.docker/config.json
.dockerignore
files.I rolled back to try compose
1.12.0
and1.11.2
(via curl)and they all have the same issue. Will try downgrading my Docker version next. FYI this issue started occurring for me after I updated both Docker and docker-compose, unfortunately I did both at the same time, and both were (IIRC) rather big jumps.I also just tried Docker engine 1.11.2 and 1.12.3 (installed via a .deb) and those seem to hang too.
In my case, docker-compose was hanging on a massive node_modules tree. Ignoring node_modules with a .dockerignore file solved the issue.
I had this problem, for me the fix was updating the version at the top of the docker-compose files to “2.1”
This just fixed my build too. It seems maybe building is searching through directories for some reason and hanging, even when told which files to read? As soon as I moved my dockerfiles into a subfolder and modified the context rather than sitting in the root, my builds stopped hanging and ran perfectly.
For me, docker hangs (actually just goes incredibly slowly) whenever I’m connected to the ‘eduroam’ WiFi (http://eduroam.org) - pointing at some weird reliance on network conditions.
I was seeing the same issue -
EOF
on step x/y while runningdocker-compose up --build
.Thanks to all you guys I looked in my repo for the largest files - found a
test.log
that was nearly 10GB… .gitignored, but not .dockerignored. Once I added it to the .dockerignore my build sped up abt 3x as fast and finished no problem.Beefing up my .dockerignore now…
In my case, it was fixed adding my fifo to
.dockerignore
, as I use vim-plumber.I’ve just checked if this has anything to do with my local login information. I logged out of all services
docker-compose build
still hangs. Then I logged in to Docker Hub (only). Still didn’t work.Having the same issue… Mac OS Sierra
UPDATE: I left docker-compose sitting there for about 10 minutes with this as the last verbose message:
After that, it also stuck here for a couple minutes:
And finally managed to proceed with the build.
The full output: https://gist.github.com/jlcd/f26c3a8283e54f2279d6844154277a8a
For anyone having the same issue with WSL, the correct Docker for Windows issue @patricknazar mentioned is the following: https://github.com/docker/for-win/issues/7808
As it seems, a recent Windows (Insider) release broke
clip.exe
, consequentially breakingdocker-credential-desktop.exe
. This bug is being discussed at https://github.com/microsoft/WSL/issues/5648Also, this note present at the Docker for Windows issue worked for me:
Adding .dockerignore works, thanks https://github.com/docker/compose/issues/4396#issuecomment-301476026
I was facing same issue, docker-compose build hang, and reason at my end was I didn’t have enough space. After creating some space its start working.
In my case,
.git
folder had an issue, when I added it to.dockerignore
, it started to workCould I ask what y’all have in your
.dockerignore
files (if anything)? We have this delightful mess at the moment, and I think this might have something to do with the hang we’re experiencing: