-
Notifications
You must be signed in to change notification settings - Fork 310
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
Attached Containers: First window closes when second connects #10646
Comments
Are you seeing this issue also with a smaller workspace that does not see the file watcher limit reached? |
Here are the container logs from Ubuntu 20 with a smaller workspace. I didn’t see any messages about the file watcher reaching its limit, but there were still prints similar to the previous port conflict issue.
|
The log entries about port forwarding do not necessarily indicate any issues:
In this case the server port inside the container is 45711 (the last of the three port numbers), the port forwarding is listening locally on the same port number (second number) and VS Code is connecting from several local port numbers (the first number). This does not indicate a port conflict. Are you seeing the window disconnect in this setup with the smaller workspace too? (Since you didn't explicitly mention it.) |
When I use a smaller workspace, I still encounter file watcher-related messages, as shown below:
I think I have identified the issue. Since multiple users share the same container, to ensure that each user can use their own plugin configurations and make the container compatible with their specific version of VS Code (avoiding re-downloading every time the container is created), I mounted the ./vscode-server directory as a data volume and used symbolic links, as shown in the diagram below: When I removed this symbolic link, the connection of multiple windows returned to normal. Do you have any better suggestions for addressing this issue? |
Could you please let me know which version introduced this feature and how does it work? When I removed the symbolic link and created a container on the same server using VS Code to attach, it still re-downloaded all the extensions and the VS Code server. I checked my server, and the ~/.vscode-remote-containers directory exists. Here are my container logs:
|
I believe the possible reason might be: although my SSH server distinguishes between usernames, all users in the container use a unified username to ensure proper access to my data volumes. Could it be that this configuration is looking up ~/.vscode-remote-containers on the server based on the username inside the container? If so, I feel this setup is not suitable for my scenario. After setting |
I realize you are attaching to the container and not building it from a devcontainer.json. In that case the extension cannot mount the cache volume, Docker doesn't allow for adding mount points to an existing container. |
So, does this feature work by directly mounting ~/.vscode-remote-containers on the remote server to the container's ~/.vscode-server directory? If I use this approach to build the container, instead of mounting it to another directory and then symlinking it to ~/.vscode-server, would that solve the file watch issue? |
To make it work with your own container, you can run the container with |
Thank you for your help. I have successfully identified the issue, and I will try to resolve it. |
I tried mounting the server's |
Originally posted by @XhosaS in #10028
The text was updated successfully, but these errors were encountered: