Wrong shared IPC handle path

[chuckb]

When I attempt to open the extensions pane, I get:
ERROR connect ENOENT /var/folders/g2/6zvms_f57kv7rxcsm7_4pzdm0000gq/C/Code-1.14.0-shared.sock

This used to work but as I have taken several VSCode updates recently, I am not sure when it stopped working.

NOTE: Use Help > Report Issues to prefill below does not work either. I get the same error.

VSCode version = 1.14.0

charles-benedicts-macbook:sd-prototype chuck_benedict$ dotnet --info
.NET Command Line Tools (2.1.0-preview1-006723)

Product Information:
 Version:            2.1.0-preview1-006723
 Commit SHA-1 hash:  7e1fe7eba7

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.12
 OS Platform: Darwin
 RID:         osx.10.12-x64
 Base Path:   /usr/local/share/dotnet/sdk/2.1.0-preview1-006723/

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0-preview3-25502-01
  Build    : bd3f818bad84f1296b4ee53f72ab8837b3caac98

charles-benedicts-macbook:sd-prototype chuck_benedict$

Steps to Reproduce:

1. Open VSCode
2. Click the extensions icon

Reproduces without extensions: Well this question is not applicable in this case.

[chuckb]

I installed 1.13.1 and extensions pane now works. I am trying to keep auto-updates from moving me back up to 1.14.0.

[chrmarti]

Could you try reinstalling VSCode? Maybe something in your install broke.

[chuckb]

I set "update.channel": "default" and then let it do its upgrade thing. Upon restart, same error when navigating to extensions pane. When I revert back to 1.13.1, it works again.

[joaomoreno]

Does it reproduce after restarting your computer?

[vscodebot]

This issue has been closed automatically because it needs more information and has not had recent activity. Please refer to our guidelines for filing issues. Thank you for your contributions.

[chuckb]

I decided to update to 1.15.0 to see if magically this got fixed. Nope, still happens. I found issue #13561 and based on what it said, I start vscode from terminal windows instead of finder. If I do that, then extensions pane opens without error.

And yes, I restarted my computer, which on Mac is usually not required ;-).

Please reopen this issue or associate to the other, as this is a bug.

[lambda]

I got the same issue after upgrading to 1.15.1 today.

The error is:

connect ENOENT /var/folders/tx/_yw35btj22zdlsczm5q9bcn00000gn/T/Code-1.15.1-shared.sock

It looks like the sock that is actually open is different:

rust:.vscode lambda$ lsof -p 45020 | grep sock
Code\x20H 45020 lambda   18u    unix 0xdc6a6565667961fb       0t0          /var/folders/tx/_yw35btj22zdlsczm5q9bcn00000gn/T/vscode-9f94e96bc033f50fbc624b787666808510576c44.sock

[rkarolak]

I'm also having this issue with both 1.15.1 and 1.16.0-insider in macOS 10.12.6 (16G29).

[lambda]

After some further investigation, it looks like this might happen because of the asynchronous loading of environment variables from your shell environment.

In my .profile, I have export XDG_RUNTIME_DIR=$TMPDIR, which sets XDG_RUNTIME_DIR to /var/folders/tx/_yw35btj22zdlsczm5q9bcn00000gn/T/.

The path to this socket is computed as follows, in src/vs/platform/environment/node/environmentService.ts:

function getNixIPCHandle(userDataPath: string, type: string): string {
	if (process.env['XDG_RUNTIME_DIR']) {
		return path.join(process.env['XDG_RUNTIME_DIR'], `${pkg.name}-${pkg.version}-${type}.sock`);
	}
	return path.join(userDataPath, `${pkg.version}-${type}.sock`);
}

So if XDG_RUNTIME_DIR is defined, this will look in there, which is the path I see in the error.

However, if XDG_RUNTIME_DIR is not defined, which may happen during startup if the asynchronous environment loading hasn't happened yet, then it will store it in userDataPath, which is computed as follows:

function getAppDataPath(platform) {
	switch (platform) {
		case 'win32': return process.env['VSCODE_APPDATA'] || process.env['APPDATA'] || path.join(process.env['USERPROFILE'], 'AppData', 'Roaming');
		case 'darwin': return process.env['VSCODE_APPDATA'] || path.join(os.homedir(), 'Library', 'Application Support');
		case 'linux': return process.env['VSCODE_APPDATA'] || process.env['XDG_CONFIG_HOME'] || path.join(os.homedir(), '.config');
		default: throw new Error('Platform not supported');
	}
}

And, indeed, there is a ~/Library/Application\ Support/Code/1.15.1-shared.sock that is open in a couple of the VSCode processes.

[chrmarti]

@lambda Thanks for the analysis. @joaomoreno Does this help in narrowing down the issue?

[joaomoreno]

I'm guessing this works for all you guys if you launch Code from a shell?

Related to #28816

[joaomoreno]

Can you give this build a try?

• macOS
• Linux 64

[freedmand]

That build has fixed the issue for me on Mac OS X. (for some reason, it didn't work on the first run-through, giving what looked like the same error. When I moved the app from ~/Downloads to ~/Applications and ran again, it worked. I tested placing it back in ~/Downloads and it still worked)

[tomjakubowski]

I have, I believe, the same issue, due to my (questionable) practice of setting XDG_RUNTIME_DIR in .zshrc on my Mac.

The build @joaomoreno posted resolved the issue for me.

[joaomoreno]

Thanks for the test guys. 🍻

[SkeLLLa]

@joaomoreno is this bug fixed in 1.16.1? I have such issue on linux with vscode 1.16.1. XDG_RUNTIME_DIR is set.

Error:

ENOENT /tmp/1000-runtime-dir/Code-1.16.1-shared.sock

[chrmarti]

@SkeLLLa This fix will be in the upcoming 1.7 release.