lua-language-server
lua-language-server copied to clipboard
LuaLS
lua-language-server exhausts available inotify resources
How are you using the lua-language-server?
Other
Which OS are you using?
Linux
What is the issue affecting?
Other
Expected Behaviour
Using lua-language-server shouldn't consume all available inotify resources.
Actual Behaviour
After opening a project no other application can use inotify, because recursive inotify can try watching too many files (over 125,000 in my case, but depends on the limit).
Reproduction steps
- Create a dummy config file (
return {}) and place it somewhere with many files (e.g. in home directory). - Specify path to that config via
--configpathlike in--configpath=$HOME/lsp.lua. - Open some workspace with that configuration (using
lsp.vimin Vim9 here, but client shouldn't matter). - Try using
inotifywait some/fileand observeFailed to watch some/file; upper limit on inotify watches reached!, which shouldn't happen.
Additional Notes
Watch probably shouldn't be recursive when used in https://github.com/sumneko/lua-language-server/blob/d33debdaa7d8748beef0e0365f0314222006058e/script/provider/provider.lua#L34
Log File
No response
https://unix.stackexchange.com/questions/13751/kernel-inotify-watch-limit-reached
https://unix.stackexchange.com/questions/13751/kernel-inotify-watch-limit-reached
This is an ugly workaround, moreover I have many millions of files in my home tree. No matter what limit I set recursive inotify will exhaust it or will waste resources for nothing (I guess lua-language-server will do something every time some file changes?). It just shouldn't be recursive, should have some small depth limit or a limit on a number of watched files.
I think this created a different, but related problem. The lua-language-server seems to spawn many (in my project 70) instances of the inotify watcher (you can monitor this with https://github.com/mikesart/inotify-info), which then quickly exhausts the limit for those (cat /proc/sys/fs/inotify/max_user_instances is 128 by default). All other processes only spawn one each.
With the stable release before this change (https://github.com/LuaLS/lua-language-server/releases/tag/3.6.4) it correctly spawns only one instance.
I think this created a different, but related problem.
The fix was to just not recurse, doesn't look like it could lead to creating more instances.
Doesn't this line: https://github.com/LuaLS/lua-language-server/blame/7075ca19746addabc66296518a1eeafca8144723/script/filewatch.lua#L44 create a new filewatcher every time a new path is added instead of re-using the existing one? You can check this with inotify-info linked above.
You're right. There probably could be just 2 instances in Lua to fix this: one recursive and one non-recursive one.
Probably a new issue should be created. It's not the same problem, it's a new one created while fixing this issue.
The title of the issue would remain the same, just a slightly different inotify resource.
I'm seeing the same behavior described in this issue. Without having nvim opened to edit my nvim config:
As soon as I run $ nvim ~/.config/nvim/lua/core/keymaps.lua, a seemingly insane number of inotify watches are started:
