-
Notifications
You must be signed in to change notification settings - Fork 285
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
DISPLAY env does not get set correctly in container #7565
Comments
We set |
Running
Running the same command within VSCode in Windows shows this:
And within VSCode in WSL2 shows this:
|
I also consistently see this issue across multiple laptops and in all the dev containers I've set up that pass through the $DISPLAY variable. I don't have a |
I am experiencing the very same issue using VSCode |
I think the problem is that |
I'm also experiencing this problem using dev containers with WSL images in vs code.
|
I'm using a WSL2-based dev container as well and as of version 1.83.1 this issue still persists. No matter what I attempt, the For now I've applied a workaround by using the following "postStartCommand" in my if [[ $DISPLAY = "1" ]]; then echo "export DISPLAY=:0" >> "~/.bashrc"; fi |
It seems you don't need to specify Therefore removing In addition I had to remove:
from |
Setting |
This is correct in a WSL2 environment, but doesn't work in devcontainers run on native Linux setups where
I ended up using this workaround. Note the different quote signs and the sh-compatible string comparison compared to #7565 (comment). |
There is a fix in Dev Containers 0.366.0-pre-release. Could everyone seeing this issue give that a try and let me know if there are any remaining issues? Thanks! |
I can confirm the issue is gone in the WSL2 setup (obviously after reloading the window and rebuilding the container). Even without "containerEnv": {
"DISPLAY": "${localEnv:DISPLAY}"
}
On a native Linux, the snippet above is still required, though, but now setting the right value (while it would e.g. set So in short: With the snippet above and the pre-release version, everything works as expected on both WSL2 and native Linux setups using the very same |
@rsarrazin2 The reason the Dev Containers extension sets Are you mounting |
@chrmarti: No mounting "containerEnv": {
"DISPLAY": "${localEnv:DISPLAY}"
},
"remoteUser": "vscode",
"runArgs": [
"--network=host"
],
"mounts": [
// Make bash history persistent (by mapping the local history to the container's remote user's).
"type=bind,source=${localEnv:HOME}/.bash_history,target=/home/vscode/.bash_history",
// Make SSH keys available to the vscode user
"type=bind,source=${localEnv:HOME}/.ssh,target=/home/vscode/.ssh",
// Make local home folder available in the container under its original path (and not as the remote
// user's home folder).
// This can be useful for example to enable git worktrees in the container (as the paths to the
// worktree master are set as absolute paths).
"type=bind,source=${localEnv:HOME}/,target=${localEnv:HOME}/"
] |
@rsarrazin2 What do you get for |
@chrmarti I created an MVP at https://github.com/rsarrazin2/devcontainer_for_vscode_remote_extension. Here is what I get inside the container:
And outside: See docker inspection report mvp.json. |
@rsarrazin2 Could you also append the Dev Containers log from right after reopening the folder in the container? ( The |
@chrmarti here you are: container.log. I just want to clarify in case there's a misunderstanding on my side: The reports I provide are from the WSL setup where the |
@rsarrazin2 The setup where the statement is required would be the most interesting. Could you send the information from that too? Thanks. |
@chrmarti The native-Linux-setup colleagues are currently on leave and I don't have such a setup locally. I'll come back with more information in the course of this week. Thanks for your patience! |
@chrmarti I got the feedback from the native Linux colleagues who gave the MVP a try with the pre-release version.
So everything actually looks good in my opinion. Maybe we hadn't correctly reloaded and/or rebuilt the container on our various tries and mistakenly thought the statement was required in the native Linux. Thank you for your patience, and I hope you didn't waste too much time digging into the issue although it seems the latest extension revision actually solved it. |
Great, thanks! |
@chrmarti I'm sorry but I didn't understand whether wayland support was added or not? If it was, do we need to set a special flag or use a special base image? Is there any documentation for it? |
@ATheCoder We mount the Wayland socket when available in the container. For this to work the socket needs to be on the same machine as the container (WSL on Windows or plain Linux) otherwise we don't mount it. |
Steps to Reproduce:
:0
:devcontainer.json:
result:
I have no idea where the
1
is coming from.I have found this issue, which is not related, but you can see in its environment variables
DISPLAY=1
is set. So it is not only a problem with my system.I also found this issue with the exact same problem and the possible solution to set
WSLENV
. But I cannot find any documentation how, where or why to set it.Full Log
Does this issue occur when you try this locally?: No
Does this issue occur when you try this locally and all extensions are disabled?: No
The text was updated successfully, but these errors were encountered: