Interactivity to container doesn't work for named pipe connections

[swernli]

When using any of the cmdlets that provide an interactive session with the container (Enter-ContainerSession, Run-ContainerImage, Exec-Container), the resulting session will work fine when connected to the daemon by tcp or unix socket, but fails to accept input and hangs when connected via named pipe. Still not sure why, investigation ongoing...

[bgelens]

I experience this as well. Currently the easiest way (IMO) to interact with the container is to create a PowerShell direct session after the container is started.

$container = Invoke-ContainerImage -Detach -Isolation HyperV -Image $image -PassThru
Enter-PSSession -ContainerId $container.ID -RunAsAdministrator

[Jaykul]

@bgelens What if the host is Windows, and the container is Linux?

[bgelens]

@Jaykul in that case I would fall back to docker cli for the moment. Although the new LIS version has added Hyper-V socket support (theoretically, we could attach over VM Bus as well)

[swernli]

@Jaykul I realize now the issue is ambiguously phrased... At the moment these cmdlets run on Windows host only, so the scenario I'm referring to is exactly that: when pointed at a Linux daemon, interactivity works fine, but when pointed at a Windows docker daemon output is displayed but input hangs. I'll update the title to clarify.

If you use the cmdlets to manage a Linux daemon things should work fine.

[friism]

@swernli hm, interactivity doesn't work me. Eg.:

Invoke-ContainerImage debian -Input -Terminal -Command bash

...starts the container and presents Debian/bash prompt, but just hangs and doesn't accept input. Am I doing it wrong?

[swernli]

That's very strange... it works for me:
PS S:\> Run-ContainerImage debian -Input -Terminal bash
root@de11d73b09ee:/# ls
bin dev home lib64 mnt proc run srv tmp var
boot etc lib media opt root sbin sys usr
root@de11d73b09ee:/# echo works!
works!
root@de11d73b09ee:/# exit
exit
PS S:\>

But the hanging at input is exactly what I see when using a Windows container. Where is your daemon running? Perhaps there is something different about the connections we are using...

[friism]

@swernli it's running in Docker for Windows. Tested from powershell

[swernli]

Ah, that could be the difference... I'm not sure what transport Docker for Windows uses. I've actually never used Docker for Windows myself; I'm testing this by connecting to an Ubuntu VM that I've set up manually as a docker host. Do you know what communication mechanism is used by the VM that Docker for Windows creates?

[friism]

@swernli named pipe over Hyper-V socket

[swernli]

Yeah, then this is likely the same issue that's affecting Windows containers, as those use named pipe as well. This is sounding like a generic named pipe issue, so I'll update the title and description to make clear that it tracks both problems. Hopefully I can find a solution soon...