NixOS-WSL
NixOS-WSL copied to clipboard
Environment variables do not take effect for `wsl --exec`
Bug description
Currently Nix environment variables do not take effect for wsl --exec
. This problem affects VSCode Remote WSL extension badly because by default it uses wsl --exec
to start the code server, which requires nix-ld
and NIX_LD
environment variable to execute properly.
To Reproduce
Steps to reproduce the behavior:
- Install last NixOS-WSL release https://github.com/nix-community/NixOS-WSL/releases/tag/22.05-5c211b47
- Run
wsl --exec nix --version
from PowerShell
<3>WSL (1769) ERROR: CreateProcessEntryCommon:570: execvpe nix failed 2
<3>WSL (1769) ERROR: CreateProcessEntryCommon:579: Create process not expected to return
Expected behavior Show Nix version, which should be 2.8.1
Logs
PS C:\Users\atry> wsl --exec nix
<3>WSL (1769) ERROR: CreateProcessEntryCommon:570: execvpe nix failed 2
<3>WSL (1769) ERROR: CreateProcessEntryCommon:579: Create process not expected to return
PS C:\Users\atry> wsl --exec env
HOSTTYPE=x86_64
LANG=en_US.UTF-8
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib:/mnt/c/Program Files/ImageMagick-7.1.0-Q16-HDRI:/mnt/c/Python311/Scripts/:/mnt/c/Python311/:/mnt/c/Windows/system32:/mnt/c/Windows:/mnt/c/Windows/System32/Wbem:/mnt/c/Windows/System32/WindowsPowerShell/v1.0/:/mnt/c/Windows/System32/OpenSSH/:/mnt/c/ProgramData/chocolatey/bin:/mnt/c/Program Files/Microsoft VS Code/bin:/mnt/c/Program Files/NVIDIA Corporation/NVIDIA NvDLISR:/mnt/c/Program Files (x86)/NVIDIA Corporation/PhysX/Common:/mnt/c/Program Files/Git/cmd:/mnt/c/Program Files/dotnet/:/mnt/c/Program Files/GitHub CLI/:/mnt/c/Program Files (x86)/sbt/bin:/mnt/c/ProgramData/nvm:/mnt/c/Program Files/nodejs:/mnt/c/tools/gsudo/Current:/mnt/c/Program Files (x86)/Nodist/bin:/mnt/c/Program Files/Java/jdk1.8.0_211/bin:/mnt/c/Program Files/OpenJDK/jdk-19.0.2/bin:/mnt/c/ProgramData/chocolatey/lib/mpv.install/tools:/mnt/c/Users/atry/AppData/Local/Microsoft/WindowsApps:/mnt/c/ProgramData/chocolatey/lib/psutils/tools/psutils-master/:/mnt/c/Users/atry/AppData/Roaming/Python/Scripts
TERM=xterm-256color
XDG_RUNTIME_DIR=/mnt/wslg/runtime-dir
DISPLAY=:0
WAYLAND_DISPLAY=wayland-0
PULSE_SERVER=/mnt/wslg/PulseServer
WSL2_GUI_APPS_ENABLED=1
WSLENV=WT_SESSION::WT_PROFILE_ID
WT_SESSION=4d87b811-c89e-4982-a071-2f47852fd7eb
WT_PROFILE_ID={61c54bbd-c2c6-5271-96e7-009a87ff44bf}
WSL_INTEROP=/run/WSL/1799_interop
NAME=DESKTOP-SICQMTD
HOME=/root
USER=root
LOGNAME=root
SHELL=env
WSL_DISTRO_NAME=NixOS
Running a command with wsl --exec
skips the shell completely, so I don't see any way for us to get environment variables in there. In the case of syschdemd (as opposed to native-systemd), this also means that the command won't run in the systemd environment. For VSCode specifically, I suggest you use https://github.com/msteen/nixos-vscode-server, to automatically patch the VSCode server
The workaround for using nix-ld with vscode server is to change remote.WSL2.connectionMethod
setting. I added approach the to the wiki page
https://nixos.wiki/wiki/Visual_Studio_Code#:~:text=should%20%22just%20work%22.-,Remote%20WSL,-Similar%20to%20SSH
Overall speaking, nix-ld
is a more general approach than the patchelf
approach when working in a development environment with package managers other than Nix, because these package managers could download binaries only compatible with FHS.
Does nix-ld remove the need for patching the server? If so, I should give it a shot
Yes
Does https://github.com/msteen/nixos-vscode-server work in WSL? On the project's main page it says it is not working quite well... For anyone who want a quick (and impure) way to work with vscode, take a look at my solution: https://github.com/sonowz/vscode-remote-wsl-nixos
I switched to nix-ld and it seems to work far better than https://github.com/msteen/nixos-vscode-server. I was using that before and it worked as well, but the connection would sometimes fail after a vscode update. That doesn't happen with nix-ld
When I tried using nix-ld, the websocket connection wouldn't work anymore. Are you using ssh remote or wsl? Also are you connecting through localhost or wsl.exe?
I use the WSL remote with "remote.WSL2.connectionMethod": "wsl2VMAddress"
FYI, as of the 1.77 release of vscode setting remote.WSL2.connectionMethod
is ignored and so setting this as a workaround no longer works.
I have raised an issue with vscode for this: https://github.com/microsoft/vscode-remote-release/issues/8305