Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Roemer opened this issue Jun 27, 2024 · 7 comments
Assignees
Labels
author-verification-requested Issues potentially verifiable by issue author bug Issue identified by VS Code Team member as probable bug containers Issue in vscode-remote containers verified Verification succeeded
Milestone

Comments

@Roemer
Copy link

Roemer commented Jun 27, 2024

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"    
}
  1. Create a simple Dockerfile with just FROM debian as content
  2. Start the dev-container
  3. Observe that Configuring Dev Container never finishes and hello is not visible in the log output
  4. Simply remove the "-v", "/tmp/.X11-unix:/tmp/.X11-unix" and rebuild the dev-container
  5. 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

@vscodenpa vscodenpa added the containers Issue in vscode-remote containers label Jun 27, 2024
@chrmarti
Copy link
Contributor

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

@chrmarti chrmarti added the info-needed Issue requires more information from poster label Jun 28, 2024
@Roemer
Copy link
Author

Roemer commented Jun 28, 2024

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 chrmarti added bug Issue identified by VS Code Team member as probable bug and removed info-needed Issue requires more information from poster labels Jul 1, 2024
@chrmarti chrmarti added this to the July 2024 milestone Jul 1, 2024
@chrmarti
Copy link
Contributor

chrmarti commented Jul 1, 2024

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.

@chrmarti chrmarti closed this as completed Jul 1, 2024
@Roemer
Copy link
Author

Roemer commented Jul 1, 2024

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"
]
  1. In Dockerfile:
RUN mkdir "/tmp/.X11-unix" && chmod 777 "/tmp/.X11-unix"

@chrmarti
Copy link
Contributor

chrmarti commented Jul 3, 2024

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
Copy link
Member

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!

@eleanorjboyd eleanorjboyd added the author-verification-requested Issues potentially verifiable by issue author label Jul 24, 2024
@connor4312 connor4312 added the verified Verification succeeded label Jul 24, 2024
@Roemer
Copy link
Author

Roemer commented Jul 25, 2024

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

@vs-code-engineering vs-code-engineering bot locked and limited conversation to collaborators Aug 15, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
author-verification-requested Issues potentially verifiable by issue author bug Issue identified by VS Code Team member as probable bug containers Issue in vscode-remote containers verified Verification succeeded
Projects
None yet
Development

No branches or pull requests

5 participants