Run separate VS Code servers per workspace in the same remote to enable different env variables per workspace.

[markusdd]

VSCode Version: 1.63.2
SSH Remote extension latest preview (v0.71.2021121615 Pre-Release)
Local OS Version: Fedora 35
Remote OS Version: CentOS 7.9
Remote Extension/Connection Type: SSH

Consider the following ssh config for 2 different environment on 1 remote node (simple example, my actual one has way more variables for tool path setups etc.):

Host slpcomp1-project1
  HostName slpcomp1
  User mkrause
  ForwardX11 yes
  RemoteCommand bash -c "export PRJHOME=/lscratch/mkrause/project1; bash"

Host slpcomp1-project2
  HostName slpcomp1
  User mkrause
  ForwardX11 yes
  RemoteCommand bash -c "export PRJHOME=/lscratch/mkrause/project2; bash"

Now connect to these projects:

For project1 everything looks as expected:

For project2 we end up with the wrong environment:

This is of course an error, because our remote command did not actually get honored. VS Code just reused the existing connection, which in this case is obviously incorrect.

When looking at the process tree it actually looks kind of hilarious because the session we wanted is there (green arrow), but the whole second editor window and the embedded terminal ended up under the process tree of the first window, which is entirely unrelated.

So for actual different workspaces there needs to be a seperate vs code server running, otherwise you cannot work in two different environments and workspaces on the same node, which an absolute must in more complex tool and environment setups.

/cc @mhoeher

[tanhakabir]

Currently when you first remote into a remote machine we start a VS Code server as a child process from the ssh process that connected to the machine. In that process the environment variables that you had set in your RemoteCommand is inherited.

When you connect a second time to that same machine, VS Code detects there's already a running VS Code server and uses that running server for the new connection. So the environment variables are never changed because VS Code is listening the the original server created from the first connection. Which is why you won't see the variables appear differently in the second connection.

At the moment we don't spin up multiple servers and the only way to change the environment of the server is to Kill VS Code Server on Host... and connect again.

I can mark this as a feature request if you'd like to have 2 servers running at the same time on the remote or you can close this issue if you feel like you don't need that support.

[markusdd]

I opened the issue because we definetly need the support for that and I think many others do as well. Because Remote SSH will mostly be used to connect to central powerful compute infrastructure where multiple envs will be common.

Also please consider issue #6187 in that context. Currently the env can only be reloaded by killing the server, which is very inconvenient, because that command removes the server, and does not just restart it. So if an env variable changes, you will have to go through disconnecting, killing the server and then re-establishing which means going through the whole remote code install process and then reconnect. Normally this should work with one 'Window reload'

Also, as soon as 2 envs were supported, you would kill the other session. Which once again comes down to the point of: The extension should work per workspace and not per remote node.

[tanhakabir]

I can definitely see that need but I'd like to keep this as a feature request for now since it does involve a larger code change. I'd like to close the other issue you had about window reload since this feature would solve that as well.

[markusdd]

yes totally make sense. I know that the server re-use is a known and wanted concept currently and this is not necessarily a bug but just a 'feature-conflict' which sort of gets introduced by RemoteCommand support.

Basically the feature request is to disable remote server sharing and spawning a dedicated one per workspace remote.

[markusdd]

As #6187 got merged into this, adding this important comment: https://github.com/microsoft/vscode-remote-release/issues/6187#issuecomment-1022571243

[treitmayr]

I face the same issue, however not for environment variables but for entering a ClearCase view on the remote host. I.e. our RemoteCommand entries differ in the name of the ClearCase dynamic view, like in RemoteCommand cleartool setview view_name_one vs. RemoteCommand cleartool setview view_name_two.

Currently it is not possible to work in two different views at the same time, and switching the view requires killing the VS Code server.

[cveld]

Is this request also covering the following use case - I would like to be able to have one workspace that combines:

• folders running on Windows
• folders running on wsl
• some processes / terminals running on Windows
• some processes / terminals running on wsl

Maybe the root cause of this all is the low performance of file system interop between the two platforms. And I still need to figure out whether OneDrive can be connected with a wsl provided mount point.

[PeterWang-dev]

any progress?

[markusdd]

yup is there any activity? This issue is more than 2 years old now and it seems to me that this is a pretty essential feature in corporate settings?