containers/<id>/attach/ws API not returning logs

[achimnol]

Expected behavior

With stream=1&stdout=1&logs=1 query parameters, it should return the stdout of the container as websocket messages.
In the Linux version (17.05.0-ce), it works as expected.

Actual behavior

But in the macOS version (Docker for Mac, 17.05.0-ce), it does not return anything. Reading the websocket connection indefinitely hangs up.

Information

Used alpine:latest container with the command /bin/ash, created with the following API parameters:

{
    "Cmd": ["/bin/ash"],
    "Image": "alpine:latest",
    "AttachStdin": false,
    "AttachStdout": false,
    "AttachStderr": false,
    "Tty": true,
    "OpenStdin": true
}

My macOS version is Sierra 10.12.5.
Not sure, but I remember that I've experienced this hang-up problem since 10.12.4 and prior Docker versions (may be around API v1.24).

Steps to reproduce the behavior

1. docker run -d -i -t alpine:latest /bin/ash
2. socat TCP-LISTEN:5020,reuseaddr,fork UNIX-CLIENT:/var/run/docker.sock
3. Launch a websocket client. (e.g., http://www.websocket.org/echo.html opened in Chrome or Firefox)
4. Connect to ws://localhost:5020/containers/<id>/attach/ws?stream=1&stdout=1&stdin=1&logs=1 and send some shell commands.

If it works, the result should be something similar to:

NOTE: In websocket.org echo page, you can append the newline character (so that the container's shell actually execute the command) via developer console: websocket.send('some command\n'); because the connection is exposed as a global websocket javascript variable.
If I capture the output using Python, the content is the echo-ed shell command, the output of the command, and the shell prompt. (multiple calls to read() on websocket may be required)

FYI: I took the above screenshot using ssh-ing to a remote Linux server with the SOCKS proxy.

If the right-side logs do not have any "blob"s, it is not working as reported above.

[achimnol]

I confirm this is still happening with Docker 17.06.0-ce-rc1.

[tht13]

I am having this issue now on ubuntu with versions 17.04 through to 17.06

[AlexVanderbist]

Still having the same issue on 17.09.0-ce...

[haches]

Still having the same issue on 17.12.0-ce-mac49 (21995).
Has anyone a workaround for this?

[sky-code]

Works on Version 18.03.0-ce-mac60 (23751), seems to be fixed

[AlexVanderbist]

I'm still running into issues on Version 18.03.0-ce-mac60 (23751) whilst the same setup works perfectly on Docker for Ubuntu. Same issue still as OP

[haches]

I can confirm that this is still not working with

Docker for Mac: 18.03.1-ce-mac65 (24312)
Mac OS: 10.13.4

Would really like to know if this could have something to do with using socat (step 2) or if this is due to Docker for Mac.

@sky-code Could you elaborate how you tested / made it work for you?

[CGJzzz]

the same as you guys describe.
I can confirm that this is still not working with Ubuntu.
several months ago, I can perfectly use websocket, but after I update docker version (from 1.18 to latest version), now the stdout is not working

[myers]

I can confirm this is still happening.

Version 18.06.1-ce-mac73 (26764)

To reproduce, try this python script: https://github.com/aio-libs/aiodocker/blob/master/examples/stdio_stdout.py

If I run this on a linux host it works, on mac it does not.

[dipaktelangre]

Having same issue on Windows 10 Enterprise
Docker version 18.06.1-ce, build e68fc7a

[vishaltelangre]

I am facing the same issue. The Docker API server does not respond on the established WebSocket connection. Screenshot as follows.

Docker version 18.06.1-ce, build e68fc7a
macOS Mojave - Version: 10.14 (18A391)

[docker-robott]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

[achimnol]

People are still experiencing this issue.
/remove-lifecycle stale

[guillaumerose]

As a temporary workaround, you can bypass the proxy by setting DOCKER_HOST variable.

export DOCKER_HOST=unix://$HOME/Library/Containers/com.docker.docker/Data/vms/0/00000003.00000948

If it works correctly, we definitely miss something in our proxy.

[guillaumerose]

/lifecycle frozen

[charleskorn]

As a temporary workaround, you can bypass the proxy by setting DOCKER_HOST variable.

export DOCKER_HOST=unix://$HOME/Library/Containers/com.docker.docker/Data/vms/0/00000003.00000948

If it works correctly, we definitely miss something in our proxy.

I've just tried this with the following script and can confirm that using $HOME/Library/Containers/com.docker.docker/Data/vms/0/00000003.00000948 works correctly:

curl --include \
     --no-buffer \
     --unix-socket "$HOME/Library/Containers/com.docker.docker/Data/vms/0/00000003.00000948" \
     --header "Connection: Upgrade" \
     --header "Upgrade: websocket" \
     --header "Sec-WebSocket-Key: SGVsbG8sIHdvcmxkIQ==" \
     --header "Sec-WebSocket-Version: 13" \
     "http://localhost/containers/my_container/attach/ws?stream=1&stdout=1&stdin=1&logs=1"

When connecting to /var/run/docker.sock, I get no output.

[abngal]

Issue still present in docker version 19.03.1, build 74b1e89 on mac (but docker 19 on ubuntu is working like expected).
( I guess running docker inside a ubuntu VM is a more reliable environment rather than dealing with quite a few docker-for-mac/win quirks )

[mehulmpt]

Issue still there as of today

[MrSerth]

As a temporary workaround, you can bypass the proxy by setting DOCKER_HOST variable.

export DOCKER_HOST=unix://$HOME/Library/Containers/com.docker.docker/Data/vms/0/00000003.00000948

If it works correctly, we definitely miss something in our proxy.

I was unable to use the socket you gave above. However, I did some further research on this. The default socket /var/run/docker.sock is a link to $HOME/Library/Containers/com.docker.docker/Data/docker.sock. Hence, using that does not make any difference. Besides the docker.sock used for the link, another socket called docker.raw.sock is available. I was successfully able to use that with Docker version 19.03.5, build 633a0ea and get web socket output:

socat TCP-LISTEN:2375,reuseaddr,fork UNIX-CLIENT:$HOME/Library/Containers/com.docker.docker/Data/docker.raw.sock

[alvarolb]

I can confirm the issue is still present on 19.03.5. Using the approach suggested by @MrSerth works.

[alexeadem]

WebSocket over Unix socket is still not working
docker desktop for mac
3.3.2 (63878)
macos big sur

Actually doing further tests the workaround was pretty simple.

sudo rm /var/run/docker.sock
sudo ln -s   $HOME/Library/Containers/com.docker.docker/Data/docker.raw.sock /var/run/docker.sock

Can we allow docker desktop to mount symbolic links other than /var/run/docker.sock or to mount paths directly?

If I add another symlink pointing to docker.raw.sock and try to mount it with -v, the mount work but I can't connect to the unix socket from inside the container.

By mounting directly with -v to $HOME/Library/Containers/com.docker.docker/Data/docker.raw.sock it doesn't work cause I get:

docker: Error response from daemon: error while creating mount source path '$HOME/Library/Containers/com.docker.docker/Data/docker.raw.sock': mkdir`

ok and maybe the easiest fix of it all is to use $HOME/Library/Containers/com.docker.docker/Data/docker.raw.sock instead, change the symlink, and make it the default

[cgerling]

I'm using macOS Monterey (12.0.1 w/ Intel) with Docker for Mac 4.2.0 (70708) and still experiencing this issue.
For now, I'm able to use the workaround of targeting docker.raw.sock, but it doesn't sound like a good idea since the "official" way is to target /var/run/docker.sock instead.
That said, is there a fix planned for this issue, or the current workaround will become the blessed way to use the Docker Engine API on macOS?