Standard output and Standard error are not being written unless docker is invoked with -i.

[git-rz]

Actual Behavior

In WSL only, Standard output and Standard error are not being written unless docker is invoked with -i.
I have tried from within several distros: Ubuntu 22, 20, 18, Kali.

Steps to Reproduce

Must be run in a WSL distro:

docker run -i --rm alpine  echo "why do I need to add -i to get my output? This makes rancher-desktop on WSL unusable"

docker run  --rm alpine  echo "why do I need to add -i to get my output? This makes rancher-desktop on WSL unusable"

Result

Expected Behavior

Rancher-Desktop on Mac shows the output.
Rancher-Desktop on Windows from inside a CMD prompt shows proper output
Rancher-Desktop on Windows w/ nerdctl & containerd backend shows the output
Docker-Desktop on Windows shows the output.
Docker on Linux shows the output.

mac

git bash(zsh)

cmd

Additional Information

Ubuntu 22 in WSL

Rancher Desktop Version

1.6.0

Rancher Desktop K8s Version

1.24.6

Which container engine are you using?

moby (docker cli)

What operating system are you using?

Windows

Operating System / Build Version

Windows 10 Enterprise 21H2

What CPU architecture are you using?

x64

Linux only: what package format did you use to install Rancher Desktop?

No response

Windows User Only

No response

[jandubois]

See also kubernetes-sigs/kind#3065

[sergioprates]

Any update?

[ivanmaia]

Any update?

[jandubois]

I'm sorry, this issue somehow got lost in the migration to the non-legacy Github projects. 😞 I thought we were tracking it on the new board already, but it seems like I mixed it up with the (related) #2094 issue.

Unfortunately, with summer vacations and other unexpected absences there is no way to get this dealt with in time for the 1.10 release, but I've added it to the 1.11 milestone now.

[ivanmaia]

Thank you!

[jandubois]

This looks like a duplicate of #1558.

[CalaxDev]

@jandubois I see you initially planned this for 1.11 but now removed it from the 1.13 milestone - What is the plan here? Adding args via docker run might work in a normal setting but not with predefined docker-compose files and this makes working with the WSL integration pretty annoying

[jandubois]

I see you initially planned this for 1.11 but now removed it from the 1.13 milestone

That's because there is nobody available to work on it in the 1.13 timeframe. We seem to always get a bit overambitious with our milestones and end up removing issues again as time goes on.

The big issue though is that 2 people already tried to fix it, but could not get it to work. 😞
So it's not something you can plan to do in a day or so.

I definitely want this fixed, but I can't make any promises on when that will happen.

[igieon]

I hope this will be soon solved. I get bitten it in perl plugin for idea. I try to solve it with fixing there but that seems wrong ...
Camelcade/Perl5-IDEA#2836

[michaelschuhmsg]

Hi @jandubois, I would like to get that fixed too and I hoped that it would have been done in 1.13 already! Thank you

[jandubois]

I hoped that it would have been done in 1.13 already

Yeah, me too, but unfortunately we didn't have anybody available to work on it. It won't be fixed in 1.14 either, sorry!

[MrWako]

After being confused by the Rancher Desktop behaviour for a while finally realized I've hit this issue. Any chance it can get prioritized? Its really quite a blocker for serious usage with WSL2.

[MrWako]

Not suggesting this is a solution but in case it sheds any light, running via nerdctl on WSL2 works as expects and echoes the message.

nerdctl run --rm --address /var/run/docker/containerd/containerd.sock alpine echo "why do I need to add -i to get my output? This makes rancher-desktop on WSL unusable"

It does trip this issue though. Similarly if you run the command in the rancher-desktop WSL2 distro it echoes correctly. From the DOS cmd prompt

wsl -d rancher-desktop
docker run --rm alpine echo "why do I need to add -i to get my output? This makes rancher-desktop on WSL unusable"

[MrWako]

Nice analysis of the issue @matejkramny in your PR: #7878 and for identifying that the issue is with the Go reverse proxy: golang/go#35892. I've re-worked a previously suggested fix that hopefully we can get returned to the Go mainline and should then just require a compiler update to fix the issue.