Version 1.30.0 does not work on Ubuntu WSL2

[eoussama]

The extension fails to start as soon as a project is opened.
This issue is fixed when I downgrade to the previous version.

Environment

• Operating System: Windows 11 WSL2 Ubuntu 22.04.4 LTS
• JDK version: 11.0.22
• Visual Studio Code version: 1.88.1
• Java extension version: 1.30.0

Steps To Reproduce

1. Open any Java project
2. Notice the error alert at the bottom right

[Error - 2:42:03 PM] Language Support for Java client: couldn't create connection to server. Error:
    ENOENT: no such file or directory, lstat '/run/user/1000' 
        at Object.realpathSync (node:fs:2675:7) 
        at t.generateRandomPipeName (/home/****/.vscode-server/extensions/redhat.java-1.30.0-linux-x64/dist/extension.js:2:1136403) 
        at /home/****/.vscode-server/extensions/redhat.java-1.30.0-linux-x64/dist/extension.js:2:1332887 
        at async c.createConnection (/home/****/.vscode-server/extensions/redhat.java-1.30.0-linux-x64/dist/extension.js:2:1165774) 
        at async c.start (/home/****/.vscode-server/extensions/redhat.java-1.30.0-linux-x64/dist/extension.js:2:1156291)

[fbricon]

Try setting "java.transport" : "stdio" in your vscode settings

[rgrunber]

According to microsoft/WSL#5919 , pipes are not supported, so maybe we need to set this to stdio by default when the client is vscode-server.

However, according to microsoft/vscode-languageserver-node#1346 (comment), it worked on Windows 10 WSL (Ubuntu 20.04).

@testforstephen, let us know if you can reproduce this.

[eoussama]

Try setting "java.transport" : "stdio" in your vscode settings

This work, thank you!

[testforstephen]

However, according to microsoft/vscode-languageserver-node#1346 (comment), it worked on Windows 10 WSL (Ubuntu 20.04).
@testforstephen, let us know if you can reproduce this.

Cannot reproduce it. Version 1.30.0 works for me in Windows 11 WSL (Ubuntu 20.04).

[legolaz8451]

Try setting "java.transport" : "stdio" in your vscode settings

Despite receiving the message "Unknown Configuration Setting," it still worked for me. I'm using WSL2. I'd like to understand why this setting works. Where can I find more information about it?

It seems to be related to this change, but I'm not entirely sure 81d814b

[rgrunber]

Try setting "java.transport" : "stdio" in your vscode settings

Despite receiving the message "Unknown Configuration Setting," it still worked for me. I'm using WSL2. I'd like to understand why this setting works. Where can I find more information about it?

It seems to be related to this change, but I'm not entirely sure 81d814b

Regarding why we did this switch : We were testing pipe for a while in pre-releases because we determined it was less likely to encounter cryptic errors, and after a few months we decided to make it the default. stdio is riskier as any piece of code running under the JVM that attempts to write to standard output might break the communication. We did a lot to reduce this risk but still occasionally got issues filed regarding missing "Content-Length" header, which is the sign something was writing to stdio without understanding the LSP protocol. It's extremely rare, but noticed it happens among the user base. I believe there were also some performance benefits noted for pipe on windows.

Regarding this issue : ENOENT: no such file or directory, lstat '/run/user/1000'

Here's the generated code that fails on realpathSync :

function generateRandomPipeName() {
    if (process.platform === 'win32') {
        return `\\\\.\\pipe\\lsp-${(0, crypto_1.randomBytes)(16).toString('hex')}-sock`;
    }
    let randomLength = 32;
    const fixedLength = 'lsp-.sock'.length;
    const tmpDir = fs.realpathSync(XDG_RUNTIME_DIR ?? os.tmpdir());
    const limit = safeIpcPathLengths.get(process.platform);
    if (limit !== undefined) {
        randomLength = Math.min(limit - tmpDir.length - fixedLength, randomLength);
    }
    if (randomLength < 16) {
        throw new Error(`Unable to generate a random pipe name with ${randomLength} characters.`);
    } 
    const randomSuffix = (0, crypto_1.randomBytes)(Math.floor(randomLength / 2)).toString('hex');
    return path.join(tmpDir, `lsp-${randomSuffix}.sock`);
}

I'd assume XDG_RUNTIME_DIR is set to /run/user/1000 (as it is on my Linux distro). Does that folder exist on the Ubuntu instance ?

[legolaz8451]

Hey @rgrunber, No, it doesn't. Interestingly, in the system logs, I find messages like this:

Starting User Runtime Directory /run/user/1000...
Finished User Runtime Directory /run/user/1000.

FWIW

❯ lsb_release -a
Distributor ID: Ubuntu
Description: Ubuntu 22.04.4 LTS
Release: 22.04
Codename: jammy
❯ uname -srm
Linux 5.15.146.1-microsoft-standard-WSL2 x86_64

[FSeidinger]

I had the same issue with other, java related parts, and the cause is pretty basic and easy to fix. Like @legolaz8451 already pointed out, you will get an Ubuntu 22.04 as the default distribution with installing wsl2.

In the Ubuntu distribution the directory /var/run as the parent of the directory VSC wants to create its socket files in, is owned by root:root with the access rights of rwxr-xr-x.

As VSC runs with the rights of the default owner with uid 1000 and gid 1000, when it tries to create the socket directory and its socket files, it simply fails due to access rights.

What helped for me was something like that:

sudo mkdir /var/run/1000
sudo chown 1000:1000 /var/run/1000

And after restarting VSC everything worked again.

Here is the output from that directory:

ls -aln /run/user/1000
total 0
drwxr-xr-x 2 1000 1000 120 May  7 16:05 .
drwxr-xr-x 3    0    0  60 May  7 16:04 ..
srwxr-xr-x 1 1000 1000   0 May  7 16:05 git-graph-askpass-uYv5TzhyvAfANHBjygENXIPLlOkaEtVj.sock
srwxr-xr-x 1 1000 1000   0 May  7 16:05 vscode-git-67161652e6.sock
srwxr-xr-x 1 1000 1000   0 May  7 16:05 vscode-ipc-3344f81f-7bb3-40ec-8c75-49945bdf38b5.sock
srwxr-xr-x 1 1000 1000   0 May  7 16:05 vscode-ipc-a88e9fd4-ebe2-41fe-b290-aa670e6b603c.sock

[legolaz8451]

Good point @FSeidinger, for me it worked as well. Most of the WSL environments have only one user, hence the coincidence. I applied this changes:

❯ sudo mkdir /run/user/1000
❯ sudo chown 1000:1000 /run/user/1000
❯ sudo chmod 0700 /run/user/1000

In addition to changing the owner, I also retained read and write permissions for the owner as suggested here to minimize the risk of process contention.

I also observed that @rgrunber's code suggests using the temporary directory as a fallback is possible, which could avoid the need for this workaround.

[jamie-burns0]

I was getting these errors when launching vscode Java project under Kali Linux on WSL2.

[Error - 4:11:56 PM] Language Support for Java client: couldn't create connection to server.
Error: listen EACCES: permission denied /run/user/1000/lsp-6962fe54eb565796fc5da37342000835.sock

[Error - 4:11:56 PM] Language Support for Java (Syntax Server) client: couldn't create connection to server.
Error: listen EACCES: permission denied /run/user/1000/lsp-60ec2ffed368ef368c58621f2ff2e49d.sock

The fix suggested by @FSeidinger and @legolaz8451 above worked for me.

❯ sudo mkdir /run/user/1000
❯ sudo chown 1000:1000 /run/user/1000
❯ sudo chmod 0700 /run/user/1000

This error seemed to come out of nowhere. On Thursday (25/JUL AEST) and for months before this i was launching the Java project without any issues. Friday morning (26/JUL AEST) this issue was happening launching any vscode Java project from any of my WSL2 distros.

A cumulative update for windows 11 (KB5040527) was applied to my system on the morning of 26/JUL. I thought maybe Microsoft had changed something in response to the CrowdStrike outage. But i had also run "sudo apt update && sudo apt full-upgrade" on my distros Friday morning 26/JUL. And i think the Language Support for Java(TM) by Red Hat extension also updated itself.

Does anyone have any ideas why this issue appeared to just drop in on me?

[jamie-burns0]

I've been doing some more investigating...

I exported a distro back on 08/MAY. If i create a new distro based on the 08/MAY copy, the /run/user folders have the following

┌──(jamie㉿DESKTOP-JAMIE)-[~]
└─$ ls -lart /run/user
total 4
drwxr-xr-x 3 root root 4096 Apr 30 22:21 .
drwx------ 3 jamie jamie 80 Jul 27 16:33 1000
drwxr-xr-x 18 root root 520 Jul 27 16:35 ..

and

┌──(jamie㉿DESKTOP-JAMIE)-[~]
└─$ ls -lart /run/user/1000
total 4
drwxr-xr-x 3 root root 4096 Apr 30 22:21 ..
drwxr-xr-x 5 jamie jamie 140 Jul 27 16:33 systemd
srw-rw-rw- 1 jamie jamie 0 Jul 27 16:33 bus
drwx------ 3 jamie jamie 80 Jul 27 16:33 .

After running "sudo apt update && sudo apt full-upgrade" to bring the distro up to date, /run/user looks like this

┌──(jamie㉿DESKTOP-JAMIE)-[~]
└─$ ls -lart /run/user
total 4
drwxr-xr-x 3 root root 4096 Apr 30 22:21 .
drwx------ 3 jamie jamie 80 Jul 27 16:33 1000
drwxr-xr-x 18 root root 520 Jul 27 16:35 ..

┌──(jamie㉿DESKTOP-JAMIE)-[~]
└─$ ls -lart /run/user/1000
total 4
drwxr-xr-x 3 root root 4096 Apr 30 22:21 ..
srw-rw-rw- 1 jamie jamie 0 Jul 27 16:33 bus
drwx------ 3 jamie jamie 80 Jul 27 16:33 .
drwxr-xr-x 5 jamie jamie 140 Jul 27 16:35 system

I then run "code ." in one of my project folders. VS Code Server updates itself to f1e16e1e6214d7c44d078b1f0607b2388f29d729 and i get the "couldn't create connection to server" errors. At this point /run/user looks like

┌──(jamie㉿DESKTOP-JAMIE)-[~/dev/projects/scratch]
└─$ ls -lart /run/user
total 8
drwx------ 2 root root 4096 Apr 30 22:21 1000
drwxr-xr-x 3 root root 4096 Apr 30 22:21 .
drwxr-xr-x 18 root root 480 Jul 27 16:38 ..

┌──(jamie㉿DESKTOP-JAMIE)-[~/dev/projects/scratch]
└─$ ls -lart /run/user/1000
ls: cannot open directory '/run/user/1000': Permission denied

If i apply the chown and chmod fixes, "sudo chown 1000:1000 /run/user/1000 && sudo chmod 0700 /run/user/1000", restart my distro and relaunch vscode from my project folder, the errors go away.

So, it appears that VS Code Server is causing the problem when it updates. I assume it's removing the /run/user/1000 folder on updating and recreating it with root as the owner.