fs.watch: node[52551] (CarbonCore.framework) FSEventStreamStart: register_with_server: ERROR: f2d_register_rpc() => (null) (-21)

[shama]

I'm getting an error which appears to be directly from libuv while using fs.watch. I'm on OSX 10.8.3 and using node 0.10.5. My ulimit -n is 10480.

I'm able to duplicate the error with the following example (it is a bit contrived but it simulates what is happening with our gruntjs/grunt-contrib-watch module). It only happens when you're watching a larger number of files and another process tries to watch the same files.

I've setup an example in a repo for duplicating the error:

git clone git://github.com/shama/fs-watch-error && cd fs-watch-error
npm install
npm test

---

Here is the code that duplicates the issue:

var fs = require('fs');
var glob = require('glob');
var limit = 9999;
glob('**/*', function(err, files) {
  if (files.length > limit) files = files.slice(0, limit);
  console.log('watching ' + files.length + ' files...');
  files.forEach(function(file) {
    fs.watch(file, function() {});
  });
});

Then run node index.js & node index.js on a large number of files and you should get:

2013-05-13 11:39 node[54911] (CarbonCore.framework) FSEventStreamStart: register_with_server: ERROR: f2d_register_rpc() => (null) (-21)

---

I'm looking into updating our module to avoid this error but I'm reporting it here because I believe it shouldn't error out to the console in that way. Considering that I don't seem to be able to catch that error and handle it more appropriately.

Thanks!

[bnoordhuis]

Sorry, can't reproduce. FWIW, it doesn't look like a libuv error to me but rather it's Carbon complaining about failing internal bookkeeping.

/cc @indutny

[shama]

Thanks for trying @bnoordhuis. This is a bit over my head which is why it's an issue not a PR but I'll try looking into it more soon. Good excuse for me to learn. :)

[kevindente]

I'm seeing this problem as well. Only seems to happen with Node 0.10 - I can't reproduce with 0.8.

[bnoordhuis]

v0.8 doesn't use FSEvents.

FWIW, I still think this is an environmental issue rather than a node.js bug but I'll leave the report open for now.

[pho3nixf1re]

I'm getting this same issue on OSX 10.8 with node 0.10.5 using grunt-watch-contrib to watch a large number of files.

[carlos8f]

👍

[jamorton]

Same issue as @pho3nixf1re.
I also get "Fatal error: EMFILE: Too many opened files." if I keep the watcher open for several hours.

[shama]

@Jonanin EMFILE is a whole different issue. The default max file descriptor limit for OSX is low 256. You can increase it with temporarily with ulimit -n 1200.

FWIW, the easiest way to avoid this error is watch less files because it only happens (for me at least) when watching a large amount of files. Tighten up your globbing patterns. If you're doing **/* then you're probably watching files in your node_modules folder which isn't necessary. Either structure your app different or add '!**/node_modules/**' to your patterns.

[medikoo]

On OSX I see it in WebStorm console (when I run command that uses a lot of watchers), but I don't see it when I run same command in OSX terminal.

[indutny]

Can you please try running disk repair from Disk Utility app? Let me know if this issue is still reproducible after the repair.

[shama]

Still reproducible for me on my MBP:

Also on my older macbook:

Thank you for looking into this @indutny!

[indutny]

I've debugged it up to mach_msg() call which receives some custom-struct which contains that -21 error code.

[indutny]

Apparently, you can watch only 451 files at the same time using FSEvents API. Not sure if its a joke from Apple, or something else... Will try to figure out more soon.