'Argument list too long' when starting server through WSL

[NotNite]

Not sure what diagnostics I can provide - on connection, this shows up in the logs, then the connection closes:

[2023-04-24 17:18:00.641] /home/julian/.vscode-server/bin/704ed70d4fd1c6bd6342c436f1ede30d1cff4710/node.orig: line 8: /nix/store/791x1p2r8qzh463ymsa2p9h0ngw6nid1-patchelf-vscode-server/bin/patchelf-vscode-server: Argument list too long
[2023-04-24 17:18:00.641] /home/julian/.vscode-server/bin/704ed70d4fd1c6bd6342c436f1ede30d1cff4710/node.orig: line 11: /home/julian/.vscode-server/bin/704ed70d4fd1c6bd6342c436f1ede30d1cff4710/node.orig: Argument list too long
[2023-04-24 17:18:00.641] /home/julian/.vscode-server/bin/704ed70d4fd1c6bd6342c436f1ede30d1cff4710/node.orig: line 11: /home/julian/.vscode-server/bin/704ed70d4fd1c6bd6342c436f1ede30d1cff4710/node.orig: Success
[2023-04-24 17:18:00.642] VS Code Server for WSL closed unexpectedly.

[ErikMcClure]

I also ran into this problem with the same error after rebuilding a new nixos install:

[2023-04-27 09:49:32.267] /home/erikm/.vscode-server/bin/704ed70d4fd1c6bd6342c436f1ede30d1cff4710/node.orig: line 8: /nix/store/yhpni7dfywwcwlya3rwrn0gqib5rn9xn-patchelf-vscode-server/bin/patchelf-vscode-server: Argument list too long
[2023-04-27 09:49:32.267] /home/erikm/.vscode-server/bin/704ed70d4fd1c6bd6342c436f1ede30d1cff4710/node.orig: line 11: /home/erikm/.vscode-server/bin/704ed70d4fd1c6bd6342c436f1ede30d1cff4710/node.orig: Argument list too long
[2023-04-27 09:49:32.267] /home/erikm/.vscode-server/bin/704ed70d4fd1c6bd6342c436f1ede30d1cff4710/node.orig: line 11: /home/erikm/.vscode-server/bin/704ed70d4fd1c6bd6342c436f1ede30d1cff4710/node.orig: Success
[2023-04-27 09:49:32.267] VS Code Server for WSL closed unexpectedly.

[msteen]

At the moment I don't have easy access to WSL, but I made some changes that possibly have fixed this issue, could any of you test whether it now works?

[ErikMcClure]

I tried the latest changes, rebooted the wsl instance, removed the service and restarted it, but unfortunately get the same errors:

[2023-04-28 10:53:19.085] /home/erikm/.vscode-server/bin/704ed70d4fd1c6bd6342c436f1ede30d1cff4710/node.orig: line 8: /nix/store/yhpni7dfywwcwlya3rwrn0gqib5rn9xn-patchelf-vscode-server/bin/patchelf-vscode-server: Argument list too long
[2023-04-28 10:53:19.085] /home/erikm/.vscode-server/bin/704ed70d4fd1c6bd6342c436f1ede30d1cff4710/node.orig: line 11: /home/erikm/.vscode-server/bin/704ed70d4fd1c6bd6342c436f1ede30d1cff4710/node.orig: Argument list too long
[2023-04-28 10:53:19.085] /home/erikm/.vscode-server/bin/704ed70d4fd1c6bd6342c436f1ede30d1cff4710/node.orig: line 11: /home/erikm/.vscode-server/bin/704ed70d4fd1c6bd6342c436f1ede30d1cff4710/node.orig: Success
[2023-04-28 10:53:19.086] VS Code Server for WSL closed unexpectedly.

I do not have an easy way to verify that I definitely was running the new version and not the old version, however, so it's possible I missed a step.

[msteen]

Thanks for trying. I tend to clean with rm -r ~/.vscode-server/ and then you can make sure the service is the new one with:

systemctl --user disable auto-fix-vscode-server.service
systemctl --user enable auto-fix-vscode-server.service
systemctl --user start auto-fix-vscode-server.service

Overkill, but sometimes needed to get it to use the latest. Though just doing:

systemctl --user restart auto-fix-vscode-server.service

Tends to work for me.

To verify you could check whether it is now using bash rather than sh at the top of the script:

ls -la ~/.vscode-server/bin/*/node

To make sure it is the patched script. And then doing something like nano or cat to see if it now lists bash at the top:

cat ~/.vscode-server/bin/*/node

[NotNite]

Tried updating, but it seems shellcheck is getting in the way:

error: builder for '/nix/store/zsyqfdajgjxkj4b81c4w7liq8pzm63m4-auto-fix-vscode-server.drv' failed with exit code 1;
       last 7 log lines:
       >
       > In /nix/store/1b66wlzickavi0jx87hypk3dvbyg8z1s-auto-fix-vscode-server/bin/auto-fix-vscode-server line 11:
       >   local bin=$1 actual_dir=$bins_dir/$1 patched_file=~/.vscode-server/.$bin.patched
       >         ^-^ SC2318 (warning): This assignment is used again in this 'local', but won't have taken effect. Use two 'local's.
       >
       > For more information:
       >   https://www.shellcheck.net/wiki/SC2318 -- This assignment is used again in ...
       For full logs, run 'nix log /nix/store/zsyqfdajgjxkj4b81c4w7liq8pzm63m4-auto-fix-vscode-server.drv'.

[msteen]

Thanks for letting me know! I just pushed a fix. Did you get the error in your logs, or just at build time? I did not have it show up when I tried nix flake check which did catch some other shell check issues before.

[NotNite]

That was when running nixos-rebuild switch - give me a second to update & rebuild and I'll let you know if this version works.

[msteen]

:+1: Probably some different versions as play, as I test every time whether it still works for me, which includes running nixos-rebuild too.

[NotNite]

Tried again after updating the flake, rebuilding my system config, and restarting the service. I had to delete the ~/.vscode-server folder and let it be redownloaded on the next connection - it seems to have worked! I can now edit my server config from my Windows machine without hassle - thanks a lot.

Can confirm the shebang is now correctly set to Bash:

$ cat ~/.vscode-server/bin/*/node | head -n 1
#!/nix/store/rnkas52f8868g1hjdlldbvh6snm3pglv-bash-5.2-p15/bin/bash

I'll leave this open in case @ErikMcClure is having any issues.

[msteen]

Good to hear. Thanks for the fast feedback! I will be closing it, if the problem still persist for others, they can comment and I will reopen, or another issue can be made.

[ErikMcClure]

It works! I just had to delete the ~/.vscode-server directory and reboot the service to get the new changes.

[ErikMcClure]

I have discovered that this bug has only been partially fixed. If you shutdown WSL, then restart it, and reopen visual studio code, the same error will happen:

[2023-05-02 06:51:11.954] /home/erikm/.vscode-server/.704ed70d4fd1c6bd6342c436f1ede30d1cff4710.node: line 8: /nix/store/hczpnz3w7cs3x6ww70fc28bd7kac2xl9-patchelf-vscode-server/bin/patchelf-vscode-server: Argument list too long
[2023-05-02 06:51:11.954] /home/erikm/.vscode-server/.704ed70d4fd1c6bd6342c436f1ede30d1cff4710.node: line 11: /home/erikm/.vscode-server/.704ed70d4fd1c6bd6342c436f1ede30d1cff4710.node: Argument list too long
[2023-05-02 06:51:11.954] /home/erikm/.vscode-server/.704ed70d4fd1c6bd6342c436f1ede30d1cff4710.node: line 11: /home/erikm/.vscode-server/.704ed70d4fd1c6bd6342c436f1ede30d1cff4710.node: Success
[2023-05-02 06:51:11.955] VS Code Server for WSL closed unexpectedly.

This can be fixed by just deleting ~/.vscode-server, but this means that the folder must be deleted every time WSL is restarted or the host machine is restarted, which is very annoying.

Unfortunately, I have absolutely no idea how or why this would happen, but I would guess it has something to do with vscode not behaving properly when the folder already exists. The weird thing is, if you close vscode and re-open it without restarting WSL, it still works fine. ONLY restarting WSL triggers this bug, for some reason. It's possible this has to do with the "cannot detect whether server is installed" error that happens, but this error has always happened and it didn't seem to cause problems before.

[msteen]

@ErikMcClure Thank you for reporting this! I think it might be broader than this issue as I noticed I could not connect either after the server I tried to connect to had a power failure, i.e. reboot. I thought I had just left it in a bad state after some previous tests, and after removing ~/.vscode-server it has been working fine, but know I know it might potentially be the same thing, I will have to do some testing to see whether this is actually the case.

[msteen]

@ErikMcClure I managed to verify the problem, on reboot I could no longer connect as well. I checked the contents of ~/.vscode-server and it turned out the original node was overwritten by the script replacement of node. This was caused by it running the patch script too often. This happened due to a bad refactor of mine, I forgot to replace one of the .patched file paths. I just tested it and it now works again across reboots. Thanks again for pointing out the problem!

[ErikMcClure]

This seems to have fixed the problem, although I had to do the full systemctl service disable + restart to actually get the new code. I'll let you know if I find another edge-case that breaks 😆