Restart/Kill Server on Host...

[atharen]

Is there an equivalent to Remote-SSH: Kill VS Code Server on Host... from the Command Palette?

---

Came about, as the official server has a similar option to remote.SSH.remoteServerListenOnSocket

It is listed at https://github.com/jeanp413/open-remote-ssh/blob/master/package.json#L90, but the official appends to the description:

When true, the remote VS Code server will listen on a socket path instead of opening a port. Only valid for Linux and macOS remotes. After toggling this setting, run the command "Kill VS Code Server on Host..." for it to take effect. Requires OpenSSH 6.7. Disables dynamic port forwarding and "local server" mode. Requires AllowStreamLocalForwarding to be enabled for the SSH server.

[jeanp413]

Not yet, need to implement that, but I think that command is only needed if the server is already running in the remote machine, if you set remote.SSH.remoteServerListenOnSocket to true before connecting it should work as expected

[GitMensch]

Can someone explain to me what this setting actually does? Should this option be preferred? Could we adjust this per remote?

[atharen]

Can someone explain to me what this setting actually does? Should this option be preferred? Could we adjust this per remote?

Mostly as a troubleshooting mechanism, probably not the highest priority.

From the VS Code docs:

General troubleshooting: Remove the server

One command helpful to troubleshoot a variety of Remote-SSH issues is Remote-SSH: Kill VS Code Server on Host. This will remove the server, which can fix a wide range of issues and error messages you may see, such as "Could not establish connection to server_name: The VS Code Server failed to start."

[GitMensch]

Thanks for taking the time, but I should have been clearer. My question was not related to the command, but instead to the setting remote.SSH.remoteServerListenOnSocket.

[atharen]

https://github.com/microsoft/vscode/issues/109475 has the most thorough answer, but tl;dr it provides security for multi-user server access, as generates user-specific UNIX sockets, whereas the default TCP port can be accessible to anyone.

---

Tbh, never considered that is could already be using websockets; I have attempted to take a glance at it, but was not sure what to look for;

I did find the remoteServerListenOnSocket option declared, and used in authResolver.ts, which leads to useSocketPath in ServerSetup.ts.

It could be just that the option is already there, just not listed as a user specified option - i.e. setting just missing from front-end.

---

Now thinking about it, when I opened the question, I had a different issue, but at the time I was hoping this could fix it - but eventually it was discovered to be an unrelated server issue, not a Remote SSH issue, so sort of solved itself.

So from my end these are sort of low-priority, as rarely had issues with Remote SSH. I guess for robustness sake they should still be considered but definitely not critical.