Error spawning child process ENOENT

[mdeabreu]

• code-server version: 1.621
• OS Version: Docker 18.09.04 build d14af54266 on Digital Ocean Ubuntu 18.04 1Gb ram

Description

After installing the Rust (rls) extension and opening a rust source file the rustup process fails to spawn as a child process. I believe this can occur in other cases when trying to spawn a child process but this is the easiest one to reproduce.

[Error - 15:49:11] Starting client failed
Error: spawn rustup ENOENT
	at Process.ChildProcess._handle.onexit (internal/child_process.js:190:19)
	at onErrorNT (internal/child_process.js:362:16)
	at _combinedTickCallback (internal/process/next_tick.js:139:11)
	at process._tickCallback (internal/process/next_tick.js:181:9)

Steps to Reproduce

1. Launch code-server inside Docker using the following command (same as in the readme): docker run -it -p 127.0.0.1:8443:8443 -v "${PWD}:/home/coder/project" codercom/code-server:1.621 --allow-http --no-auth.
2. Search for "rust" in the Extensions pane, and install the Rust (rls) extension.
3. Create a new file in your project titled hello.rs.
4. Open the newly created rust source file.
5. You will see error notifications and when looking at the Output window you will be able to see the error message.

[foresthoffman]

@mdeabreu Thanks for this! Do you have rustup and rustc installed and accessible via the PATH environment variable?

[mdeabreu]

For the repro steps I did not install those (I realize now that was a mistake and it should be installed). That being said I do have a code-server running that has both rustup and rustc installed and accessible in the PATH.

coder@83e8ec3d2161:~/project$ cargo new hello
     Created binary (application) `hello` package
coder@83e8ec3d2161:~/project$ cd hello
coder@83e8ec3d2161:~/project/hello$ cargo run
   Compiling hello v0.1.0 (/home/coder/project/hello)
    Finished dev [unoptimized + debuginfo] target(s) in 0.94s
     Running `target/debug/hello`
Hello, world!
coder@83e8ec3d2161:~/project/hello$ 

For this instance of code-server the /home/coder/.profile has the following lines added

export USER="$(whoami)"
export PATH="$HOME/.cargo/bin:$PATH"

This creates the USER env variable so cargo is happy, and adds the cargo bin directory to the path so that rust/cargo works as expected.

Additionally, by default, the terminals launched by VSCode do not load the .bashrc or .profile files into the environment. To fix that the following had to be added to /home/coder/.local/share/code-server/settings.json

{
    // Linux
    "terminal.integrated.shellArgs.linux": ["-l"]
}

This makes terminals act like logged in bash sessions (https://code.visualstudio.com/docs/editor/integrated-terminal#_shell-arguments)

[mdeabreu]

Took another look at this. Despite settings.json having "terminal.integrated.shellArgs.linux": ["-l"] which should treat all shells as being "logged in" and having the correct path. Extensions do not have the correct PATH variable.

The rls extension is trying to call rustup and rls which should be located at /home/coder/.cargo/bin and this directory should be in the PATH. However extensions do not have the correct PATH and so they can't find rustup.

Work Around

As a workaround for this particular case add the following lines to settings.json

  // Fix rls extension
  "rust-client.rustupPath": "/home/coder/.cargo/bin/rustup",
  "rust-client.rlsPath": "/home/coder/.cargo/bin/rls",

This explicitly tells the extension where to look. But this will not fix this class of problems.

[foresthoffman]

@mdeabreu Interesting. When I take a look at some other requests for rust extensions, i'll look further into this. I believe that I had to do the same with VSCode itself, the last time I tried a Rust extension, so this very well may be a limitation of the extension and not the environment. If you echo $PATH in an integrated terminal is there a difference in the output, when the terminal.integrated.shellArgs.linux setting is set to the default versus ["-1"]?

[mdeabreu]

Interesting, I’ll try running VSCode natively on an Ubuntu machine with the rust plugin and see if I run into the same issue.

Yes, without the "-l" argument for internal shells they don’t act like “logged in” shells and so the path isn’t updated by the profile script. In that case the cargo bin directory is not in the path.

(Apologies for formatting, on mobile)

[sr229]

@mdeabreu Try out v2 and see if this fixes your problem, if it does, feel free to close this.

[sr229]

No response for 26 days already so we'll mark it closed.

[qwertycody]

Reporting back on this issue because this thread helped me, here is what fixed my issues on RHEL...

yum install rust rustc rls