Unable to use docker, in addition to the 'docker version' command.

[maorui2014]

Maybe the Linux kernel version is too low (docker requires 3.10+)?

[aseering]

Thanks for reporting this! Docker is actually more than just a userspace process; a big part of its logic has been merged directly into the Linux kernel. Microsoft has indicated that they don't plan to implement the kernel portions of Docker for WSL:

https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/13250370-docker

The recommended alternative is to install the Windows version of Docker, and point the WSL Docker command-line tools at the Windows Docker daemon over TCP. (Or just use Windows Docker directly -- IMO the Windows Docker experience just got a lot cleaner as of Docker 1.12, released publicly earlier this week.)

[marfillaster]

you can add this to ~/.bashrc

export DOCKER_HOST=tcp://:2375

[sepiroth887]

I have trouble using docker (tried 1.12 1.11 and 1.10 clients so far). Regardless whether I use the Native (Hyper-V based) docker engine or a remote unix one, any docker build is stalling on sending the context (usually it shows the first few Kb or even up to 3Mb being sent)

strace doesn't show anything helpful :(

socket(PF_INET, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 4
setsockopt(4, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
connect(4, {sa_family=AF_INET, sin_port=htons(5000), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
clock_gettime(CLOCK_REALTIME, {1467341112, 873312100}) = 0
epoll_create1(EPOLL_CLOEXEC)            = 5
epoll_ctl(5, EPOLL_CTL_ADD, 4, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=3246342176, u64=140311237967904}}) = 0
getsockname(4, {sa_family=AF_INET, sin_port=htons(65284), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
getpeername(4, {sa_family=AF_INET, sin_port=htons(5000), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
setsockopt(4, SOL_TCP, TCP_NODELAY, [1], 4) = 0
futex(0xc8202cb790, FUTEX_WAKE, 1)      = 1
Sending build context to Docker daemon 3.342 MBld context to Docker daemon 557.1 kB

Occasionally the futex is released, followed by a few clock_gettime calls, but nothing else. Nework, CPU, Memory are 100% idle as well until I manually SIGTERM it.

[sepiroth887]

I should note however that build seems to be the only command I tried that doesn't work. Run/stop/ps/kill/exec seem to work fine.

[sepiroth887]

Also it seems that issue ensues from a 6mb file I have in the context. It works if my context is small enough, but with that file present I always get a failure.

[aseering]

What Windows Insider build are you running?

Build 14376, for example, fixed one issue with sending large blocks of data over TCP sockets. There are also a couple remaining/unresolved issues ( #610 and #616 ) regarding scenarios that sound kind of like this.

[sepiroth887]

I'm on 14379

It seems to still happen, and yea, they may well be related. I will try a few docker builds with various file sizes to see if there is a breaking point. What are the default TCP buffer sizes btw? sysctl isn't working yet (though could probably check /proc..)

[sepiroth887]

looks like it breaks around 1MByte+ for a single file. Docker also seems to put multiple files together since 2+ Files broke at ~700KByte each....

also noticed this:
setsockopt(4, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0

Possibly related to SO_BROADCAST not yet supported?

[sepiroth887]

Also insight into the network stack is pretty hard right now :D proc is empty, no packet analyzer seems to work... ip doesn't work either. :(

[sepiroth887]

bump. It's also not working yet on 14393.5

[aseering]

docker build uploads your entire build context as a single tarball. (It creates and streams the tarball in memory so you don't see this as an end-user, but as I understand it, the wire protocol looks like one big data stream.) So you're right that it puts multiple files together.

It could well be that you're hitting #610 or #616 . Could you post an strace of the docker build command during a failed upload? It would be helpful if you could additionally look at that strace and compare it to the examples on those two tickets; see if it looks similar to either.

For SO_BROADCAST -- I don't know whether broadcast is supported or not in the current release, but that syscall is returning success (0) and unimplemented socket features in other contexts have returned failure (-1 with errno set).

For what it's worth -- I'm not a Microsoft dev, I'm just a user who's using Docker and (unrelatedly) hitting similar network issues. You could try pinging the official folks who have responded on those tickets to see if they have thoughts on this one as well. From experience, the first thing they'll ask for is "do you have a complete strace of all threads of the failing command?"

[sepiroth887]

Thanks @aseering . You're right, it cannot be related to SO_BROADCAST. It's also next to impossible to trace properly since the upload seems to split into multiple forked processes. Tracing the forks has an interesting side effect of actually working so far 100% to get past the content upload -.-
Could be the either of the tickets, but might also be related to resumable system calls which is bugging all Go developers on WSL right now (:#349). Possible that the slowdown of strace is enough to avoid whatever is blocking it, so no way to get a trace for now. Though if thats the case I'm curious as to why there is no exception and everything just hangs indefinitely.

[Leigh-ma7]

same here. not working. i followed exactly this blog from Darth. i even installed Powershell docker server/clients. even the first docker run hello-world not running too well.
Keep getting Docker daemon error.

http://darthnunix.blogspot.com.au/2016/06/docker-cli-on-wsl-for-docker-beta-on.html

[rustyx]

Please make Docker work in WSL!

[AStupidBear]

+1

[zed76r]

+1

[tara-raj]

Please see the blog post on using Docker with WSL - https://blogs.msdn.microsoft.com/commandline/2017/12/08/cross-post-wsl-interoperability-with-docker/