[Remote-Container Bug] postStartCommand hangs indefinitely when the x11-unix socket is mounted as volume

[Roemer]

I have a simple dev-container which just consists of a postStartCommand and adds a volume mount to the /tmp/.X11-unix socket (the socket is needed because otherwise UI applications like Cypress are extremely slow).

In that case, the Configuring Dev Container hangs indefinitely. If I remove the x11 socket mount, the postStartCommand executes successfully and the container finishes initialization.

• VSCode Version: 1.90.2
• Local OS Version: Windows 10
• Remote OS Version: WSL2 Debian
• Remote Extension/Connection Type: Container over WSL

Steps to Reproduce:

1. Create a devcontainer.json file like:

{
  "name": "x11-socket-test",
  "build": {
    "dockerfile": "Dockerfile",
  },
  "runArgs": [
    "-e", "DISPLAY=${localEnv:DISPLAY}",
    "-v", "/tmp/.X11-unix:/tmp/.X11-unix:ro"
  ],
  "postStartCommand": "echo hello"    
}

2. Create a simple Dockerfile with just FROM debian as content
3. Start the dev-container
4. Observe that Configuring Dev Container never finishes and hello is not visible in the log output
5. Simply remove the "-v", "/tmp/.X11-unix:/tmp/.X11-unix" and rebuild the dev-container
6. Observe that hello is written in the output and the container finishes initialization

Does this issue occur when you try this locally?: Yes
Does this issue occur when you try this locally and all extensions are disabled?: Yes

[chrmarti]

Please append the Dev Containers log from when this happens. (F1 > Dev Containers: Show Container Log)

[Roemer]

I just saw the following in the log:

Container server: Error: listen EROFS: read-only file system /tmp/.X11-unix/X1
    at Server.setupListenHandle [as _listen2] (node:net:1855:21)
    at listenInCluster (node:net:1920:12)
    at Server.listen (node:net:2025:5)
    at /tmp/vscode-remote-containers-server-a07e1b7a-aa46-4bca-bb7d-5c13522497e2.js:12:10798
    at new Promise (<anonymous>)
    at /tmp/vscode-remote-containers-server-a07e1b7a-aa46-4bca-bb7d-5c13522497e2.js:12:10781
    at async Promise.all (index 1)

Might this be the issue, that it aborts after this error? I also set the volume mount to :ro, that did not change anything (I'll edit it in the initial post).

Here is the full log:
log.txt

Edit: As a side-note, the reason why I manually mount the x11 socket into the container is performance. If I do not mount it, only a wayland mount is created in the container and when I then run an UI application (eg. glxgears from the mesa-utils package), I get about 10x less performance as when I mount the x11 socket. This might be a separate issue.

[chrmarti]

Tracking the performance issue in #10016.

I will fix this issue by skipping the X11 forwarding when the container has a DISPLAY env variable set.

[Roemer]

I will fix this issue by skipping the X11 forwarding when the container has a DISPLAY env variable set.

That is great and would fix this issue. My current work-around is to use another X11 index (10 for example) from inside the container and redirect it to X0 from WSL and also create the /tmp/.X11-unix folder before mounting the socket into it and grant the folder write rights for everyone.

Concretely like that:

1. In runArgs in devcontainer.json:

"runArgs": [
  "-e", "DISPLAY=:10",
  "-v", "/tmp/.X11-unix/X0:/tmp/.X11-unix/X10"
]

2. In Dockerfile:

RUN mkdir "/tmp/.X11-unix" && chmod 777 "/tmp/.X11-unix"

[chrmarti]

This is now available with Dev Containers 0.376.0-pre-release. Please give it a try and let me know how it goes.

[eleanorjboyd]

Hi @Roemer! Just a bump to see if you re you able to verify if this fix works. You can do so by getting the latest pre-release version of the Dev Containers extension. Appreciate any help, thanks!

[Roemer]

@chrmarti @eleanorjboyd I just tried with pre-release v0.378.0 and it indeed fixed this issue, the postStartCommand does run correctly.