Having `/etc/nixos` directory on macOS can cause rust-analyzer to assume the OS is nixOS

[jieyouxu]

Info	Version
OS	macOS Catalina 10.15.5 (19F101)
Platform	Darwin 19.5.0 x86_64 i386
VSCode	1.47.3
rust-analyzer VSCode client plugin	0.3.261-nightly

I tried to install rust-analyzer plugin in VSCode on macOS, and I can install the plugin, but can't successfully install the server binary. The culprit seems to be lines 16274 in the production script out/main.js checks the OS type:

// Patching executable if that's NixOS.
if (await fs.promises.stat("/etc/nixos").then(_ => true).catch(_ => false)) {
...

This seems to be generated from the lines
https://github.com/rust-analyzer/rust-analyzer/blob/56ade20380a028026eeb71af2a8a81e37ede7efb/editors/code/src/main.ts#L328-L331

The problem here is that this check for NixOS evaluates to true on my macOS system and it means that it tries to utilize NixOS utilities to patch the server binary, which I don't have, causing server installation failure.

This check is insufficient; it can give a false positive on macOS or other linux distributions, for that matter, if the user has the /etc/nixos directory for whatever reason (like myself), even if the directory is empty. It only looks like it's checking if the directory exists (using fs.stat calls underlying stat(2), and maps ENOENT to false).

I've tried to look for relevant APIs in Node.js docs, but os.platform() doesn't seem to provide sufficient info either (i.e. it might not distinguish between linux distros?).

As discussed by @eternaleye in PR #4555, which introduced this check, a better way may be checking for /etc/os-release, but that file seems to be only available if the user's distribution runs systemd. Maybe a few more checks can make that work.

Alternatively, a really hacky way that might be more accurate may be (assuming that it is gated by a linux-distro check):

const util = require('util');
const exec = util.promisify(require('child_process').exec);

async function is_nixos() {
    // On NixOS, `uname(3)` should give something like 
    // `Linux NixOS 4.9.53 #1-NixOS SMP ...`
    try {
        const { stdout } = await exec('uname -a');
        if (stdout.toLowerCase().contains("nixos")) {
            return true;
        } else {
            return false;
        }
    } catch (e) {
        return false;
    }
}

But I don't have NixOS installed and can't really test it out. (Running it my system gives a false as expected).

[kiljacken]

I might be asking a stupid question, but why would you have a /etc/nixos directory if you're not running NixOS?

[jieyouxu]

That's precisely why it took me a long time to debug this particular issue. I have absolutely no clue 😕 why I have the /etc/nixos directory, and for that matter it was just an empty directory too... Which makes this bug very, very unlikely to trigger...

[kiljacken]

If any of our NixOS users are reading along, could you check if you have a /etc/lsb-release file? It's one of the presumably many standards to check which distribution you're running, and reading it should definitely not cause any false positives, unless someone actively tries.

[killercup]

This is a very weird issue.

If any of our NixOS users are reading along, could you check if you have a /etc/lsb-release file?

Nope:

cat: /etc/lsb-release: No such file or directory

a better way may be checking for /etc/os-release, but that file seems to be only available if the user's distribution runs systemd.

NixOS always has /etc/os-release, so checking for existence + 2nd line there could work:

$ cat /etc/os-release 
NAME=NixOS
ID=nixos
...

[lnicola]

From what I've seen, /etc/lsb-release is less common than /etc/os-release.

Anyway, I don't think it's worth handling this situation. We might add a log message ("NixOS detected, patching binary"), but the main distribution method will be rustup in the future.