I have been working on a Linux VM more recently, and one particularly annoying thing about it (there are a lot of little quirks that are frustrating) was that VSCode couldn’t monitor for changes because it was out of watchers.
Watchers are part of the inotify Linux kernel subsystem1 that extend the filesystem to notice changes and report on those changes to applications listening for them.2
There are, however, a fixed number of watchers, and evidently, my machine’s default (8192) was insufficient to the task.
The fix was relatively straightforward: increase the number of watchers. The guard/listen repo has an informative post on the process. Quoting below3:
The technical details
Listen uses inotify by default on Linux to monitor directories for changes. It’s not uncommon to encounter a system limit on the number of files you can monitor. For example, Ubuntu Lucid’s (64bit) inotify limit is set to 8192.You can get your current inotify file watch limit by executing:
$ cat /proc/sys/fs/inotify/max_user_watchesWhen this limit is not enough to monitor all files inside a directory, the limit must be increased for Listen to work properly.
You can set a new limit temporary with:
$ sudo sysctl fs.inotify.max_user_watches=524288
$ sudo sysctl -pIf you like to make your limit permanent, use:
$ echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf
$ sudo sysctl -pYou may also need to pay attention to the values of max_queued_events and max_user_instances if Listen keeps on complaining
After making those changes, my VSCode was once again able to track my changes, which in turn, meant that the source control features were actually helpful and I didn’t have to use the terminal to see my diffs.
Footnotes
- 1 Words, they’re hard and I’m not sure I know exactly what they all mean.
- 2 inotify - Wikipedia
- 3 Increasing the amount of inotify watchers · guard/listen Wiki · GitHub
Top comments (12)
Actually, having to increase the limit may mean that something is wrong with VSCode or rather one of its plugins. Such as that it monitors node_modules or something.
While increasing the limits helps to hack around the problem, it may actually backfire later. Would be useful to report it somewhere. I remember quite similar discussion about Parcel.
Hiyas. This is the issue that is dealing with the whole amount of file watchers not working properly and watching node_modules directories in multi-root workspaces.
100% agree with this. At the time, however, I needed the hack and an ability to see my changes.
Inotify is kinda awesome, really. The inotifywait cmd exposes an ignore pattern (like gitignore, rsync, etc). It would be GREAT if IDEs let us grab that, too! Preeeety sure, my limit is being reached because of the trillion files in my node_modules lol
Yea ist main suspect. But how would vs code know if we installed new module to get exports from it?
Could always fall-back to the universal polling mechanism (eg check ignored dirs every 3-ish seconds).
Alt, my Intellij has pre- and post-scripts that run after certain commands. Those could exec only after
npm **.This is purely theoretical, though 🤷♀️ (unless someone on here is building the IDEs)
w h a t
Rough estimate 😉
(But... Now I'm absolutely going to run a file count on my node_modules when I get back to the office)
Update:
But, to be fair: That's from a pretty large project with several microservice modules in it.
I had this error trying to run LiveShare once I've added many folders into my workspace, once I've removed 20+ folders from workplace and left only one - the problem disappeared.
Thanks for sharing this no e hack I am planning to use a Linux VM soon for my Dev work, will use your hack
You can also add ignore folders and files in your settings file ignoring the virtual environment and folders such as .git will help.