Vscode: Unable to watch for file changes in this large workspace - not a large workspace.

[jsonsystems]

• VSCode Version: 1.27.2
• OS Version: Ubuntu 18.04 bionic (x86-64)

Steps to Reproduce:

1. Create a basic web project with a node_modules directory which exceeds the limit of file watchers:
2. Recursively count the number of files in the entire project directory using find . -type f | wc -l
3. My project has 44452 files (including directories).
4. Check current limit of file watchers using cat /proc/sys/fs/inotify/max_user_watches
5. Make a note of the watcher limit of 8192
6. Configure Visual Studio code to exclude the node_modules directory using

"files.watcherExclude": {
  "**/node_modules/**": true
}

1. Count files in only node_modules using find node_modules -type f | wc -l
2. Make a note of the file count: 43218
3. Subtract the node_modules file count (43218) from project file count (44452)
4. 44452 - 43218 = 1234
5. 1234 is well within the watcher limit of 8192.
6. If VS Code honours watcherExclude, it must only watch 1234 files.
7. VS Code still complains it's _"Unable to watch for file changes in this large workspace"_.

Does this issue occur when all extensions are disabled?: Yes

[bpasero]

@jackwootton this limit is OS global (as far as I know) so it could be that another program also consumes handles. Does the workspace maybe contain symlinks that point to other folders?

[jsonsystems]

Using ls -alR . | grep ^l to recursively list all symbolic links in the project shows that I do have symbolic links. They're all in node_modules.

cd node_modules
ls -alR . | grep ^l

Yields...

lrwxrwxrwx 1  21 Sep 11 22:25 tsc -> ../typescript/bin/tsc
lrwxrwxrwx 1  26 Sep 11 22:25 tsserver -> ../typescript/bin/tsserver
lrwxrwxrwx 1  21 Sep 11 22:25 tsc -> ../typescript/bin/tsc
lrwxrwxrwx 1  26 Sep 11 22:25 tsserver -> ../typescript/bin/tsserver
lrwxrwxrwx 1  18 Sep 11 22:25 jsesc -> ../jsesc/bin/jsesc
lrwxrwxrwx   1   18 Sep 11 22:25 acorn -> ../acorn/bin/acorn
lrwxrwxrwx   1   26 Sep 11 22:25 ansi-html -> ../ansi-html/bin/ansi-html
lrwxrwxrwx   1   19 Sep 11 22:25 atob -> ../atob/bin/atob.js
lrwxrwxrwx   1   32 Sep 11 22:25 autoprefixer -> ../autoprefixer/bin/autoprefixer
lrwxrwxrwx   1   25 Sep 11 22:25 babylon -> ../babylon/bin/babylon.js
lrwxrwxrwx   1   34 Sep 11 22:25 blocking-proxy -> ../blocking-proxy/built/lib/bin.js
lrwxrwxrwx   1   22 Sep 11 22:25 browserslist -> ../browserslist/cli.js
lrwxrwxrwx   1   61 Sep 11 22:25 build-optimizer -> ../@angular-devkit/build-optimizer/src/build-optimizer/cli.js
lrwxrwxrwx   1   20 Sep 11 22:25 cssesc -> ../cssesc/bin/cssesc
lrwxrwxrwx   1   32 Sep 11 22:25 editorconfig -> ../editorconfig/bin/editorconfig
lrwxrwxrwx   1   15 Sep 11 22:25 errno -> ../errno/cli.js
lrwxrwxrwx   1   29 Sep 11 22:25 escodegen -> ../escodegen/bin/escodegen.js
lrwxrwxrwx   1   30 Sep 11 22:25 esgenerate -> ../escodegen/bin/esgenerate.js
lrwxrwxrwx   1   25 Sep 11 22:25 esparse -> ../esprima/bin/esparse.js
lrwxrwxrwx   1   28 Sep 11 22:25 esvalidate -> ../esprima/bin/esvalidate.js
lrwxrwxrwx   1   28 Sep 11 22:25 handlebars -> ../handlebars/bin/handlebars
lrwxrwxrwx   1   12 Sep 11 22:25 he -> ../he/bin/he
lrwxrwxrwx   1   23 Sep 11 22:25 html-minifier -> ../html-minifier/cli.js
lrwxrwxrwx   1   31 Sep 11 22:25 image-size -> ../image-size/bin/image-size.js
lrwxrwxrwx   1   31 Sep 11 22:25 import-local-fixture -> ../import-local/fixtures/cli.js
lrwxrwxrwx   1   27 Sep 11 22:25 in-install -> ../in-publish/in-install.js
lrwxrwxrwx   1   27 Sep 11 22:25 in-publish -> ../in-publish/in-publish.js
lrwxrwxrwx   1   21 Sep 11 22:25 internal-ip -> ../internal-ip/cli.js
lrwxrwxrwx   1   22 Sep 11 22:25 istanbul -> ../istanbul/lib/cli.js
lrwxrwxrwx   1   25 Sep 11 22:25 jasmine -> ../jasmine/bin/jasmine.js
lrwxrwxrwx   1   19 Sep 11 22:25 jscat -> ../system/bundle.js
lrwxrwxrwx   1   18 Sep 11 22:25 jsesc -> ../jsesc/bin/jsesc
lrwxrwxrwx   1   19 Sep 11 22:25 json5 -> ../json5/lib/cli.js
lrwxrwxrwx   1   25 Sep 11 22:25 js-yaml -> ../js-yaml/bin/js-yaml.js
lrwxrwxrwx   1   22 Sep 11 22:25 karma -> ../karma-cli/bin/karma
lrwxrwxrwx   1   17 Sep 11 22:25 lessc -> ../less/bin/lessc
lrwxrwxrwx   1   22 Sep 11 22:25 loose-envify -> ../loose-envify/cli.js
lrwxrwxrwx   1   32 Sep 11 22:25 miller-rabin -> ../miller-rabin/bin/miller-rabin
lrwxrwxrwx   1   14 Sep 11 22:25 mime -> ../mime/cli.js
lrwxrwxrwx   1   20 Sep 11 22:25 mkdirp -> ../mkdirp/bin/cmd.js
lrwxrwxrwx   1   23 Sep 11 22:25 multicast-dns -> ../multicast-dns/cli.js
lrwxrwxrwx   1   22 Sep 11 22:25 ng -> ../@angular/cli/bin/ng
lrwxrwxrwx   1   36 Sep 11 22:25 ngc -> ../@angular/compiler-cli/src/main.js
lrwxrwxrwx   1   41 Sep 11 22:25 ngsw-config -> ../@angular/service-worker/ngsw-config.js
lrwxrwxrwx   1   44 Sep 11 22:25 ng-xi18n -> ../@angular/compiler-cli/src/extract_i18n.js
lrwxrwxrwx   1   27 Sep 11 22:25 node-gyp -> ../node-gyp/bin/node-gyp.js
lrwxrwxrwx   1   26 Sep 11 22:25 node-sass -> ../node-sass/bin/node-sass
lrwxrwxrwx   1   19 Sep 11 22:25 nopt -> ../nopt/bin/nopt.js
lrwxrwxrwx   1   31 Sep 11 22:25 not-in-install -> ../in-publish/not-in-install.js
lrwxrwxrwx   1   31 Sep 11 22:25 not-in-publish -> ../in-publish/not-in-publish.js
lrwxrwxrwx   1   21 Sep 11 22:25 npm -> ../npm/bin/npm-cli.js
lrwxrwxrwx   1   21 Sep 11 22:25 npx -> ../npm/bin/npx-cli.js
lrwxrwxrwx   1   36 Sep 29 19:09 parser -> ../@babel/parser/bin/babel-parser.js
lrwxrwxrwx   1   22 Sep 11 22:25 pbjs -> ../protobufjs/bin/pbjs
lrwxrwxrwx   1   28 Sep 11 22:25 protractor -> ../protractor/bin/protractor
lrwxrwxrwx   1   52 Sep 11 22:25 purify -> ../@angular-devkit/build-optimizer/src/purify/cli.js
lrwxrwxrwx   1   25 Sep 11 22:25 regjsparser -> ../regjsparser/bin/parser
lrwxrwxrwx   1   16 Sep 11 22:25 rimraf -> ../rimraf/bin.js
lrwxrwxrwx   1   27 Sep 11 22:25 sassgraph -> ../sass-graph/bin/sassgraph
lrwxrwxrwx   1   20 Sep 11 22:25 semver -> ../semver/bin/semver
lrwxrwxrwx   1   16 Sep 11 22:25 sha.js -> ../sha.js/bin.js
lrwxrwxrwx   1   23 Sep 11 22:25 sshpk-conv -> ../sshpk/bin/sshpk-conv
lrwxrwxrwx   1   23 Sep 11 22:25 sshpk-sign -> ../sshpk/bin/sshpk-sign
lrwxrwxrwx   1   25 Sep 11 22:25 sshpk-verify -> ../sshpk/bin/sshpk-verify
lrwxrwxrwx   1   22 Sep 11 22:25 strip-indent -> ../strip-indent/cli.js
lrwxrwxrwx   1   20 Sep 11 22:25 stylus -> ../stylus/bin/stylus
lrwxrwxrwx   1   19 Sep 11 22:25 tree-kill -> ../tree-kill/cli.js
lrwxrwxrwx   1   21 Sep 11 22:45 tsc -> ../typescript/bin/tsc
lrwxrwxrwx   1   33 Sep 11 22:25 tsfmt -> ../typescript-formatter/bin/tsfmt
lrwxrwxrwx   1   22 Sep 11 22:25 tsickle -> ../tsickle/src/main.js
lrwxrwxrwx   1   20 Sep 11 22:25 tslint -> ../tslint/bin/tslint
lrwxrwxrwx   1   22 Sep 11 22:25 ts-node -> ../ts-node/dist/bin.js
lrwxrwxrwx   1   26 Sep 11 22:45 tsserver -> ../typescript/bin/tsserver
lrwxrwxrwx   1   25 Sep 11 22:25 uglifyjs -> ../uglify-js/bin/uglifyjs
lrwxrwxrwx   1   16 Sep 11 22:25 uuid -> ../uuid/bin/uuid
lrwxrwxrwx   1   35 Sep 11 22:25 webdriver-manager -> ../protractor/bin/webdriver-manager
lrwxrwxrwx   1   25 Sep 11 22:25 webpack -> ../webpack/bin/webpack.js
lrwxrwxrwx   1   47 Sep 11 22:25 webpack-dev-server -> ../webpack-dev-server/bin/webpack-dev-server.js
lrwxrwxrwx   1   18 Sep 11 22:25 which -> ../which/bin/which
lrwxrwxrwx  1  33 Sep 11 22:25 detect-libc -> ../detect-libc/bin/detect-libc.js
lrwxrwxrwx  1  20 Sep 11 22:25 mkdirp -> ../mkdirp/bin/cmd.js
lrwxrwxrwx  1  20 Sep 11 22:25 needle -> ../needle/bin/needle
lrwxrwxrwx  1  32 Sep 11 22:25 node-pre-gyp -> ../node-pre-gyp/bin/node-pre-gyp
lrwxrwxrwx  1  19 Sep 11 22:25 nopt -> ../nopt/bin/nopt.js
lrwxrwxrwx  1  12 Sep 11 22:25 rc -> ../rc/cli.js
lrwxrwxrwx  1  16 Sep 11 22:25 rimraf -> ../rimraf/bin.js
lrwxrwxrwx  1  20 Sep 11 22:25 semver -> ../semver/bin/semver
lrwxrwxrwx 1  25 Sep 11 22:25 uglifyjs -> ../uglify-js/bin/uglifyjs
lrwxrwxrwx 1  25 Sep 11 22:25 esparse -> ../esprima/bin/esparse.js
lrwxrwxrwx 1  28 Sep 11 22:25 esvalidate -> ../esprima/bin/esvalidate.js
lrwxrwxrwx 1  14 Sep 11 22:25 mime -> ../mime/cli.js
lrwxrwxrwx 1  20 Sep 11 22:25 semver -> ../semver/bin/semver
lrwxrwxrwx   1   15 Sep 11 22:25 errno -> ../errno/cli.js
lrwxrwxrwx   1   15 Sep 11 22:25 is-ci -> ../is-ci/bin.js
lrwxrwxrwx   1   20 Sep 11 22:25 JSONStream -> ../JSONStream/bin.js
lrwxrwxrwx   1   20 Sep 11 22:25 mkdirp -> ../mkdirp/bin/cmd.js
lrwxrwxrwx   1   27 Sep 11 22:25 node-gyp -> ../node-gyp/bin/node-gyp.js
lrwxrwxrwx   1   19 Sep 11 22:25 nopt -> ../nopt/bin/nopt.js
lrwxrwxrwx   1   27 Sep 11 22:25 opener -> ../opener/bin/opener-bin.js
lrwxrwxrwx   1   41 Sep 11 22:25 qrcode-terminal -> ../qrcode-terminal/bin/qrcode-terminal.js
lrwxrwxrwx   1   12 Sep 11 22:25 rc -> ../rc/cli.js
lrwxrwxrwx   1   16 Sep 11 22:25 rimraf -> ../rimraf/bin.js
lrwxrwxrwx   1   20 Sep 11 22:25 semver -> ../semver/bin/semver
lrwxrwxrwx   1   23 Sep 11 22:25 sshpk-conv -> ../sshpk/bin/sshpk-conv
lrwxrwxrwx   1   23 Sep 11 22:25 sshpk-sign -> ../sshpk/bin/sshpk-sign
lrwxrwxrwx   1   25 Sep 11 22:25 sshpk-verify -> ../sshpk/bin/sshpk-verify
lrwxrwxrwx   1   16 Sep 11 22:25 uuid -> ../uuid/bin/uuid
lrwxrwxrwx   1   18 Sep 11 22:25 which -> ../which/bin/which
lrwxrwxrwx 1  19 Sep 11 22:25 nopt -> ../nopt/bin/nopt.js
lrwxrwxrwx 1  20 Sep 11 22:25 semver -> ../semver/bin/semver
lrwxrwxrwx  1  42 Sep 11 22:25 webdriver-manager -> ../webdriver-manager/bin/webdriver-manager
lrwxrwxrwx 1  18 Sep 11 22:25 jsesc -> ../jsesc/bin/jsesc
lrwxrwxrwx 1  21 Sep 11 22:25 tsc -> ../typescript/bin/tsc
lrwxrwxrwx 1  26 Sep 11 22:25 tsserver -> ../typescript/bin/tsserver
lrwxrwxrwx 1  14 Sep 11 22:25 mime -> ../mime/cli.js
lrwxrwxrwx 1  25 Sep 11 22:25 uglifyjs -> ../uglify-es/bin/uglifyjs
lrwxrwxrwx 1  14 Sep 11 22:25 mime -> ../mime/cli.js
lrwxrwxrwx 1  14 Sep 11 22:25 mime -> ../mime/cli.js

Given that another program could consume global quota for handles, is there a way I can track down what's using file handles?

[bpasero]

I am not sure how to...

[jsonsystems]

I did find Who's consuming my inotify resources? on StackExchange a good starting point.

However, running that "big ball of mess" (authors words) results in no output. The command does run to completion (albeit with a warning):

lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
      Output information may be incomplete.

Excluding the FUSE filesystem obviously prevents the error, but still no output.

Adding -e /run/user/1000/gvfs makes the full command (big ball of mess):

sudo lsof -e /run/user/1000/gvfs | awk '/anon_inode/ { gsub(/[urw]$/,"",$4); print "/proc/"$2"/fdinfo/"$4; }' | while read fdi; do count=$(sudo grep -c inotify $fdi); exe=$(sudo readlink $(dirname $(dirname $fdi))/exe); echo -e $count"\t"$fdi"\t"$exe; done | sort -nr > watches

Assuming the command is correct, and that I have file watchers, then all file watchers must be in the FUSE filesystem?

I then tried checking getting information about a specific file in my VS Code workspace. Using lsof: WARNING: can't stat() fuse.gvfsd-fuse file system as a guide:

cd my-project-root/main-app/src/app
sudo lsof -e /run/user/1000/gvfs -f -- src/app/app.component.css

...no results (command ran to completion).

[akupaka]

Same here. VS Code v 1.30.0 and only 172 files without node_modules folder.
Have no idea what else could watch for another 8k files.

[bpasero]

@akupaka are you in a multi-root workspace or single folder?

[akupaka]

@bpasero it's single folder I guess. I opened folder using Code.

[pascollin]

Same here too. VS Code 1.30.1 and only 41 files outside node_modules folder.

[xsrvmy]

I just ran into this issue as well, and it's rather annoying because I use watchers for other things like compiling latex. I am not sure this is a factor, but it is possible that another development tool (eg. webpack) is using up resources.

[hoehrmann]

Also happening for me on Linux Mint 19.1 with a single folder and

Version: 1.31.1
Commit: 1b8e8302e405050205e69b59abb3559592bb9e60
Date: 2019-02-12T02:19:29.629Z
Electron: 3.1.2
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Linux x64 4.15.0-45-generic

Could background compilation in watch mode be the culprit?

[the-neo-zeed]

Same issue for me as well on Ubuntu 18.04.

Version: 1.31.1
Commit: 1b8e8302e405050205e69b59abb3559592bb9e60
Date: 2019-02-12T02:19:29.629Z
Electron: 3.1.2
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Linux x64 4.18.0-15-generic

I ran the commands @jackwootton posted with some modifications. At first, I wasn't getting any results back from running the command (same as @jackwootton). After some tinkering, I realized I needed to change the awk pattern from /anon_inode/ to /a_inode/ and finally got some results.

Commands I ran:

sudo lsof -e /run/user/1000/doc -e /run/user/1000/gvfs -nP | awk '/a_inode/ { gsub(/[urw]$/,"",$4); print "/proc/"$2"/fdinfo/"$4; }' | while read fdi; do count=$(sudo grep -c inotify $fdi); exe=$(sudo readlink $(dirname $(dirname $fdi))/exe); echo -e $count"\t"$fdi"\t"$exe; done | sort -nr > watches

Results:

4565    /proc/4679/fdinfo/21    /usr/share/code/code
3301    /proc/4719/fdinfo/20    /usr/share/code/code
96      /proc/1/fdinfo/6        /lib/systemd/systemd
72      /proc/2313/fdinfo/11    /usr/lib/gnome-settings-daemon/gsd-xsettings

... omitted for brevity

So, it appears vscode has launched two processes - the first (4679) having 4565 inotify monitored files and the second (4719) having 3301 inotify monitored files. My project only contains ~30 files.

Just to be sure, I disabled all the extensions, shut down vscode, and re-ran the above commands - no vscode processes where found, as expected.

I then relaunched vscode, leaving the extensions disabled, and opened my project folder again. I added an empty .js file and immediately received the 'unable to watch for file changes' warning. I then re-ran the above commands and got a similar result to the first run:

4565    /proc/12867/fdinfo/21   /usr/share/code/code
3298    /proc/12948/fdinfo/20   /usr/share/code/code
96      /proc/1/fdinfo/6        /lib/systemd/systemd
72      /proc/2313/fdinfo/11    /usr/lib/gnome-settings-daemon/gsd-xsettings

... omitted for brevity

And just to make sure things matched, I did a line count on /proc/12867/fdinfo/21 and it did indeed contain 4565 inotify entries. Here's a sample:

pos:    0
flags:  02004000
mnt_id: 13
inotify wd:11d5 ino:1200674 sdev:800002 mask:fc6 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:74062001e79915b2
inotify wd:11d4 ino:c61680 sdev:800002 mask:fc6 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:8016c60034d13d16
inotify wd:11d3 ino:c61696 sdev:800002 mask:fc6 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:9616c6006fb687e8
inotify wd:11d2 ino:c61689 sdev:800002 mask:fc6 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:8916c600bf718bd9
inotify wd:11d1 ino:c616ae sdev:800002 mask:fc6 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:ae16c600399e012c
inotify wd:11d0 ino:c616ab sdev:800002 mask:fc6 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:ab16c600380d4a93
inotify wd:11cf ino:c616a5 sdev:800002 mask:fc6 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:a516c60081ca84bc
inotify wd:11ce ino:c6167f sdev:800002 mask:fc6 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:7f16c600b4a97fa4
inotify wd:11cd ino:c61697 sdev:800002 mask:fc6 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:9716c60081c875ca
inotify wd:11cc ino:c61695 sdev:800002 mask:fc6 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:9516c600615d2ded
inotify wd:11cb ino:c61694 sdev:800002 mask:fc6 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:9416c600305ec5a3
inotify wd:11ca ino:c61686 sdev:800002 mask:fc6 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:8616c60085f0d0df
inotify wd:11c9 ino:c616eb sdev:800002 mask:fc6 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:eb16c6004f0db028
inotify wd:11c8 ino:c61684 sdev:800002 mask:fc6 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:8416c6009d9985d7
inotify wd:11c7 ino:c6168b sdev:800002 mask:fc6 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:8b16c6006f9705a9
inotify wd:11c6 ino:c61685 sdev:800002 mask:fc6 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:8516c6005d9fb664
inotify wd:11c5 ino:c6168a sdev:800002 mask:fc6 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:8a16c600a56530fc
inotify wd:11c4 ino:c61688 sdev:800002 mask:fc6 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:8816c600766d2ef5
inotify wd:11c3 ino:c616fe sdev:800002 mask:fc6 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:fe16c600a6b4d755
inotify wd:11c2 ino:c60c0a sdev:800002 mask:fc6 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:0a0cc600209c7eb5

... omitted for brevity

[yantrab]

the same for this repo.

Version: 1.32.3
Commit: a3db5be9b5c6ba46bb7555ec5d60178ecc2eaae4
Date: 2019-03-14T23:38:49.842Z
Electron: 3.1.6
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Linux x64 4.18.0-16-generic

[rickhall]

I believe I'm seeing the same thing on Fedora 29. To add some details, I have a folder containing 255 files, excluding node_modules. This is what I'm seeing for inotify consumption for Code:

   WATCHER
    COUNT     PID     CMD

    4270     6257  /usr/share/code/code /usr/share/code/resources/app/extensions/node_modules/typescript/lib/typingsInstaller.js --globalTy
    1617     6244  /usr/share/code/code /usr/share/code/resources/app/extensions/node_modules/typescript/lib/tsserver.js --useInferredProje

This seems awfully high for just 255 files.

[anied]

Confirming similar issue in Ubuntu 18.04. And when I had VSCode running I couldn't start my webpack dev server because there were no available watchers. I had to kill VSCode and work from Sublime Text to continue working.

[rickhall]

Just a follow up on this, I have a project with 104 files where Code is configured to ignore node_modules and some other directories and I am seeing this usage:

   WATCHER
    COUNT     PID     CMD
----------------------------------------
    4541     5167  /usr/share/code/code /usr/share/code/resources/app/out/bootstrap-fork --type=watcherService
    4367     5189  /usr/share/code/code /usr/share/code/resources/app/extensions/node_modules/typescript/lib/tsserver.js --useInferredProje
    4251     5231  /usr/share/code/code /usr/share/code/resources/app/extensions/node_modules/typescript/lib/typingsInstaller.js --globalTy

Holy smokes! That's a lot of file watchers for 104 files. Clearly, this editor is not intended for large projects.

[vitorhugomattos]

hm, maybe it's related to telemetry... using code-oss I get the expected numbers.

[fiblit]

@bpasero If you don't mind my asking, what more information is needed for this issue?

[bpasero]

I have previously asked about using multi-root setup or not because we use:

• chokidar: when opening 1 folder (no multi root setup)
• NSFW: when opening 0-N folder (multi root workspace file)

As of today, ONLY chokidar supports the files.watcherExclude setting in a way that it would require no file handles.

To ensure you are only in a single folder setup, this issue must reproduce via File > Open Folder. Can people confirm?

[vscodebot[bot]]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

[tony-garcia]

I'm seeing this issue in a project with only 4 files and no node_modules folder. I'm using VSCode 1.39.2 on Linux Mint 19.2 (equivalent to Ubuntu 18.04). And yes, @bpasero , the issue reproduces with File -> Open Folder. It also happens when I open the folder via the 'code' CLI.

[bpasero]

@tony-garcia to clarify:

• you open 1 folder in VSCode
• it has 4 files
• you see the warning about unable to watch?

[tony-garcia]

@bpasero yes, that's correct

[tony-garcia]

[bpasero]

@tony-garcia thanks, can you try this as well when no other app is running? possibly another app already needs all those file handles.

And to confirm, what is your configured limit? Check https://code.visualstudio.com/docs/setup/linux#_visual-studio-code-is-unable-to-watch-for-file-changes-in-this-large-workspace-error-enospc

[tony-garcia]

Still happens when no app is running.
For more context, this is a fresh install of Linux Mint 19.2. So not only is there not another app running, there are barely any other apps installed. I was running Mint 17.3 for a long time (Ubuntu 14.04 equivalent) with VSCode and had no issues (never changed the amount of watchers). Yesterday I performed a completely fresh install of Mint 19.2 and VSCode was one of the first things I installed and I see the warning every time, even with only 4 files.
Also, to answer your other question, I haven't changed my configured limit, so it's at the default value of 8192. But that should handle 4 files just fine. Also, as I mentioned, I never had to change that configuration when I was on Mint 17.3 and I habitually had 6+ apps running at the same time as VSCode.
Seems like every Linux person on this thread who is reporting OS version is either Mint 19 or Ubuntu 18. Do you guys at MS have a machine with one of those versions to see if you can reproduce?

[codeart1st]

Add Fedora 30/31 to the list.

[bpasero]

@tony-garcia I am using Ubuntu 18 at work for a long time without issues, but I also increased that limit, otherwise I would see the warning for the VSCode workspace.

Are you (or anyone here) willing to conduct a little experiment and try to run Chokidar (https://github.com/paulmillr/chokidar) library standalone? This is the file watcher we are using. Ideally we can distill a bug against them.

[tony-garcia]

Ok, so it seems like you did see the same issue before you increased the watcher limit, which is good to know.
I'd be willing to conduct an experiment with Chokidar. Any specific steps you want me to take?

[bpasero]

Ok, so it seems like you did see the same issue before you increased the watcher limit, which is good to know.

Well, but only with a VSCode workspace which has thousands of files.

Yeah, can you locally clone https://github.com/paulmillr/chokidar and run it to watch a simple small folder and see if you get the same folder? Instructions are at https://github.com/paulmillr/chokidar#api

[tony-garcia]

Hi @bpasero -- sorry for the radio silence. I will run chokidar and test it out for you. Just been crazy busy lately. I hope to get to this by the weekend. Thanks for the help.

[ghuser]

@tony-garcia, @bpasero FYI:

Checkout this issue: https://github.com/microsoft/vscode/issues/85038

There is a setting that is ignored when a second folder is added to the workspace:
user settings->text editor->files->watcher exclude.

If your workspace has one folder added, then watcher exclude works fine (e.g. node_modules dir is not watched).

When you add a second folder to the workspace then watcher exclude rules stop working and all folders of the workspace are watched without exclusions (even the first one).

In linux (with inotify subsystem), watching a directory means adding a watch for every single subdirectory recursively.

That is why adding a folder with only 4 files to the workspace can exhaust the watch limit. It is because after that point the first folder is also watched without exclusions (e.g. the node_modules subdirectory will also be watched now together with all the included subdirectories).

To reproduce:

1. Start vscode with strace (as described below) with a workspace with one folder added to it (That folder should contain node_modules subdir). Check the strace logs. No watches are added for node_modules dir because it is by default excluded in the settings.
2. Then add a new folder to the workspace (e.g. with 1 file only and nothing else inside). See how many watches are added now and check their paths. You will see paths being added from the first folder (node_modules directory).

I've tested with snap and flatpak versions but I guess it will be the same with standalone versions also.

command to run:

strace -fe trace=inotify_add_watch /path/to/vscode --disable-extensions 2>&1 |  grep "node_modules"

[bpasero]

Thanks for clarifying this, I thought by now people would see this only on a single-folder workspace. But please confirm.

[kudep]

Version: 1.40.1
Commit: 8795a9889db74563ddd43eb0a897a2384129a619
Date: 2019-11-13T16:49:30.162Z
Electron: 6.1.2
Chrome: 76.0.3809.146
Node.js: 12.4.0
V8: 7.6.303.31-electron.0
OS: Linux x64 5.3.11-1-MANJARO

i get same message after ssh-remote establish:
Unable to watch for file changes in this large workspace. Please follow the instructions link to resolve this issue.
for
fs.inotify.max_user_watches = 524288

Remoted dir contains one small txt file. All is good working in local dir.

[ghuser]

@kudep can you try to reproduce following the steps I describe above?

[pascollin]

version 1.40.1

The given command (copied below) shows a list of inotify watches (on node_modules) only when I add a second folder into the workspace.

The VSCode warning about "too many inotify watches" is shown either with a single folder workspace (when strace command doesn't log anything).

strace -fe trace=inotify_add_watch /path/to/vscode --disable-extensions 2>&1 | grep "node_modules"

[ghuser]

@pascollin This could be an effect of another editor or watch tool being open. e.g. sublime_text, webpack watch, cpx e.t.c
There is a nice script you can execute first for finding which process is consuming most of the watches. Then you can shut it down to focus on testing vscode.

[ghuser]

@bpasero is there any further feedback required for this issue? I think now it is reproducible.
As @pascollin verified:

The given command (copied below) shows a list of inotify watches (on node_modules) only when I add a second folder into the workspace.

node_modules is by default on the watch exclusion list, so no inotify watches should be added for that directory.
Since node_modules usually contains thousands of subdirectories this seems to be causing the exhaustion of inotify watches (one watch per directory).

[bpasero]

The given command (copied below) shows a list of inotify watches (on node_modules) only when I add a second folder into the workspace.

Sorry, I do not understand this message. Why does the command show the inotify watches only when a second folder is added?

[ghuser]

Why does the command show the inotify watches only when a second folder is added?

That's exactly my point. On linux (which uses inotify subsystem for watching folders) there a bug with vscode watcher exclude on workspaces with more than one root folders. And the command verifies it.

example:

dir1
  node_modules/

emptyDir/

Create a workspace with only dir1/ added to it.
Open vscode with strace as described above. When the workspace with one folder is loaded, nothing is printed. This means vscode watcher excludes (which by default excludes node_modules from watching) works fine.

Now do: File->Add Folder to the workspace: emptyDir/. You see dir1/node_modules being printed in the console. This means that watcher exclude stops functioning and it wrongly adds watches for all folders.

Now the implication of this is that since node_modules normally contain thousands of directories, the OS-level max watches is reached. So nor vscode nor any other program can add any more watches. E.g. tools like nodemon or webpack (watchmode) will not function if started after vscode.

Hope I clarified it a bit more.

[bpasero]

Yeah, that is a known issue.

/duplicate https://github.com/microsoft/vscode/issues/40898

[vscodebot[bot]]

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for existing issues here. See also our issue reporting guidelines.

Happy Coding!

[slanden]

I have this problem and I have a single root folder open in VS Code that includes node_modules and other subdirectories. The problem is not just in multi-root workspaces.

[victor-yarema]

From what I understand the referred issue (#40898) does not explain the comment (https://github.com/Microsoft/vscode/issues/59679#issuecomment-549026436) from @tony-garcia .
Or did I miss something?

[klwemu]

Do you use C:\ for your web project? VS Code has serious troubles to watch file changes if not. It´s much faster as well. NOTE: Do not use drives which are mapped to folders!

By the way: WebStorm displays a warning in such a case! Would be nice in Code too.

[Duncan3142]

I'm experiencing the same issue on Fedora 31, with a single folder workspace. The vscode watch exclude globs are being ignored ignored.
Adding the desired exclude globs to .gitignore (node_modules, dist, etc...) can intermittently fix the problem.