When to start dnsmasq with systemd

I just started using VSCode version 1.24.1.

After loading a folder, it shows warning

Visual Studio Code is unable to watch for file changes in this large workspace

After i check the limit as suggested on their guide, using

cat /proc/sys/fs/inotify/max_user_watches

I get 8192, while my project has only 650 files (of which 400 are inside .git)

Why does this happen? Is this a bug or am I missing something?

(Increasing the limit is clearly not the right solution.)

what linux ppl dont know, there are ppl new to linux like me. So if you're a noob, this is for you.

1. Open a new terminal.
2. cat /proc/sys/fs/inotify/max_user_watches (might be a number 8k+)

now (a) for vim-Editor

3. (a) sudo vim /etc/sysctl.conf
4. (a) go all the way down and add a new line with: fs.inotify.max_user_watches=524288 (make sure you DONT have a # in front of the command)
5. (a) type :wq! and press enter

or (b) for nano-Editor (thanks to @bradrar)

3. (b) sudo nano /etc/sysctl.conf

4. (b) go all the way down and add a new line with: fs.inotify.max_user_watches=524288 (make sure you DONT have a # in front of the command)

5. (b) type ctrl + x, type y and press enter

6. type sudo sysctl -p
7. type again: cat /proc/sys/fs/inotify/max_user_watches (should be 500k+ now)
8. (thank me later.)

The solution I found and it's work for me is

add this line fs.inotify.max_user_watches=524288 in to /etc/sysctl.conf

and then run the command sudo sysctl -p

and then go to your vscode settings find a file called settings.json

and this line to it

"files.watcherExclude": {
    "**/.git/objects/**": true,
    "**/.git/subtree-cache/**": true,
    "**/node_modules/*/**": true
  }

you can also refer this link https://code.visualstudio.com/docs/setup/linux#_visual-studio-code-is-unable-to-watch-for-file-changes-in-this-large-workspace-error-enospc

The fact that you are out of watches does not mean that its VSCode's fault.

VSCode has for sure issues with excluding directories from watch (on linux) (update: most are recently resolved here, and here)

But since you have counted the files yourself, the error message in this case is probably misleading and some other application has already exhausted watches.

To trace the guilty app you can use this nice script