FSEventStreamStart: register_with_server: ERROR: f2d_register_rpc() #75
Comments
|
I have honestly never seen that error before and have no idea how to solve it. I also couldn't reproduce the issue. I'm on OSX 10.8.3. It looks like an issue with node, likely even libuv: https://github.com/joyent/libuv/blob/master/src/unix/fsevents.c#L200. Sorry to punt it but I don't think there is any way I could fix this issue here. Thanks! |
|
I have the same issue. |
|
UPDATE: I fixed the issue. I believe I was tracking too many files using the pattern "**/template.html" on every reload. So I adjusted the grunt.event object to initially watch all files, then changed the file mapping to watch only the file being changed. Doing this prevented the issue from reoccurring. Here's my code now: /*global module:false*/
var minimatch = require('minimatch');
module.exports = function (grunt) {
grunt.initConfig({
watch: {
template: {
files: '**/template.html',
tasks: ['inlinecss', 'htmlcompressor']
},
options: {
nospawn: true
}
},
htmlcompressor: {
compile: {
files: [{
src: 'template.html',
dest: 'email.html'
}],
options: {
type: 'html',
compressCss: true
}
}
},
inlinecss: {
main: {
files: [{
src: 'email.html',
dest: 'email.html'
}]
}
}
});
// Load tasks
grunt.loadNpmTasks('grunt-contrib-watch');
grunt.loadNpmTasks('grunt-inline-css');
grunt.loadNpmTasks('grunt-htmlcompressor');
// Default Task(s)
grunt.registerTask('default', ['watch']);
grunt.event.on('watch', function(action, filepath) {
// Current working directory
var cwd = filepath.replace(filepath.substr(filepath.lastIndexOf('/') + 1), '');
// Destination is path/to/directory/email.html
var dest = cwd + 'email.html';
// Change file mapping to match directory of changed file
grunt.config('watch.template.files', filepath);
if (minimatch(filepath, grunt.config('watch.template.files'))) {
grunt.config('inlinecss.main.files.0.src', [filepath]);
grunt.config('inlinecss.main.files.0.dest', dest);
grunt.config('htmlcompressor.compile.files.0.src', dest);
grunt.config('htmlcompressor.compile.files.0.dest', dest);
}
});
}; |
|
I'm also seeing this issue. I'll take a look at @jeremypeter's workaround for now and pop in to see if this bug is reported somewhere in the dependent projects. |
|
Grunt-contrib-watch has also a problem with Mocha: (0 tests ... on file change). When I run the same code on Windows, no mocha problems nor FSEventStreamStart strange warnings. Now Mac sucks. |
|
I have a theory this may have to do with how grunt watch reinitializes itself each time it runs. There may not be enough time between watches on the same resources (directories) so there's a race condition if the event stream is still be "scheduled" (not properly stopped/invalidated.) While this might be a node-level issue, it is possible that we can do more to terminate the existing watch's subscriptions more properly before recreating the task. |
|
Can we reopen this? I found a solution based on my previous comments. Gaze supports a close() method which closes the existing subscriptions. My fix consists of:
I'll attempt to submit a proper pull request when I can, but feel free to test it out sooner. |
|
@snostorm I'll give that a go. atm it will try closing the watchers upon |
|
@shama I was actually hacking the latest npm version, so the Either way, I think explicitly calling |
|
@shama: putting the close calls in |
|
I figured out how to duplicate this issue. If you open a file descriptor on a file within a process then try to open another file descriptor on the same file with another process... bam: The problem here is sometimes file descriptors are not always closed properly with spawning child processes. So I'll need to look into that more. But at least now I know how to duplicate the issue to work on a fix for it upstream. |
|
Oh and a way to get around this issue if you run into it is: |
|
Opened an issue for this on nodejs/node-v0.x-archive#5463 |
|
When is the next planned tag? |
|
I'm having this problem too. One observation is that I only seem to see it when a live-reload client is connected. Not sure if that makes sense - maybe the web server serving the updated file acts as the second process that triggers the error? Just a guess. |
|
I'm getting this right now, still no actionable solution? |
|
@reggi The only thing that works for me is |
|
@shama I ran |
|
This has just started happening for me too. Previously fixed this by upgrading node, but now I'm on 0.10.22. Trying 0.11 now. |
|
@aexmachina It should be patched in the latest node v0.10. Would you mind posting your Gruntfile so I can try and duplicate? |
|
@aexmachina Thanks! Try upgrading to the latest watch task, |
|
Yep, that's got it. Thanks! |
|
It looks like the problem is caused by the number of files, if I reduce the set of file/directories to be watched then the problem goes away. So I can work around it, but I think it'd be good to have a better error message when this happens. |
|
I had the same issue, I caused (and fixed) it by making a small adjustment in the files to be watched: changed to: To debug this though, is there any way to inspect what files are matched by patterns set in the watch task? |
|
Just curious, why do people do |
|
@fwielstra module.exports = function(grunt) {
grunt.initConfig({
matchtest: {
/* change the content of this pattern to test your variables */
src: '<%= matchPatternToTest %>'
},
});
// Match Pattern Testing
// ----------------------------
// This is a handy little function for testing your match patterns. When you use variables for
// configuring tasks, it's sometimes useful to see output of what variables your directives sees.
// This task lets you do that. Simply call `grunt matchtest` from the command line.
grunt.registerMultiTask('matchtest', function() {
console.log(this.filesSrc);
});
}; |
|
@feitla Unfortunately the solution is just to watch less files until node |
|
For future visitors from Google: check that you're not accidentally including bower or node_modules directories :~) Oops! Just add I ran into this using gulp with a watch. Commenting here because this is the first Google result for the error, and it's relevant. |
|
Thanks @ggranum ! Works for me. |
|
thanks everyone! this SMA! |
|
@ggranum thank you |
|
@ggranum thank you, this solve problems :) |
|
Thanks @ggranum! |
If you use a custom adapter, grunt is watching inside `node_modules`. Then... gruntjs/grunt-contrib-watch#75 happened
|
Avoid watching items in the "bower_components" folder too. [
"!**/node_modules/**/*",
"!**/bower_components/**/*"
] |
|
How can this possibly be closed? "Watch fewer files" is not a solution, nor is excluding node_modules folders. What if my org has a module that has a linked module where we develop our sass code? |
|
@dclowd9901 We accept pull requests if you know a better solution. |
|
@EvanLovely Where should I add these to avoid watching? Thanks! |
|
@chetangautam Add them anywhere you're declaring files to watch. |
|
@EvanLovely Thanks! |
I have an issue where on every 3rd save I get this: ERROR
It appears when I either save it 3 times within the same file or if I open up 3 different files, the error will appear afte the 3rd file has been saved.
Here's my code:
I basically have a folder structure that contains a template.html and an email.html. I work within the template.html and on every save, it creates the email.html that inlines the css and minifies the code.
The text was updated successfully, but these errors were encountered: