"failed to get console mode for stdout: The handle is invalid." from various commands after update to 4.27.0 #13891
Assignees
Comments
|
I had some more time to test this, and the issue seems to be a bit more severe. One of tries (run under Definitely not all commands suffer from this. I have not experienced it for |
|
Can confirm this just broke us after updating to 4.27.0. Earlier this Powershell script worked fine: Now it returns
|
|
I can also confirm this. Example 1: Example 2: Example 3: Note: If you run the same command without redirection, it works fine Example 2: Example 3: This unfortunately breaks all our PowerShell automation for our local devenvironments with Docker Desktop. We have reverted to 4.26.1 for now |
|
|
|
having the same issue with the docker import command |
hilari0n
changed the title
|
FYI. Issue still persists in version 4.27.1 |
|
After updating to 4.27.1 this problem came up. As it's critical, what is the ETA on this? |
|
Same here, v4.27.1 doesnt fix it
|
|
Hiya! Sorry for the delay in replying, we're aware and will fix a ship for this soon. In the meantime, we've pinpointed the issue, so if you need a workaround right now, you can downgrade the Another option is to invoke the |
|
Thank you for replying! Replacing it with the one you provided in the zip file worked for me while waiting on the fix... |
|
The previous version works, can this be installed safely? |
|
Downgrading Docker Desktop as a whole isn't advisable due to the recently disclosed CVEs that we patched in the last version — https://www.docker.com/blog/docker-security-advisory-multiple-vulnerabilities-in-runc-buildkit-and-moby/. |
|
... docker-windows-amd64.exe.zip – and replacing the Ty for the quick fix, it's working. |
|
idk if this is related but
Can confirm this happens after updating to 4.27.1 after updating two of my devices |
I can confirm that this hotfix works |
|
Is it fixed in 4.27.2 ? |
No, it isn't fixed. |
Can confirm this hotfix still works with v4.27.2. Thanks! 👍 |
|
Is there any update on how long until this is fixed? Currently I have to decide between
|
|
@ckuetbach If you are using git bash, you can use some workaround like this if uname | grep -i mingw &> /dev/null && docker --version | grep 'failed to get console mode for stdout' &> /dev/null ; then
log warning "applying hotfix for known docker bug docker/for-win#13891" # if you don't have log, use regular echo
function docker () { # you can use alias instead if you are going to place this in .bashrc
com.docker.cli $@;
}
fi |
|
Same problem here, I have to get rid of this annoying problem since it makes false failures in my system... If you run docker completion powershell How did this bug even get in the system? |
|
Small update: we've merged a fix for this which we'll include in the next version of Docker Desktop (4.28), soon. Sorry for the inconvenience in the meantime! |
60 tasks
|
I updated to v4.27.2 after using 4.26 while 4.27.x was being fixed Yet still I get the same error as when I reported 4.27.x so is there a way to push a new version only once this is actually fixed for windows users? PS> docker --help | more |
|
Thanks for the update! Currently my service is broken because my code expects the output of Docker commands to adhere to the "{{.json}}" format specifier rules. Is there an estimate on when 4.28 will be available? |
|
I'm mentioning an workaround that relies on modifying the PowerShell scripts. When a single string is expected, as in: we can replace When an array is expected, as in: we can add a |
|
Potential workaround We observe this issue as well, Docker v4.27.2 , from powershell. Part of failing.ps1 script: ` Invoke-Expression -Command $command | Out-String -OutVariable userid ` Error: Our workaround: Launch Windows PowerShell ISE and run script failing.ps1 from there. Greetings from SwissLife in Zurich .... Frank Potthast Rutz Update: Minimal script for testing. Fails in PowerShell, OK from within PowerShell ISE. Invoke-Expression -Command 'docker run busybox date' Invoke-Expression -Command 'docker run busybox date' | Out-String -OutVariable userid |
|
Hi Frank, won’t that workaround throw away the first line of valid output on every version besides v27? If the output format is supposed to be JSON, that would result in a completely invalid JSON object. I do not agree that this issue should be downgraded to low severity. Please consider that this output is relied upon ubiquitously, sometimes in production programs that may be hard if not impossible to patch quickly. It’s pretty unacceptable that the output format can be specified explicitly and then not adhered to. Thank you for your hard work, |
Hi Julio, sorry, my comment above was unclear. That we downgraded this issue from critical to low was intended to describe how we, a docker-enduser-company, handle this bug. From a Docker Desktop perspective, this is a rather critical issue, I agree with you. I removed the line from my comment above to avoid further misunderstandings. Sorry for being unclear, kind regards ... Frank |
Apologies for the confusion on my end! Glad we’re on the same page. Best, |
|
Any estimate on when 4.28 will be released? Thanks |
Thanks for sharing. I was not aware that there are cases, where this works. |
There's a more general/generic approach we've implemented in our script, which is also elastic, so you don't need to understand which commands are and which are not affected and will also work with unaffected versions of Docker Desktop, so will also work correctly after a fix is released. It works with Windows PowerShell and PowerShell (Core). [string] $dockerCommandParameters = @(,'--help'); # This is just an example, you can use any command, e.g.: @(,'version', '--format', '{{.Client.Version}}')
[string[]] $commandOutput = & docker $dockerCommandParameters `
| % { [bool] $firstline = $true; } { if (!$firstline -Or ($_ -INotLike '*failed to get console*')) { $_ }; $firstline = $false; };
# Do the command output processing here, e.g.:
$commandOutput | more;You can also use it with pipeline processing (i.e., when you don't want to store the whole output in a variable, but process it as it's being returned) and without the use of array for command parameters. Something like this: & docker --help `
| % { [bool] $firstline = $true; } { if (!$firstline -Or ($_ -INotLike '*failed to get console*')) { $_ }; $firstline = $false; } `
| more;There are drawbacks however:
|
|
|
I hope you added a new unit test to prevent regression. Easy steps to reproduceversion.txt: Possible workaround for someUse version2.txt: |
|
Release notes for 4.28.0 list:
So this issue is fixed, correct? Would love to update to a stable version, thanks! 😊 |
|
Docker Desktop 4.27.2 had this error. Docker Desktop 4.28.0 fixed this for me. |
|
Experiencing this same issue with: 4.27.2 (137060) It screws up all scripts relating to business central containers (bccontainerhelper) because it breaks json-handling all over the place. The json data begins with "failed to get console mode for stdout: The handle is invalid." Issue with vs code test runner |
|
Funny/interesting note: |
I don't think they will be releasing a patch addressing it for 4.27, so your only solution seems to be to upgrade to 4.28, 4.29 or 4.30, or "frankenstein" yourself a something from different versions. (As the issue is solely in Docker CLI, you could try to keep the rest as-is and only take the CLI from a newer version.) |
|
I just tested with version: And I can confirm the error no longer appears in the file when I run a docker build command from console and redirect the output to a file but what happen is still not the intended behavior: The output from docker is still not logged into the output file and is logged into the caller console instead, which defeats the purpose of redirecting the output to a file in the first place. It appears that the whole docker build log is logged into stderr instead of stdout, meaning that you can catch it into the file only by redirecting both of those into it. Is there any valid reason for docker build to behave like that? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
and others
Description
After updating my Docker Desktop to 4.27.0, if I run "docker images" and redirect the output (e.g. to a file or to a different process), then the command prints
failed to get console mode for stdout: The handle is invalid.first, before returning the output.This complicates the output processing (i.e. you have to detect and skip this information).
Reproduce
docker images docker/*-extension | moreExpected behavior
"docker images" should return valid information, without the "failed to get console mode for stdout: The handle is invalid." error. E.g.
docker images docker/*-extension | moredocker version
Client: Cloud integration: v1.0.35+desktop.10 Version: 25.0.1 API version: 1.44 Go version: go1.21.6 Git commit: 29cf629 Built: Tue Jan 23 23:10:35 2024 OS/Arch: windows/amd64 Context: default Server: Docker Desktop 4.27.0 (135262) Engine: Version: 25.0.1 API version: 1.44 (minimum version 1.24) Go version: go1.21.6 Git commit: 71fa3ab Built: Tue Jan 23 23:09:46 2024 OS/Arch: linux/amd64 Experimental: false containerd: Version: 1.6.27 GitCommit: a1496014c916f9e62104b33d1bb5bd03b0858e59 runc: Version: 1.1.11 GitCommit: v1.1.11-0-g4bccb38 docker-init: Version: 0.19.0 GitCommit: de40ad0docker info
Diagnostics ID
AEECB6F4-4558-4399-9A63-E38CE48B4BCE/20240129142522
Additional Info
This happens under
cmd.exe,pwsh.exeorpowershell.exe. It happens regardless if the console runs with standard or elevated ("as Administrator") privileges.It's not caused by a custom setting of
imagesFormat, as I have not customized it, and also the issue occurs the same, if the format is indicated in the command (e.g.docker images --format "{{json .}}" docker/*-extension | more).The issue does not occur if the output is not redirected or if I use it on my WSL2 Ubuntu.
It should probably also be considered, if such error messages should be ever returned to the standard output stream or rather (my preference) to the standard error stream.
The text was updated successfully, but these errors were encountered: