search

neovim / nvim-lspconfig

Quickstart configs for Nvim LSP
Apache License 2.0
10.82k stars 2.1k forks source link

Multiple instances of lua-language-server (sumneko_lua) are running when I open a single file #319

Closed ahmedelgabri closed 3 years ago

ahmedelgabri commented 4 years ago

Features: +acl +iconv +tui See ":help feature-compile"

system vimrc file: "$VIM/sysinit.vim" fall-back for $VIM: "/usr/local/Cellar/neovim/HEAD-1869f86/share/nvim"

Run :checkhealth for more info


- nvim-lsp version(commit hash): `3f72236`

- `:checkhealth`

health#targets#check

health#nvim_lsp#check

Checking language server protocol configuration

health#gitmessenger#check

health#completion_nvim#check

general

completion source

snippet source

health#nvim#check

Configuration

Performance

Remote Plugins

terminal

tmux

health#provider#check

Clipboard (optional)

Python 2 provider (optional)

Python 3 provider (optional)

Python virtualenv

Ruby provider (optional)

Node.js provider (optional)

Perl provider (optional)

How to reproduce the problem from neovim startup

Open any .lua file, in my case it's this file https://github.com/ahmedelgabri/dotfiles/blob/e71e9ac3d319cc0af909e7156212ae445de27a10/roles/vim/files/.vim/lua/lsp.lua

Actual behaviour

Screenshot 2020-08-09 at 17 02 51 Screenshot 2020-08-09 at 17 01 05

Expected behaviour

justinmk commented 4 years ago

I seem to recall @norcalli mentioning that sumneko server had various problems. Maybe he can comment on his current setup for Lua LSP

ruifm commented 4 years ago

I'm having the same issue

p00f commented 3 years ago

They don't shut down after closing neovim too

elianiva commented 3 years ago

I think this has been improved since then? I never experienced it anymore and they always shut down after closing Neovim. I also tried to open 4 files and it only launch 1 instance of lua-language-server. Though, the LSP sometimes uses a ton of my CPU but it never locks my Neovim, it's still usable. After several seconds, it went back to normal.

mjlbach commented 3 years ago

I personally haven't noticed this in awhile, I also feel like this is an upstream issue and we can't/shouldn't try to implement more advanced process management for language servers that refuse a shutdown command. The only thing we could try to do is store the PID and pkill it when it fails, but if the language server crashes (as they do), I don't know that we can reliably identify that and not fill whatever process ends up using the same PID.

ahmedelgabri commented 3 years ago

I didn't notice this happening either for a while & after merging this #498 I don't think it makes sense to keep this open anymore.

mjlbach commented 3 years ago

Unfortunately a lot of bugs seem to be caused by having older language servers, and before when we were managing installs via neovim they would become rather out of date 😞 I'm glad sumneko seems to be working now!

nyngwang commented 2 years ago

@mjlbach Thanks for all of you!

eo1989 commented 2 years ago

Apologies to pull this back up, but this issue is still lurking. It also occurs with Null-ls and Pyright. Im running sumneko_lua (via brew) 2.6.7 and still have the multiple-spawn issue occurring. Anytime I open new files within the same directory, or a same project, a new LSP is spawned. The picture is much like the two posted beforehand.

kyleerhabor commented 2 years ago

I've been experiencing the same issue, except a new LSP is spawned whenever the file is written to (e.g. :w).

ssipos90 commented 2 years ago

yep, it still happens to me too. If I work on my lua config, my RAM gets full in 10 minutes and OOM killer triggers.

ssipos90 commented 2 years ago

I found out it's because of single_file_support = true, which is the default. If you set it to false, the language server will start only in lua projects, but only one instance of the server will be present.

To set the neovim config as a lua project, I ran $ echo "{}" > ~/.config/nvim/.luarc.json.

Setting single_file_support to false means that you can't open your neovim config from anywhere, you'd need to cd into ~/.config/nvim (either before or from within neovim) for the project to be detected, otherwise lua language server won't start.

histeward commented 2 years ago

:lua vim.lsp.stop_client(vim.lsp.get_active_clients())

This command got rid of the multiple instances for me. It's just a temporary workaround to get rid of the instances while working on the Lua file.

Multiple instances occurred when I sourced my lsp config file.

Aaron-von-Awesome commented 2 years ago

:lua vim.lsp.stop_client(vim.lsp.get_active_clients())

This command got rid of the multiple instances for me. It's just a temporary workaround to get rid of the instances while working on the Lua file.

Multiple instances occurred when I sourced my lsp config file.

Thank you for your tip @histeward !

I ended up using this key map in my init.lua, so I can reload my settings quickly and avoid multiple LSP servers for the same file type from running:

vim.keymap.set("n", "<leader><CR>", ":execute 'lua vim.lsp.stop_client(vim.lsp.get_active_clients())' | luafile ~/.config/nvim/init.lua<CR>", {noremap = true})
anthony-S93 commented 2 years ago

It's still happening, @ahmedelgabri

I myself discovered this issue today while I was trying to set up nvim-lspconfig. If you add packer.nvim's autocommand to your plugin specification file and run :LspInfo after saving the file, you will notice multiple instances of sumneko_lua being attached to that buffer. It's annoying because it causes the autocomplete suggestions to duplicate and take up computer resources.

But because all my plugin configurations are inside packer.nvim's plugin specification file (plugins.lua), I managed to solve this by adding a small chunk of logic that would skip the setup() call for sumneko_lua if there is already an instance of it attached to the buffer.

Here's what it would look like in your plugins.lua file: 

vim.cmd([[
      augroup packer_user_config
          autocmd!
          autocmd BufWritePost plugins.lua source <afile> | PackerCompile
      augroup end
  ]])

...Your other config...

--Setting up language servers
local lspconfig = require("lspconfig")
local start_sumneko_lua = true --boolean defaults to true, otherwise, the server will never start
local current_buf_id = vim.api.nvim_get_current_buf()
local servers_attached_to_current_buf = vim.lsp.get_active_clients({bufnr = current_buf_id})

for _, server in ipairs(servers_attached_to_current_buf) do
    if server.name == "sumneko_lua" then --an instance of sumneko_lua is already attached to the buffer
        start_sumneko_lua = false 
    end
end

--After that, all you have to do is to wrap sumneko lua's setup() call inside a conditional using the boolean

if start_sumneko_lua then
    lspconfig.sumneko_lua.setup{
         -- yada yada yada
    }
end

--Other servers don't need this, so their setup can be called as usual
lspconfig.pyright.setup{

}

--yada yada yada...

The idea is to wrap an if-conditional around the lspconfig.sumneko_lua.setup() call and then decide whether or not to start the language server based on a "flag." Turning off single_file_support is certainly a quick and dirty way to make this issue go away, but sometimes we need single_file_support as well. If that's what you need, then this is one way to do it. I've tested it on my setup and haven't run into issues so far. The code seems to be working fine for now.

nyngwang commented 2 years ago

In my case, a new sumneko_lua LSP client is spawned on different root directory, even with the single_file_support set to true(this is set upon nvim-lspconfig):

update: My temporary fix just for my dotfiles(~/.config, as 90% of the time we spent on it, Oops) is:

local util = require('lspconfig.util')
local root_files = {
  '.luarc.json',
  '.luacheckrc',
  '.stylua.toml',
  'stylua.toml',
  'selene.toml',
  'init.lua', -- adding this line
}

M = {
  -- copy-paste from https://github.com/neovim/nvim-lspconfig/blob/master/lua/lspconfig/server_configurations/sumneko_lua.lua
  root_dir = function (fname)
    local root = util.root_pattern(unpack(root_files))(fname)
    if root and root ~= vim.env.HOME then
      return root
    end
    return util.find_git_ancestor(fname)
  end,
  -- ...
}