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: |
chrmarti
added
bug
|
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! |
Steps to Reproduce:
:0:devcontainer.json:
result:
I have no idea where the
1is coming from.I have found this issue, which is not related, but you can see in its environment variables
DISPLAY=1is 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: