Solargraph not starting. Starting the Solargraph server messages never goes away

[jcostello]

When opening a ruby file CocSolargraph tries to start the server but nothing happens. No errors in the log. Config seems to be fine since if I change the path to a wrong one I got an error message

{
  "solargraph.trace.server": "verbose",
  "solargraph.commandPath": "/home/juan/.rbenv/shims/solargraph",
}

This is the coc log

2020-12-04T14:09:27.758 INFO (pid:11406) [services] - registered service "languageserver.godot"
2020-12-04T14:09:28.028 INFO (pid:11406) [plugin] - coc.nvim 0.0.79-67cc18bcbf initialized with node: v10.15.3 after 332ms
2020-12-04T14:09:35.687 INFO (pid:11406) [services] - registered service "solargraph"
2020-12-04T14:09:54.166 INFO (pid:11406) [completion-complete] - Results from: snippets

[lfidnl]

Hello. I've faced up with the same problem. The problem was solargraph didn't start properly. Try to run manually solargraph scan in working directory and you can see the root cause.
In my case it was old bundler, old ruby gems and ruby 2.7.1.
I update bunlder via gem install bundler, gem update --system and add this to coc-config.json (may be it is not necessary):

{
... 
  "solargraph.useBundler":false,
  "solargraph.bundlerPath":"/home/user/.rvm/gems/ruby-2.7.1/gems/bundler-2.2.1/exe/bundler",
  "solargraph.commandPath":"/home/user/.rvm/gems/ruby-2.7.1/wrappers/solargraph"
...
}

I hope it will be helpful

[anchorite]

In my case it was misconfigured rbenv - it wasn't initialized for non-interactive bash login sessions. The plugin tries to start solargraph using bash -l -c and it was failing as the shims provided by rbenv were unavailable.

In my case it was easy to see that bash -l -c env was showing PATH without rbenv and its shims.

[himat]

I'm still facing this issue.

I tried solargraph scan but it shows no errors

❯ solargraph scan
The dependency tzinfo-data (>= 0) will be unused by any of the platforms Bundler is installin
g for. Bundler is installing for ruby but the dependency is only for x86-mingw32, x86-mswin32
, x64-mingw32, java. To add those platforms to the bundle, run `bundle lock --add-platform x8
6-mingw32 x86-mswin32 x64-mingw32 java`.
Scanned /Users/x/Workspace/zzz (4368 pins) in 5.545418999972753 secon
ds.

I'm running my project inside rvm with rvm use 2.7.2. Is there something coc setting I need to set to make sure coc can properly call solargraph inside rvm?

[himat]

Ok I've found that the command coc is running is /usr/local/bin/zsh -l -c cd /Users/x/Workspace/zzz && solargraph socket --port 0

But it seems that the issue for me is that if I run just the first part, there's some kind of infinite loop parse error:

❯ /usr/local/bin/zsh -l -c cd /Users/x/Workspace/zzz
(eval):1: parse error near `()'
(eval):1: parse error near `()'
(eval):1: parse error near `()'
(eval):1: parse error near `()'
(eval):1: parse error near `()'
(eval):1: parse error near `()'
(eval):1: parse error near `()'
(eval):1: parse error near `()'
(eval):1: parse error near `()'
(eval):1: parse error near `()'
(eval):1: parse error near `()'
(eval):1: parse error near `()'
(eval):1: parse error near `()'
(eval):1: parse error near `()'
(eval):1: parse error near `()'
(eval):1: parse error near `()'
(eval):1: parse error near `()'
(eval):1: parse error near `()'
(eval):1: parse error near `()'
(eval):1: parse error near `()'
(eval):1: parse error near `()'
(eval):1: parse error near `()'
(eval):1: parse error near `()'
(eval):1: parse error near `()'
...<repeats infinitely>

Would this be some issue in my ~/.zshrc?

But it doesn't make sense to me since if I run just /usr/local/bin/zsh -l it enters into the shell just fine.
And if I run just /usr/local/bin/zsh -c cd /Users/x/Workspace/zzz && solargraph socket --port 0 this also works fine.

It seems that it's the combination of the -l and -c <cmd> flags that makes it have a parse error for some reason.

[himat]

So actually turns out that it's some issue with running zsh -x -l -c "echo hi" within a ruby rvm environment. If I run it in a directory that's not in a ruby rvm then this infinite loop doesn't happen.
But I have no idea how to fix it.

[himat]

Ok I fixed it - I think rvm somehow added a line to source its scripts automatically in a ~/.zlogin file, and after I removed the sourcing line there it's fixed now.

[kidonchu]

Ok I've found that the command coc is running is /usr/local/bin/zsh -l -c cd /Users/x/Workspace/zzz && solargraph socket --port 0

@himat I'm kind of having similar issue as you are. How did you find out the actual command coc is running?

[anchorite]

@kidonchu, execsnoop tool from bcc utils shows all executed commands in the system. Btw there are other useful debugging tools in this repository.

[himat]

@kidonchu run top or htop to see the running command while the solargraph server is trying to start

[johnpitchko]

Running into the same issue here; Starting the Solargraph language server just spins forever.

Using rbenv. Tried @anchorite's solution, but running zsh -l -c env shows that the /Users/x/.rbenv/shims is on the PATH.

Investigated @himat 's solution but I do not have a .zlogin file.

Adding 'Solargraph.diagnostics': true in the coc-settings.json file did not display any messages.

[Samuelfaure]

Having the same issue, zsh -l execute the contents in my .zprofile, which opens a whole new Sway server & also prevents solargraph server from ever opening.

I'm not a terminal wizard but I'm not certain Coc-solargraph should execute zsh with the option -l ? Does it really make sense?

Edit: related issue #62

Fixed the issue by adding this in my vim config init.rb:

call coc#config('solargraph.shell', '/bin/sh')

That way the .zprofile is not executed and solargraph can launch. I'm still wondering if this is normal practice to use zsh -l in that situation...