lua-language-server exhausts available inotify resources

[xaizek]

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

1. Create a dummy config file (return {}) and place it somewhere with many files (e.g. in home directory).
2. Specify path to that config via --configpath like in --configpath=$HOME/lsp.lua.
3. Open some workspace with that configuration (using lsp.vim in Vim9 here, but client shouldn't matter).
4. Try using inotifywait some/file and observe Failed 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

[actboy168]

https://unix.stackexchange.com/questions/13751/kernel-inotify-watch-limit-reached

[xaizek]

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.

[sumneko]

Has been fixed by 7075ca19746addabc66296518a1eeafca8144723

[jmbuhr]

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.

[xaizek]

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.

[jmbuhr]

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.

[xaizek]

You're right. There probably could be just 2 instances in Lua to fix this: one recursive and one non-recursive one.

[xaizek]

Probably a new issue should be created. It's not the same problem, it's a new one created while fixing this issue.

[jmbuhr]

The title of the issue would remain the same, just a slightly different inotify resource.

[alichtman]

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: