VSCode remote + WSL

[viperML]

Hello 👋

I have been playing around with VSCode (installed in windows) + the remote WSL extension, and in the process I had to solve some problems. I want to share my findings, and maybe we can find a solution to all of them.

Node binary

When the WSL part of vscode server starts, it will download a pre-compiled node binary from the internet, and try to use it to run the server. This binary doesn't work on NixOS. In the WSL extension logs, you would see something like:

 /home/nixos/.vscode-server-insiders/bin/ed2619e11b68bec43b788486230b0c2afeb4672d/bin/code-server-insiders: line 12: /home/nixos/.vscode-server-insiders/bin/ed2619e11b68bec43b788486230b0c2afeb4672d/node: No such file or directory

Known solutions

• Manually patching or replacing the binary
  One could use the existing nix tooling to patch this binary, or maybe replace it with a symlink into the store.

• Automatic patching with the help of ~/.vscode-server/server-env-setup
  The ~/.vscode-server/server-env-setup path can hold a script that the vscode remote extension will run before running the server. In this script we can automate the process of patching the node binary.
  This is exactly what sonowz/vscode-remote-wsl-nixos does.

• nix-ld
  As the readme says, this allows you to run unpatched binaries, inlcuding the node binary. For my setup I did a "global" installation, by setting the NIX_LD_LIBRARY_PATH and NIX_LD environment variables system wide. It is quite convenient, because the server just works OOTB, but I can understand that users wouldn't want to enable this globally.

{
  pkgs,
  lib,
  ...
}: let
  env = {
    NIX_LD_LIBRARY_PATH = lib.makeLibraryPath [
      stdenv.cc.cc
    ];
    NIX_LD = "$(${pkgs.coreutils}/bin/cat ${pkgs.stdenv.cc}/nix-support/dynamic-linker)";
  };
in {
  environment.variables = env;
  environment.sessionVariables = env;
  programs.nix-ld.enable = true;
}

Maybe this environment could be set with the help of ~/.vscode-server/server-env-setup, by exporting NIX_LD and NIX_LD_LIBRARY_PATH, altough I haven't tried it myself.

remote.WSL2.connectionMethod

I had this error today for the first time, so I suspect vscode changed something in a recent release:

When attaching to WSL, the server would download fine to the distro, but will fail to start, with the error messages:

The logs show:

...
[2022-05-07 09:37:42.493] Server bound to 127.0.0.1:44369 (IPv4)
[2022-05-07 09:37:42.493] Extension host agent listening on 44369
[2022-05-07 09:37:42.493] 
[2022-05-07 09:37:42.510] Started local proxy server on 59760.
[2022-05-07 09:37:42.510] WSL resolver response: 127.0.0.1:59760
[2022-05-07 09:37:42.510] To debug connection issues, open a local browser on http://127.0.0.1:59760/version
[2022-05-07 09:37:42.510] Using 'wslExeProxy' to connect to the VS Code server as configured by setting 'remote.WSL2.connectionMethod'
[2022-05-07 09:37:42.510] 'wslExeProxy' should fix reconnection issues after sleep and network adapter changes.
[2022-05-07 09:37:42.510] Please report issues related with the new setting to https://github.com/microsoft/vscode-remote-release/issues/5894
[2022-05-07 09:37:42.510] To revert back to the old way of connecting, change setting 'remote.WSL2.connectionMethod' to 'wsl2VMAddress'.

And, as it says, by using the setting "remote.WSL2.connectionMethod": "wsl2VMAddress" seems to solve this issue.
I don't know if this is a problem with nixos-wsl, or vscode.

~ not resolved (running as root)

During the initialization of the vscode server, it will call this command:

[2022-05-07 09:07:25.787] Probing if server is already installed: C:\WINDOWS\System32\wsl.exe -d NixOS -e sh -c "[ -d ~/.vscode-server/bin/57fd6d0195bb9b9d1b49f6da5db789060795de47 ] && printf found || ([ -f /etc/alpine-release ] && printf alpine-; uname -m)"
[2022-05-07 09:07:26.415] Unable to detect if server is already installed: Error: Command failed: C:\WINDOWS\System32\wsl.exe -d NixOS -e sh -c "[ -d ~/.vscode-server/bin/57fd6d0195bb9b9d1b49f6da5db789060795de47 ] && printf found || ([ -f /etc/alpine-release ] && printf alpine-; uname -m)"

Upon more investigation, it seems that ~ is resolved to the root user. This is not the behaviour in other distros:

PS C:\Users\ayats> C:\WINDOWS\System32\wsl.exe -d NixOS -e sh -c "echo ~"
/root

PS C:\Users\ayats> C:\WINDOWS\System32\wsl.exe -d Ubuntu -e sh -c "echo ~"
/home/ayats

I don't know if this is a misconfiguration on my side.
Altough vscode seems to ignore this and continue the WSL extension initialisation, I think this should be further investigated.

System details

PS C:\Users\ayats> wsl --version
WSL version: 0.58.3.0
Kernel version: 5.10.102.1
WSLg version: 1.0.33
MSRDC version: 1.2.2924
Direct3D version: 1.601.0
Windows version: 10.0.22000.613

nixpkgs rev: cbe587c735b734405f56803e267820ee1559e6c1
nixos-wsl rev: 506d46f8b7509080388ab5d3c6daca5a1097f649

VSCode 1.67

[nzbr]

I'm on VSCode 1.66.2 and use msteen/nixos-vscode-server, which works quite well, except for the fact that i have to restart the auto-fix-vscode systemd service once after every vscode update.

remote.WSL2.connectionMethod
will probably happen to me after i update to 1.67, so I'm not seeing that yet

~ not resolved (running as root)
That is correct, because running NixOS -e sh does not start the root users shell, which is what changes into the systemd namespace and drops privileges to the user (nixos by default). So /root is actually the current home directory when you run that command. The only way to get around that would be if Microsoft allowed us to actually run systemd as PID 1, removing the need for the namespace switch
This gets pointed out a lot, so I might add a paragraph about that phenomenon to README.md

[SuperSandro2000]

Which settings are you using to make it work?

[stfnx]

Just the defaults without doing anything special. Probably the service was not started properly the first time I tried.

[SuperSandro2000]

In my experience nothing works properly when using a newer version of the remote wsl extension because it doesn't find any env variables in wsl.

[nzbr]

I just managed to get it to work by using nix-ld-rs and doing this:

      programs.nix-ld = {
        enable = true;
        package = pkgs.nix-ld-rs.nix-ld-rs;
        libraries = options.programs.nix-ld.libraries.default ++ [
          (pkgs.runCommand "ld.so" { } ''
            mkdir -p $out/lib
            ln -s "$(cat '${pkgs.stdenv.cc}/nix-support/dynamic-linker')" $out/lib/ld.so
          '')
        ];
      };

[SuperSandro2000]

It seems that

programs.nix-ld = {
  enable = true;
  package = pkgs.nix-ld-rs;
  libraries = with pkgs; [
    stdenv.cc.cc # for libstdc++.so.6
  ];
};

is already enough. The main change from my previous tries is nix-ld-rs.

I am still hesitant because of the devastating effect LD_LIBRARY_PATH can have.