DEV Community

Stephen Charles Weiss
Stephen Charles Weiss

Posted on • Originally published at stephencharlesweiss.com on <time datetime="2019-09-24T12:22:05Z" class="date">Sep 24, 2019</time>

Running VSCode On Linux: Hitting My Watcher Limit And What To Do About It

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_watches

When 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 -p

If you like to make your limit permanent, use:

$ echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf

$ sudo sysctl -p

You 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

Discussion (14)

Collapse
katafrakt profile image
Paweł Świątkowski

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.

Collapse
oof2win2 profile image
oof2win2

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.

Collapse
stephencweiss profile image
Stephen Charles Weiss Author

100% agree with this. At the time, however, I needed the hack and an ability to see my changes.

Collapse
therealkevinard profile image
Kevin Ard

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

Collapse
tkdmzq profile image
TKDMzq • Edited on

Yea ist main suspect. But how would vs code know if we installed new module to get exports from it?

Collapse
therealkevinard profile image
Kevin Ard

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)

Collapse
lesha profile image
lesha 🟨⬛️

trillion files in my node_modules

 w h a t

Collapse
therealkevinard profile image
Kevin Ard

Rough estimate 😉

(But... Now I'm absolutely going to run a file count on my node_modules when I get back to the office)

Thread Thread
therealkevinard profile image
Kevin Ard

Update:

❯ find . -type f | grep node_modules | wc -l
412140

But, to be fair: That's from a pretty large project with several microservice modules in it.

Collapse
codingsafari profile image
Nico Braun

You can additionally exclude stuff. I have the below in my settings.json

"files.watcherExclude": {
    "**/.git/objects/**": true,
    "**/.git/subtree-cache/**": true,
    "**/node_modules/*/**": true,
    "**/package-lock.json": true,
    "**/yarn.lock": true,
    "**/dist/*/**": true,
    "**/vendor/*/**": true,
    "**/dist_electron/**": true,
},
Collapse
lairdstreak profile image
laird.streak

You can also add ignore folders and files in your settings file ignoring the virtual environment and folders such as .git will help.

Collapse
twitmyreview profile image
Priyab Dash

Thanks for sharing this no e hack I am planning to use a Linux VM soon for my Dev work, will use your hack

Collapse
codingsafari profile image
Nico Braun

It's not a hack. That's day to day work on Linux. It's just another setting.

Collapse
lehu profile image
le-hu

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.