As of 19/1/2018 (maybe earlier):
Extension says no rls installed, do I want to install. This is strange as rls is installed (via rustup) in cargo bin.
Couldn't start client Rust Language Server
ErrorCould not install RLS component (rls)
VSCode:
Version 1.19.2
Commit 490ef761b76b3f3b3832eff7a588aac891e5fe80
Date 2018-01-10T15:55:03.538Z
Shell 1.7.9
Renderer 58.0.3029.110
Node 7.9.0
Architecture x64
Rust installed via rustup -
toolchains installed:
stable-x86_64-pc-windows-gnu
stable-x86_64-pc-windows-msvc
beta-x86_64-pc-windows-msvc
nightly-x86_64-pc-windows-gnu
nightly-x86_64-pc-windows-msvc (default)
Uninstalled the plugin and reinstalling has no effect. Nothing about Rust or RLS in logs.
Not sure exactly what is wrong or how to diagnose more.
What's your rustc --version and Rust (rls) extension version?
rustc 1.25.0-nightly (15a1e2844 2018-01-20)
typing
rls --version
results in
error: toolchain 'nightly-x86_64-pc-windows-msvc' does not have the binary rls.exe
Even though I run it from the folder rls is installed in (.cargo/bin)
Vs Code plugin version Is 0.3.2
You’re saying that RLS is installed via rustup - what does ‚rustup
component add rls-preview’ say?
The component changed its name some time ago, maybe you have the old
component installed?
On Sun, 21 Jan 2018 at 17:27, Neil Danson notifications@github.com wrote:
Vs Code plugin version Is 0.3.2
—
You are receiving this because you commented.Reply to this email directly, view it on GitHub
https://github.com/rust-lang-nursery/rls-vscode/issues/237#issuecomment-359260607,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC8y3UI7UNfECwqqOOZT2yLx9BexQLuuks5tM2VagaJpZM4Rl0bP
.
It says
info: component 'rls-preview' for target 'x86_64-pc-windows-msvc' is up to date
I uninstalled all gnu toolchains so that it was clearer what Rust (rls) would be using
Now I get
"The Rust Language Server server crashed 5 times in the last 3 minutes. The server will not be restarted."
Hm, that's weird. Would you mind setting a RUST_LOG env var to something like rls=trace,rls_analysis=error and then rerun VSCode? It should give more info about what RLS does and why it's crashing, the err output should be under Output > Rust Language Server window.
I'm on Windows and having this issue. RLS itself seems to be fine, but the VS Code extension isn't detecting it. Setting those environment variables doesn't seem to have added anything to the output log.
The specific order of events is:
[Error - 4:48:59 PM] Starting client failedI was experiencing this issue as well. For what it's worth, when looking in my settings rust-client.channel was defaulted to nightly. Switching it to stable fixed the issue.
(In fact, setting RUST_LOG=rls=trace,rls_analysis=error did nothing for me either, the output panel still read "Starting client failed." Only after switching to stable did the trace output appear.)
Setting "rust-client.channel": "stable" in VS Code user settings worked for me too. Thanks!
Perhaps rls-vscode should handle this the same way the atom plugin does: finding the latest dated channel release with RLS and installing that for them (taken from https://github.com/rust-lang-nursery/rls/issues/677#issuecomment-360071755).
I'm on windows, getting the same error even after setting the "rust-client.channel" to stable. No output at all from the extension that I can find.
Changing to stable worked for me.
Sorry, the problem isn't that RLS can't be installed, it's that every time I run Code it says that "Info: RLS is not installed. Install?", if I don't press 'yes' then it says RLS can't be started. If I do press 'yes' then it toils away in the background for a while and after this RLS is available.
I met "The Rust Language Server server crashed 5 times in the last 3 minutes. The server will not be restarted." this problem, too.
VS Code 1.19.3 7c4205b5c6e52a53b81c69d2b2dc8a627abaa0ba
Rust (rls) 0.3.2
Default host: x86_64-pc-windows-msvc
installed toolchains
--------------------
stable-x86_64-pc-windows-msvc
nightly-x86_64-pc-windows-msvc
active toolchain
----------------
stable-x86_64-pc-windows-msvc (default)
rustc 1.23.0 (766bd11c8 2018-01-01)
I figured out at least one aspect of this.
Once I set "rust-client.channel": "stable" in my user settings (which I had no idea I had to do until I noticed a mention of it in this thread), I continued to get the same behavior in my own project (an erroneous "RLS is not installed" message, and no working RLS). Then I tried it on a different project and it actually worked. My normal project has workspace Cargo.toml. I think this is just yet another failure of RLS to support Cargo workspaces.
So workspace mode is on by default on nightly and off by default on stable, so that might be a cause?
I have the same issue on my VSCode, I am running the RLS plugin 0.4.5 and my rust version is rustc 1.26.1 (827013a31 2018-05-25). I have added "rust-client.channel": "stable", to my user settings file in vscode. And I am using this on High Sierra running MacOS. Does anyone have any updates on this one ?
@ormrepo could you try using nightly RLS and see if that works please?
Hi Nrc sorry for the delay in replying. I have installed the nightly build as per the attached screenshot. And I still receive the same error as per the other screenshot. I am using vscode 1.2.1


Are you aware of any other workarounds or any other rls type plugins on vscode ?
1.2.1 is very old, I think current VSCode is 1.24. I think this error is because you don't have rustc in a path that VSCode can see. Can you run rustc from the command line?
Hi nrc, Thanks for responding, I am running VSCode 1.24 as shown in the screenshot and I can run rustc from the command line see the other screenshot.


Can you run rustup from the command line? It looks like you are using a path to run Rust. The RLS needs to be able to find rustup without using the full path, so it needs to be in your $PATH env var. Hope that works.
Hi, nrc thanks for getting back to me. I can run rust from the command line. As shown in the screenshot below.

However, I note that you mentioned something about my $path I have attached another screenshot showing the top of my bash profile and there isnt anything in there relating to rust. I am new to rust as you may know and I would appreciate it if you could let me know the line I need to add to my bash profile that is necessary to get this working ?

Thanks
It looks like you're running rustup with rustup, not ~foo/rustup or something so you should be fine.
I don't know anything else to try. The best bet is probably to try and debug it yourself - pull this repo and open it in VSCode, in rustup.ts you should be able to find the error messages you're getting. Set breakpoints and see if you can get any more information about the errors.
Running into this on not one, but two Windows 10 machines with entirely fresh installs of the stable Rustup release. Components are verified to be correctly installed. Paths are correct. Starting up RLS manually from a console/bash terminal work.
Trying to start this extension gives me "Error starting up rls" in a popup with no additional information.
Just wanted to make sure people are aware this is still happening, I'm getting @jeremyong 's problem too.
cc @Xanewok this might be a good place to add facility to get more info in the event of an error
It just started happening with me as well. How would reset it so it will at least attempt to run again?
It happens to me too!
I'm also having this problem on Windows 10 running Visual Studio Code version 1.31.1, with the Rust(rls) extension version 0.5.3.
I've also noticed that none of my integrated terminals within VSCode are picking up the path to the cargo install directory.
Running the following from a powershell window outside of VSCode produces output
echo $Env:Path | select-string cargo
while running it from inside the integrated terminal produces nothing. I have restarted VSCode and rebooted the computer too, but I'm sure this is related to the issue at hand somehow.
edit:
VS Code terminals now correctly pick up rust in the path (who knows why), but RLS still produces errors on startup. However, RLS will intermittently start. I don't know what the difference between a successful startup and failed one is.
I encountered this problem after attempting to use vs code with newly installed Rust via rustup on Windows 10. After getting the "RLS could not be started" error popup, I popped open the vs code developer console, and saw that the problems all seemed to start with this error:
console.ts:134 [Extension Host] Detected active channel: stable-x86_64-pc-windows-msvc (default) (since 'rust-client.channel' is unspecified)
console.ts:134 [Extension Host] Error getting sysroot from `rustc`: Error: Command failed: rustup run stable-x86_64-pc-windows-msvc (default) rustc --print sysroot
error: toolchain 'stable-x86_64-pc-windows-msvc (default)' is not installed
Sure enough, explicitly setting rust-client.channel in settings.json lets RLS start up as expected. So my guess is the problem is that detecting the active channel is mistakenly getting the active _toolchain_, not channel, and then every future command where it tries to use the "channel" naturally fails.
FYI, I was experiencing this issue on VSCode as well, the rust-client.channel option set to stable also resolved the issue for me.
Happen to me as well on VSCode MacOS. Same fix for vanilla rust installation
Just started having the same issue. will try the rust-client.channel thing. If it helps any it started only after I assigned an override to a directory of the nightly toolchain. But it broke with every other project as well. Was working perfectly fine before this.
even after unsetting the override in the directory the problem persists.
The most recent problem should be fixed with 0.5.4. In the future, we need to better tell the user what's wrong, but for now I'll close this issues since it's gotten too big and too broad now. Thanks everyone for sharing their fixes :100:
With everything up to date and rust(rls) extension 0.5.4 still get the error "Could not install RLS component (rls-preview)" on windows 10. Can run from vc terminal and windows cmd rustup and rustc commands from anywhere so path is set correctly.
EDIT 30. September 2019:
This issue still keeps on appearing when new Rust versions get released. I can always solve this simply by doing the following:
$ rustup update
$ cargo clean
$ cargo check && cargo build
This method works for me every time.
Original comment:
I ran into this issue, too. What worked for me:
1.) Delete everything in ~/.rustup/ (which removes toolchains, defaults, components and overrides)
$ rm -rf ~/.rustup/*
2.) Install toolchain, set default, install components
$ rustup install stable
$ rustup default stable
$ rustup component add rls rust-analysis rust-src
3.) Uninstall Rust (rls) plugin in VSCode, restart VSCode, install the plugin, close VSCode
4.) Run cargo check && cargo build && cargo doc on respository
5.) Open VSCode again -> RLS is building
I ran into this issue, too. What worked for me:
1.) Delete everything in
~/.rustup/(which removes toolchains, defaults, components and overrides)
$ rm -rf ~/.rustup/*2.) Install toolchain, set default, install components
$ rustup install stable
$ rustup default stable
$ rustup component add rls rust-analysis rust-src3.) Uninstall Rust (rls) plugin in VSCode, restart VSCode, install the plugin, close VSCode
4.) Runcargo check && cargo build && cargo docon respository
5.) Open VSCode again -> RLS is building
still cant work for me

This is happening for me after adding a new crate, any fixes?
It keeps showing RLS [building]...
The same thing happens to me.
Environment
$ rustup --version; rustc --version; rls --version
Wed Jul 24 22:47:29 DST 2019
rustup 1.18.3 (435397f48 2019-05-22)
rustc 1.36.0 (a53f9df32 2019-07-03)
rls 1.36.0 (9692ca8 2019-05-18)
Symptoms
The visual symptoms are the same as in the graphic @nshen posted: the same two notices, plus the infinite spinner for "RLS Starting".
Hypothesis
Could it be that the Rust (rls) extension does not know about WSL, and is looking for executables named i.e. rls.exe and rustup.exe?
This continues to happen for me on Mac. Infinitely spinning with "RLS Starting." Every time I try to re-install, it tells me it can't find RLS and it can't find Rustup. Both are in ~/.cargo/bin. I have deleted the entire contents of .rustup and set the channel in the configuration to "stable" per suggestions in this issue. Neither has had any impact.
$ rustup --version; rustc --version; rls --version
rustup 1.18.3 (435397f48 2019-05-22)
rustc 1.36.0 (a53f9df32 2019-07-03)
rls 1.36.0 (9692ca8 2019-05-18)
I'm going to pile on with an example of VS Code (1.36.1 x64) on Linux (Mint).
I have tried numerous ways of setting and confirming I can get expected RLS output in Terminal (bash), but I continue to see errors from the extension.
bryan@Linux-Mint:~/repo/rust_variables$ rls --version
rls 1.36.0 (9692ca8 2019-05-18)
The Rust Language Server server crashed 5 times in the last 3 minutes. The server will not be restarted.
See also my comment in this issue, for my comments on logging not working as expected / needed.
~Can we please re-open this issue?~
I have just tested what's causing the problem.
I'm using vscodium under Debian testing and the problem seems to be the shell script that is located in bin directory of vscod(e|ium).
Inside my vscodium directory I have the executable named codium, in your case should be code, and if you execute that one, everything works as expected.
If you run the script version that is found in vscod(e|ium)/bin, then you get this problem.
UPDATE: I forgot to mention that I have added a symlink in my $HOME/bin/ and named it vscodium for the sake of personal convenience.
The current workaround is the following:
/PortableApps/vscodium/codium; as soon as RLS starts, close the editor./PortableApps/vscodium/bin/codium; now it should start. If it doesn't, give it another try.vscodium.It's an interesting issue, I have to admit.
UPDATE #2: When I attempt to start the editor via Application Finder (I use XFCE4), it loads the last opened folder / project of mine; with this method, RLS it does not work.
Now, if I go via terminal to the actual location where the folder is located and execute vscodium . to load the desired folder, everything works as expected without a problem.
I hope this helps in any way.
I'm seeing the same issue on Debian Linux amd64, not sure how it broke since it used to work.
[Error - 00:21:56] Starting client failed
Error: Command failed: rustup toolchain list
/bin/sh: 1: rustup: not found
at ChildProcess.exithandler (child_process.js:303:12)
at ChildProcess.emit (events.js:200:13)
at maybeClose (internal/child_process.js:1021:16)
at Socket.<anonymous> (internal/child_process.js:430:11)
at Socket.emit (events.js:200:13)
at Pipe.<anonymous> (net.js:586:12)
In the command line the same works:
eddy@aptonia:~/usr/src/uCautomation/plant-watering-system/water_system/generomst $ rustup toolchain list
stable-x86_64-unknown-linux-gnu (default)
nightly-2018-01-09-x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu
avr-toolchain
In vscode I get these errors:
Rustup not available. Install from https://www.rustup.rs/
Couldn't start client Rust Language Server
I start vscode with a shortcut which calls vscode directly:
/home/eddy/opt/VSCode-linux-x64/bin/code
Versions are:
eddy@aptonia:~/usr/src/uCautomation/plant-watering-system/water_system/generomst $ rustc --version; rustup --version
rustc 1.42.0 (b8cedc004 2020-03-09)
rustup 1.21.1 (7832b2ebe 2019-12-20)
VSCode version info:
Version: 1.41.1
Commit: 26076a4de974ead31f97692a0d32f90d735645c0
Date: 2019-12-18T15:04:31.999Z
Electron: 6.1.5
Chrome: 76.0.3809.146
Node.js: 12.4.0
V8: 7.6.303.31-electron.0
OS: Linux x64 4.9.0-11-amd64
I'm seeing the same issue on Debian Linux amd64, not sure how it broke since it used to work.
[Error - 00:21:56] Starting client failed Error: Command failed: rustup toolchain list /bin/sh: 1: rustup: not found at ChildProcess.exithandler (child_process.js:303:12) at ChildProcess.emit (events.js:200:13) at maybeClose (internal/child_process.js:1021:16) at Socket.<anonymous> (internal/child_process.js:430:11) at Socket.emit (events.js:200:13) at Pipe.<anonymous> (net.js:586:12)
I think at fault is the fact sh incorrectly called, skipping the $PATH initialization:
eddy@aptonia:~/usr/src/uCautomation/plant-watering-system/water_system/generomst $ ls -l $(which sh)
lrwxrwxrwx 1 root root 4 ian 24 2017 /bin/sh -> dash
eddy@aptonia:~/usr/src/uCautomation/plant-watering-system/water_system/generomst $ $(which sh) "rustup toolchain list"
/bin/sh: 0: Can't open rustup toolchain list
eddy@aptonia:~/usr/src/uCautomation/plant-watering-system/water_system/generomst $ $(which sh) -c "rustup toolchain list"
stable-x86_64-unknown-linux-gnu (default)
nightly-2018-01-09-x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu
avr-toolchain
I'm seeing the same issue on Debian Linux amd64, not sure how it broke since it used to work.
```
[Error - 00:21:56] Starting client failed
Error: Command failed: rustup toolchain list
/bin/sh: 1: rustup: not found
The issue - and solution - to this (at least, in my case), was that the default path to rustup was incorrectly set in the extension. This is resolved by manually editing the path, as per this issue: https://github.com/rust-lang/rls-vscode/issues/622#issuecomment-561596264
EDIT 30. September 2019:
This issue still keeps on appearing when new Rust versions get released. I can always solve this simply by doing the following:
- Close VSCode.
$ rustup update $ cargo clean $ cargo check && cargo build
- Open VSCode -> RLS starts immediately.
This method works for me every time.
Original comment:
I ran into this issue, too. What worked for me:1.) Delete everything in
~/.rustup/(which removes toolchains, defaults, components and overrides)
$ rm -rf ~/.rustup/*2.) Install toolchain, set default, install components
$ rustup install stable
$ rustup default stable
$ rustup component add rls rust-analysis rust-src3.) Uninstall Rust (rls) plugin in VSCode, restart VSCode, install the plugin, close VSCode
4.) Runcargo check && cargo build && cargo docon respository
5.) Open VSCode again -> RLS is building
in 2021 now. Thanks for the help. This got rls working for me in vscode
FYI, in VSCode many folks have been moving to the rust-analyzer
FYI, in VSCode many folks have been moving to the rust-analyzer
I can vouch for this. Switched to rust-analyzer a few months ago and it works much better.
@bluejekyll @lamafab Thanks for the tip. Im on rust-analyzer now.
Most helpful comment
I was experiencing this issue as well. For what it's worth, when looking in my settings
rust-client.channelwas defaulted to nightly. Switching it tostablefixed the issue.(In fact, setting
RUST_LOG=rls=trace,rls_analysis=errordid nothing for me either, the output panel still read "Starting client failed." Only after switching to stable did the trace output appear.)