vscode-remote-release icon indicating copy to clipboard operation
vscode-remote-release copied to clipboard

Unable to connect to VS Code server: Error in request - ENOENT /run/user/1000/vscode-ipc-*.sock

Open eliot-akira opened this issue 3 years ago • 10 comments

I'm occasionally but regularly seeing this error when using Remote SSH and running the code command in the built-in terminal.

Unable to connect to VS Code server: Error in request.
Error: connect ENOENT /run/user/1000/vscode-ipc-5cc265b0-6bec-4e0e-99c7-8fc48bccd7c4.sock
    at PipeConnectWrap.afterConnect [as oncomplete] (node:net:1161:16) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'connect',
  address: '/run/user/1000/vscode-ipc-5cc265b0-6bec-4e0e-99c7-8fc48bccd7c4.sock'
}

Searching in Issues, #6362 seemed related, and this comment in particular gave me a hint for a temporary solution.

VSCODE_IPC_HOOK_CLI=$( lsof | grep $UID/vscode-ipc | awk '{print $(NF-1)}' | head -n 1 )

It searches for the first available VSCode IPC socket, gets its second to last column for the path to vscode-ipc-*.sock, and updates the relevant env variable. (In the original code snippet, they were getting the last column using awk '{print $NF}' but on my system that returns type=STREAM instead.)

After running the above line, the error no longer occurs.

I'm OK with this temporary fix, but I figured I'd make an issue report, in case someone can get to the bottom of it and solve it permanently.


  • VSCode Version: 1.69.2
  • Local OS Version: Darwin x64 18.2.0
  • Remote OS Version: Ubuntu 22.04 LTS
  • Remote Extension/Connection Type: SSH

Steps to Reproduce:

The error appears occasionally (maybe after host reboots or when Remote SSH reconnects?). It might be related to #6988, "Vscode server stops after running for a while without use".

  1. Open terminal with CTRL/CMD+J
  2. Run code some-file.txt

eliot-akira avatar Jul 27 '22 14:07 eliot-akira

I have the same issue of this, and it only happens when I accidently closed the connection to remote (for example, Ctrl+Q to close the remote window) and instantly reopen it. The error on my side can be solved upon eliot's approach, but it is indeed not convenient when I have multiple opened cli windows. I guess this error may be related with some recent updates on remote-cli since I did not see this error at least in the version which did not change code into code-server and mv code into dir remote-cli


VSCode Version: 1.69.1 Local OS Version: CentOS Linux release 8.5.2111 Remote OS Version: CentOS Linux release 8.4.2105 Remote Extension/Connection Type: SSH

qcxia20 avatar Jul 28 '22 06:07 qcxia20

Same problem. Trying to work out how to use your solution above - if I run $ lsof | grep $UID/vscode-ipc | wc -l I have 90 lines. Is that normal??

VsCode 1.69.2 Remote OS: Rocky Linux release 8.5 (Green Obsidian) Remote Extension/Connection Type: SSH

sjpb avatar Aug 04 '22 14:08 sjpb

same issue

Unable to connect to VS Code server: Error in request.
Error: connect ENOENT /run/user/1003/vscode-ipc-29b85497-9c46-43f3-b7bb-30557442106d.sock
    at PipeConnectWrap.afterConnect [as oncomplete] (node:net:1161:16) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'connect',
  address: '/run/user/1003/vscode-ipc-29b85497-9c46-43f3-b7bb-30557442106d.sock'

zjiaqi2018 avatar Aug 04 '22 15:08 zjiaqi2018

I just got the same thing in Codespaces:

Unable to connect to VS Code server: Error in request.
Error: connect ENOENT /tmp/vscode-ipc-aac63c64-d630-482f-a06b-b651ce82b0e3.sock
    at PipeConnectWrap.afterConnect [as oncomplete] (node:net:1161:16) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'connect',
  address: '/tmp/vscode-ipc-aac63c64-d630-482f-a06b-b651ce82b0e3.sock'
}

There was an auto-update waiting. Restarting to get the update solved the problem. So I wonder if this has to do with the auto-updater.

aaronadamsCA avatar Aug 04 '22 20:08 aaronadamsCA

This problem has a workaround https://github.com/microsoft/vscode-remote-release/issues/3575. Apparently after a VSCode update the cached server doesn't get invalidated properly.

Of course this workaround is not nice and should be handled automatically, sadly the other Issue was closed prematurely.

SoftwareApe avatar Aug 05 '22 07:08 SoftwareApe

The temporary fix that's working for me is to refresh the constant VSCODE_IPC_HOOK_CLI with an open/available socket process named vscode-ipc-*.sock.

It means the error is caused by that environment variable having a "stale" value, pointing at an old socket process which no longer exists.

I searched for where the constant is being used, in all the repos under the microsoft organization (search result). Here's where the error is occurring.

https://github.com/microsoft/vscode/blob/f8ae10c8d05cf92f55c19b4937f0a5c5c0498778/src/vs/server/node/server.cli.ts#L374

The env variable is passed to the http module for the option socketPath. When it's an invalid value, http.request throws, "Error in request - ENOENT".


Interestingly, when I search for this env variable throughout GitHub (result), there are other people who ran into the same error with stale socket process causing an error in VSCode server CLI.

From the top result:

The VSCODE_IPC_HOOK_CLI environment variable points to a socket which is rather volatile, while the long path for the 'code' alias is more stable: vscode doesn't change the latter even across a "code -r ." reload. But the former is easily detached and so you need a fresh value if that happens. (source)

And the second:

Each time the VS Code window is reloaded a new IPC socket is created. If you leave a background processes running and then exit VS Code (or reconnect) it with have a stale VSCODE_IPC_HOOK_CLI variable/IPC socket and won't be able to open the browser on your host.

To fix, update VSCODE_IPC_HOOK_CLI in the process's environment to the latest socket. (source)


So we're all seeing the same issue.

The permanent solution seems to be: in vscode/src/vs/server/node/server.cli.ts, to check if VSCODE_IPC_HOOK_CLI is pointing to a living socket process; if it's not, refresh the value with the path to an available one. Basically applying the fix that we're doing internally and automatically.

eliot-akira avatar Aug 05 '22 14:08 eliot-akira

@eliot-akira I'm not quite sure that's the only issue. when I refresh VSCODE_IPC_HOOK_CLI and use 'code --wait' as my git rebase editor, it tells me I need to run the command from a console that was started from within VSCode.

SoftwareApe avatar Aug 05 '22 14:08 SoftwareApe

@SoftwareApe It sounds like you might be experiencing a related but different issue. For me, that one-liner in the issue description solved it completely (so far). But from your earlier comment, I see you're having to remove ~/.vscode-server (and probably reload the window or restart the editor).

eliot-akira avatar Aug 05 '22 15:08 eliot-akira

@eliot-akira yes, that's right, delete the server and restart helped

SoftwareApe avatar Aug 05 '22 20:08 SoftwareApe

@SoftwareApe It sounds like you might be experiencing a related but different issue. For me, that one-liner in the issue description solved it completely (so far). But from your earlier comment, I see you're having to remove ~/.vscode-server (and probably reload the window or restart the editor).

yes, but my ~/.vscode-server has produced more than 9G data, no idea if there are some useful cache (like produced by cpp extension, help me travel in my huge project) that I don't want to delete. image

so I'm using the VSCODE_IPC_HOOK_CLI solution

Tamce avatar Aug 08 '22 10:08 Tamce

I am also encountering this issue, but seemingly only after setting up an rsa key as the preferred ssh authentication method. Not sure if it's related but i thought I'd mention it.

AidanGlina avatar Oct 26 '22 20:10 AidanGlina

Having this issue when using code -r . to open VS code's folder structure to where I am in my present working directory.

Varelion avatar Nov 09 '22 18:11 Varelion

I had the same issue and the workaround from @eliot-akira did not work in my case. For me this following slightly modified command solved the issue: VSCODE_IPC_HOOK_CLI=$(lsof | grep $USER | grep vscode-ipc | awk '{print $(NF-1)}' | head -n 1)

RobertoDonPedro avatar Nov 10 '22 09:11 RobertoDonPedro

I had the same issue and for me I cleared the cache files in folders vscode-server/ .vscode-server-insiders/:

rm -rf .vscode-server/
rm -rf .vscode-server-insiders/

and restarting the CLI solved the problem.

ghlrobin avatar Dec 05 '22 14:12 ghlrobin

close vscode then in powershell: wsl --shutdown. Then reopen vscode..

bwelboren avatar Dec 11 '22 18:12 bwelboren

This problem has a workaround #3575. Apparently after a VSCode update the cached server doesn't get invalidated properly.

Of course this workaround is not nice and should be handled automatically, sadly the other Issue was closed prematurely.

Here it suggests removing the ~/.vscode-server folder which is inconvenient because you also remove all extensions and stuff. In my case, by removing ~/.vscode-server/bin/blah/vscode-remote-lock.<my_user>.blah solved the issue and I got to keep everything including the installed extensions.

lmrlyv avatar Dec 14 '22 10:12 lmrlyv

Is this happening in a terminal that was previously open, before reconnecting? I guess the value of the IPC environment var is stale, does this work in a new terminal when failing in the old terminal?

roblourens avatar Dec 17 '22 21:12 roblourens

I haven't found a reliable way to reproduce the issue, but in my case I believe it's always with a new terminal opened after VSCode Server reconnects.

For reference, I opened a corresponding issue in microsoft/vscode#157275, close to the file where the error is occurring: src/vs/server/node/server.cli.ts. It's where the constant cliPipe is defined from the env variable, and the function sendToPipe passes it in a call to http.request, which throws if the socket is stale.

The solution seems to be, before the call to http.request, it needs to check and refresh the socket path to make sure it's pointing to a living process. I'm not sure about the technical details how best to implement it - perhaps it's more efficient to catch the ENOENT error, then refresh the socket path to retry as needed (instead of checking on every call to sendToPipe).

eliot-akira avatar Dec 17 '22 22:12 eliot-akira

Thanks for opening that upstream issue. I thought I'd heard about this recently. Will close this in favor of the other issue. https://github.com/microsoft/vscode/issues/157275

roblourens avatar Dec 17 '22 22:12 roblourens

I somehow ran into the same problem. Restarting VS Code app did not fix the issue for me.

what worked was, I ssh -ed into the remote machine via a terminal and htop -u $USER to see running processes. A few vscode-server processes were still running even after the app is closed. Using htop I killed all processes that had $HOME/.vscode-server/blah/blah pathname. Then reopening vscode and re-login into remote development session fixed the issue for me!

thammegowda avatar Dec 19 '22 19:12 thammegowda

Same issue, restarting vscode etc doesn't work, but @eliot-akira 's workaround worked right away. Thanks for both raising this, and for making the workaround so easy to find @eliot-akira :)

strazto avatar Dec 20 '22 00:12 strazto

use below commands and then it will ask id password again while doing any transaction on git.

rm -rf .vscode-server/ rm -rf .vscode-server-insiders/

theabidkhan avatar Jan 29 '23 10:01 theabidkhan