Repository navigation
Open
Description
Description
Build fails with error:
cannot write /tmp/tmp4phcyxn2 because server did not provide an image ID
$ CACHE_FROM=27d861591f4da977a04e94431f1fce214485f293 COMPOSE_DOCKER_CLI_BUILD=1 DOCKER_BUILDKIT=1 docker-compose build --progress=plain --build-arg BUILDKIT_INLINE_CACHE=1
Native build is an experimental feature and could change at any time
Building app-frontend
WARNING: Error loading config file: .dockercfg: $HOME is not defined
WARNING: Error loading config file: .dockercfg: $HOME is not defined
#1 [internal] load build definition from Dockerfile
#1 sha256:bfa4b15feec4aff66a56da2fffc697555bf3abd42288cdb47fe7d6e146e43d25
#1 transferring dockerfile: 1.98kB done
#1 DONE 0.5s
#2 [internal] load .dockerignore
#2 sha256:c8a814244b123e69ef5bdbc269631c12cdf20bed9340d85934d92a5b7b8c249f
#2 transferring context: 114B done
#2 DONE 0.4s
....
....
...
#33 158.8 webpack 5.9.0 compiled with 17 warnings in 153155 ms
#33 159.2 Done in 158.35s.
#33 DONE 159.4s
cannot write /tmp/tmp4phcyxn2 because server did not provide an image ID
Steps to reproduce the issue:
- building images parallel with docker compose
Describe the results you received:
Docker compose fail to build
Describe the results you expected:
either success or provide a meaningful error message
Additional information you deem important (e.g. issue happens only occasionally):
the issue doesn't occur on every build
we use jenkins as our ci
and some of the build are failing. not all, not even most. but we have 10s of failures per day (out of hundreds)
Output of docker version:
WARNING: Error loading config file: .dockercfg: $HOME is not defined
Client: Docker Engine - Community
Version: 20.10.2
API version: 1.41
Go version: go1.13.15
Git commit: 2291f61
Built: Mon Dec 28 16:17:29 2020
OS/Arch: linux/amd64
Context: default
Experimental: true
Server: Docker Engine - Community
Engine:
Version: 20.10.2
API version: 1.41 (minimum version 1.12)
Go version: go1.13.15
Git commit: 8891c58
Built: Mon Dec 28 16:15:23 2020
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.4.3
GitCommit: 269548fa27e0089a8b8278fc4fc781d7f65a939b
runc:
Version: 1.0.0-rc92
GitCommit: ff819c7e9184c13b7c2607fe6c30ae19403a7aff
docker-init:
Version: 0.19.0
GitCommit: de40ad0
Output of docker info:
Client:
Context: default
Debug Mode: false
Plugins:
app: Docker App (Docker Inc., v0.9.1-beta3)
buildx: Build with BuildKit (Docker Inc., v0.5.1-docker)
Server:
Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 17
Server Version: 20.10.2
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 1
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 269548fa27e0089a8b8278fc4fc781d7f65a939b
runc version: ff819c7e9184c13b7c2607fe6c30ae19403a7aff
init version: de40ad0
Security Options:
apparmor
seccomp
Profile: default
Kernel Version: 4.4.0-1121-aws
Operating System: Ubuntu 16.04.7 LTS
OSType: linux
Architecture: x86_64
CPUs: 32
Total Memory: 58.97GiB
Name: ip-172-29-38-181
ID: 52OS:AMCC:AUGD:EYU4:SQAP:3FUE:2OF7:LJMH:IWMF:VAAB:K7TG:XR3S
Docker Root Dir: /mnt/docker
Debug Mode: false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
registry.internal.****.io:5000
127.0.0.0/8
Live Restore Enabled: false
WARNING: No swap limit support
Additional environment details (AWS, VirtualBox, physical, etc.):
AWS, ubuntu, running jenkins
Reacted by nir winkler, Mykhailo Semenchenko, Alon Mizrahi, Barak Kakoun, Gal Angel, nofar9792, Yoni Naim, OrCohen, David Gehtman, Mykhailo Kachanovskyi and 22 more
Reacted by Eden Turgeman, Ilya Isakov, Michael Blitshtein, LIN JHIH-LEI and Ali Abbas Jaffri
Reacted by Yoni Naim, ojamui, Eden Turgeman, Kfir Shainholtz, Tzur Ziv, Alon Mizrahi, Ilya Isakov, Michael Blitshtein, Michael S and LIN JHIH-LEI
Activity
thaJeztah commentedon Feb 15, 2021
error is produced in this part;
cli/cli/command/image/build_buildkit.go
Lines 358 to 366 in 2f20bf4
Curious; could it be that it's happening in situations where the cache was fully used, and no new image was built?
thaJeztah commentedon Feb 15, 2021
Hmm... output of your example shows that at least some part of the build did not use cache;
So probably that's not it (unless it still produced the same artefact in the end 🤔)
AlonMiz commentedon Feb 15, 2021
thanks! yea it does some of the build not from the cache (either local or remote)
thaJeztah commentedon Feb 15, 2021
I asked @tonistiigi to have a look as well (as he may have a better clue what could cause this); it's a USA Holiday today, so I don't expect him to have a look Today at least.
If you have more information that could help debugging (if the failing builds are on a public repo and logs are still available; feel free to post a link)
tonistiigi commentedon Feb 16, 2021
Please post a reproducer. If you can reproduce without compose then that would be preferable.
AlonMiz commentedon Feb 16, 2021
it's not reproducible at all. it happens occasionally. and not in our local env. only in our CI
and it's a private repo as well but i can share more logs from the build. (not that they are so meaningful as i shared the important parts)
tonistiigi commentedon Feb 17, 2021
@AlonMiz You don't happen to be using
docker buildx install?@ulyssessouza FYI if you've seen this in compose or have ideas. Does compose set
--loadalways when invoking builds? Looks like image was never created. This happens on if you don't specify an output on buildx container driver (but there should be a warning then). Or if you specify output other than image.ulyssessouza commentedon Feb 17, 2021
@tonistiigi No. I've never seen that.
And
docker-composedoes not set--loadnor usebuildxonlybuildkit.tonistiigi commentedon Feb 17, 2021
@ulyssessouza buildx can replace
docker buildcommand if it is configured to do so. If compose requires image ID to be returned it should set--output=image. Not sure if it is actually related to this issue though.ulyssessouza commentedon Feb 17, 2021
@tonistiigi For the image ID
docker-composepasses--iidfiledo read it after the build and retrieve the image IDhttps://github.com/docker/compose/blob/master/compose/service.py#L1875
AlonMiz commentedon Feb 22, 2021
we have another insight, worth mentioning
in some cases when this error occurs, it throws the same error in multiple images builds at once, at the end of each build.
so in the same pipeline run, we have several successful builds and some failed builds of different images.
here's an example for such case
build1:
another image build failure at the same run:
Madvinking commentedon Mar 5, 2021
any update on this?
21 remaining items
elgambet commentedon Sep 27, 2021
in my case, this was the solution!
Thank you @SatoshiDark
HMS24 commentedon Jan 24, 2022
Got the same issue
this solve my problem! thx
ofiry-tm commentedon Mar 7, 2022
I have the same issue.
I run a jenkins job that run a docker-compose build on an ec2 with 16 GB memory, ( I use jenkins ec2 plugin, only one executer per ec2 instance)
its hard to believe that its a memory issue.
ofiry-tm commentedon May 3, 2022
this indeed helped us, but only for about 2 months.
now we have the same issue with
1.27.4of docker-composeUPDATE: looks like updating the docker-compose to version
2.5.0solved the issue for nowJHIH-LEI commentedon May 11, 2022
@ofiry-tm
1.27.4 is not valid version.
2.5.0 can not help this issue for me.
Add more memory also not help.
JHIH-LEI commentedon May 11, 2022
I solve my problem after I clean up my memory.

As you can see I am out of memory.
aliabbasjaffri commentedon Oct 7, 2022
I'm running into the same problem. There is sufficient space and resources allocated to docker but
docker-compose buildstill fails; and spits out a nasty error when i try toforce-recreatewithdocker-compose upIf i build the same image with
docker, it builds and runs perfectly fine, but not withdocker-compose. However, because i have previously build the container with docker, with the sametagas thecontainer_nameindocker-compose,docker-compose upruns just fine. I hence need to builddockercontainer individually and then rundocker-composeto reflect the updated changes.dockerversiondocker-composeversiondocker-composecontentsxinzweb commentedon Nov 9, 2022
@aliabbasjaffri I hit the similar issue after I enabled the
docker desktopbeta features,Use containrd for pulling and storing images. After I disable it, then I don't have this problem anymore.This is my
docker versionWillBeebe commentedon Dec 21, 2022
Worked for me, thank you!
thaJeztah commentedon Dec 21, 2022
The issue with containerd integration enabled is likely related to rumpl/moby#125, which will be included in an upcoming release of Docker Desktop (I think the next release will be after the Holidays, so early next Year)
sankarraj-ps commentedon Jan 13, 2023
disabling parallel worked for me, could anyone please explain how?
thaJeztah commentedon Jan 13, 2023
@sankarraj-ps is this with "classic" compose (v1) or compose v2?
Some possible reasons (would have to check the exact implementation in compose, and this depends on what version (v1/v2) of compose);
--iidfileoption behind the scenes to store the image-id, and for some reason uses the same file for multiple builds, there could be a race condition (multiple builds attempting to write the ID to the same file)sankarraj-ps commentedon Jan 16, 2023
This is actually classic compose(v1) with parallel builds
lisaschumann commentedon May 26, 2023
For me it also worked again after clearing out memory and restarting/pruning with
docker system prune -aattempting to fix codespaces prebuild issues