compose: failed to get console mode for stdout: The handle is invalid.
Description of the issue
The docker-compose build command prints this failed error every time.
Context information (for bug reports)
Output of docker-compose version
docker-compose version 1.27.4, build 40524192
docker-py version: 4.3.1
CPython version: 3.7.4
OpenSSL version: OpenSSL 1.1.1c 28 May 2019
Output of docker version
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:14:16 2020
OS/Arch: windows/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:28 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-compose config
(Make sure to add the relevant -f and other flags)
services:
web:
build:
context: C:\Users\anthony\example
dockerfile: Dockerfile
version: '2.4'
and the Dockerfile can be anything, this works
FROM nginx:stable
Steps to reproduce the issue
- Create any Dockerfile on Windows
- Create any Docker Compose manifest with a build section pointing to the same Dockerfile
- Run
docker-compose build
Observed result
The Docker Compose build command always prints the failed line. Nothing else seems to be wrong, but I’m not sure.
WARNING: Native build is an experimental feature and could change at any time
Building web
failed to get console mode for stdout: The handle is invalid.
[+] Building 0.1s (5/5) FINISHED
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 31B 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [internal] load metadata for docker.io/library/nginx:stable 0.0s
=> CACHED [1/1] FROM docker.io/library/nginx:stable 0.0s
=> exporting to image 0.0s
=> => exporting layers 0.0s
=> => writing image sha256:b3914da1a942520904ff755103e5eb24c87fee1a5af36 0.0s
=> => naming to docker.io/library/downloads_web 0.0s
Expected result
The plain Docker build command works as expected.
[+] Building 0.1s (5/5) FINISHED
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 31B 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [internal] load metadata for docker.io/library/nginx:stable 0.0s
=> CACHED [1/1] FROM docker.io/library/nginx:stable 0.0s
=> exporting to image 0.0s
=> => exporting layers 0.0s
=> => writing image sha256:b3914da1a942520904ff755103e5eb24c87fee1a5af365037b7fa48e38c6a16e 0.0s
=> => naming to docker.io/library/web
Stacktrace / full error message
failed to get console mode for stdout: The handle is invalid.
Additional information
OS version / distribution, docker-compose install method, etc.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 26
- Comments: 40
Any update on what’s happening with this? It’s happening to all of my developers, and it’s obscuring the logs.
Same for me. After yesterday update console output for
docker-compose buildchanged. And it throws “failed to get console mode for stdout: The handle is invalid.”Windows 10 Docker Desktop 3.2.1
Fallback to Docker Desktop 3.1.0 helped
Same fore me. In normal command window this works:
If I put the variable on 1 it gives the handle error.
I updated today, March 15th
Same issue on windows docker desktop 3.2.2.
The most upsetting part of this all is how docker just auto updated. Previously I would wait numerous months after a update, to actually update my docker, to avoid these kind of small bugs. I would typically update on another test development machine, prior to updating my actual development machine to ensure there are no bugs on the latest version. We really need a way to opt out of updates, as this can really kill productivity.
What’s the solution to this? @ndeloof why did you close?
This is actually driving me crazy, I have so many developers affected because of this… Setting COMPOSE_DOCKER_CLI_BUILD to 0 actually breaks it (same error we get when docker service is not initialized).
Same problem on my side. It would be great to get an update.
I had the same issues since upgrading to 3.2.1 yesterday (on Windows 10). Aside of that failed message, my builds also seemed to hang on one specific line, so I also reverted to version 3.1.0.
Afterwards I figured that the line probably just takes a long time and it would actually have completed … but 3.1.0 shows the console output I’m used to, which gives a more comfortable feeling: it’s “clearly still doing stuff and not just hanging”. So this does indeed feel like a serious issue.
(The screenshot in the OP confuses me a bit, because it shows 3.1.0, while the issue for ternavsky and I only appeared on 3.2.1.)
I only started getting this last week with Git for Windows’ bash run through Windows Terminal.
I tee’d it to see the output (I hope):Redirect turned out to show the same thing:
Update: Happens with both HyperVisor and WSL 2.
@JeremyKennedy I can confirm that too. Only solved after manually downloading the binary (link below) and replacing it manually.
https://github.com/docker/compose/releases
I can confirm that I don’t get this error anymore. On Windows, I had to manually download the new
composebinary and replace it on my system, since Docker for Windows didn’t seem to be able to pull the most recent update.Looks like it’s been fixed. There’s a linked MR. Guess we’re waiting for a release!
I’m having the same “issue” on Windows while running a shell script containing the command:
cat context.tar.xz | docker build - --tag "something:1.0"But when I run the same script on macOS (Apple M1): I don’t get this issue at all
It seems that the Docker image builds anyway but this could be problematic as my container won’t work when run from Windows built image…
seconded - it’s back with these on Win10 Docker version 20.10.13, build a224086 Docker Compose version v2.3.3
@shakyav download the .exe from the link: https://github.com/docker/compose/releases
Replace the
docker-compose.exein your machine with the one you downloaded.If you don’t know where
docker-compose.exeis located in your machine, open Git Bash, typewhich docker-compose, this command will reveal the folder where docker-compose is installed in your machine.Fixed in docker-compose version 1.29.1, for those that want to cross-reference with
docker-compose version.Same issue, docker-compose build stuck at
after updating docker, and
warning appears. COMPOSE_DOCKER_CLI_BUILD=0 doesn’t solve the problem.
It would be great if auto-update is an option.
@CollinAlpert try running
com.docker.cli build | tee ... I wonder this is a side effect for legacy telemetry mechanism in Docker DesktopThis seems to be tangentially relayed to the docker-compose command being merged into the “docker” command, i.e. “docker compose up -d” vs “docker-compose up -d”. Using the latter I was getting this error, but the former works.
How to replace docker-compose manually on windows ?
Great suggestion above.
In VS Code, I’m adding to the workspace settings:
The first time, VS Code will ask if you allow setting this variable, when you open the terminal. Press “Allow”, kill the terminal and restart the terminal.
“docker-compose build” will now work properly.
I just deny Docker desktop to make changes in the system on startup. After that you should run Docker by yourself, cause autostart won’t work. After a minute it continues to threat me that it will be updated on the next reboot)
Same issue. Is there a way to prevent auto update?
I noticed this warning message only appears when running Docker Compose commands. It looks like both Docker and Docker Compose merged changes to use native build / buildx by default now. Why is this warning still here?
And why does the handle error disappear when I turn off native build?