Repository navigation
lua-language-server exhausts available inotify resources #1709
Description
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
Activity
actboy168 commentedon Nov 23, 2022
https://unix.stackexchange.com/questions/13751/kernel-inotify-watch-limit-reached
xaizek commentedon Nov 25, 2022
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 commentedon Jan 31, 2023
Has been fixed by 7075ca1
jmbuhr commentedon Apr 14, 2023
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_instancesis 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 commentedon Apr 14, 2023
The fix was to just not recurse, doesn't look like it could lead to creating more instances.
jmbuhr commentedon Apr 15, 2023
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-infolinked above.xaizek commentedon Apr 15, 2023
You're right. There probably could be just 2 instances in Lua to fix this: one recursive and one non-recursive one.
xaizek commentedon Apr 17, 2023
Probably a new issue should be created. It's not the same problem, it's a new one created while fixing this issue.
jmbuhr commentedon May 1, 2024
The title of the issue would remain the same, just a slightly different inotify resource.
alichtman commentedon Jul 6, 2024
I'm seeing the same behavior described in this issue. Without having
nvimopened to edit mynvimconfig:As soon as I run
$ nvim ~/.config/nvim/lua/core/keymaps.lua, a seemingly insane number of inotify watches are started:[nvim] Fix lua-language-server inotify exhaustion
b0o commentedon Dec 8, 2024
I'm seeing even more ridiculous numbers.
RedEtherbloom commentedon Apr 10, 2025
I'm seeing similar numbers on my end.
Arbel-arad commentedon Oct 26, 2025
i'm also seeing numbers in the 500K+ range
