Error: listen EADDRINUSE about grunt-express-server

[ericclemmons]

So it's starting up fine, but watch triggers express again and it fails for you? I'll check 'er out!

[Dakuan]

Hi Eric,

Yes, that's right. I've tried disabling the tasks that get run before hand to see if they were interfering some how but no joy….

Cheers!
Dom

On 4 Aug 2013, at 17:59, Eric Clemmons [email protected] wrote:

So it's starting up fine, but watch triggers express again and it fails for you? I'll check 'er out!

—
Reply to this email directly or view it on GitHub.

[Dakuan]

any luck with this?

Cheers,
Dom

[alexgorbatchev]

Had the same issue, the problem might be that even though your server receives SIGTERM, it might not be exiting because of opened connections or listeners... SIGTERM is a polite way of asking a process to exit... so in process.on 'SIGTERM' add process.exit()

[ericclemmons]

What's so bizarre is that in my testing, you would expect grunt express:defaults express:defaults express:defaults to exhibit this behavior, right?

I just added grunt-contrib-watch, with ['jshint', 'express:defaults'], and no matter how I try, grunt express:defaults watch won't trigger the EADDRINUSE error.

I need some more help here...

[ericclemmons]

@Dakuan Can you post up your app.js so I can see if there's any hints there? Particularly the app.listen part...

[RasterBurn]

I'm having the same problem. Are there any workarounds?

[ericclemmons]

Sure, there are totally some workarounds, and possibly some fixes! If only someone could point me to a project or example code for me to reproduce the problem with :)

:hint hint:

[ericclemmons]

I'm going to have to close this issue until someone can help me reproduce it. I may run across it on my own, but until then, you guys are going to have to help me out here :)

[meenie]

@ericclemmons - I'm having this issue now. Here is what I have:

Gruntjs Snippet

// Define Server
express: {
    options: {
        // Override defaults here
    },
    dev: {
        options: {
            script: 'express.js'
        }
    }
},
// Setup Watch
watch: {
    express: {
        files:  [ 'server/**/*.js' ],
        tasks:  [ 'express:dev' ],
        options: {
            spawn: false // Without this option specified express won't be reloaded
        }
    }
};

grunt.registerTask('server', ['express:dev', 'watch']);

express.js

var express = require('express'),
    app = express();

// Start the server
app.listen(3000, function () {
    console.log("Express server listening on port %d in %s mode", 3000, app.settings.env);
});

I don't think you can get much simpler than this.

[meenie]

Just having a look at your /tasks/lib/server.js. I've done console.log(process._servers); just above line 12. When it first starts up, I get undefined, which is what we want. But when a file is edited and watch triggers the server again, that _servers object is still undefined. I'm guessing that it shouldn't be. Maybe something changed recently in grunt-contrib-watch that no longer persists the data in process? I've never written a grunt task, so I could be talking complete nonsense.

[ericclemmons]

Do me a favor & add module.exports = app.listen(...) in front of your code & let me know if that changes anything...

[meenie]

Do me a favor & add module.exports = app.listen(...) in front of your code & let me know if that changes anything...

Nope, doesn't work.

[ericclemmons]

Ok, back to me then ;)

[meenie]

Just wondering if you've had a chance to look at this? It would be super handy if it worked :).

[ericclemmons]

Sorry, been ill for several days. I'll get to this soon.

[meenie]

Hi @ericclemmons,

Sorry to hear that! No worries, take your time.

Cheers,
cody

[ericclemmons]

Just published v0.4.10 with #31 (fixes #28 & #30). Can you let me know if this also resolves your problem, or if it persists?

[meenie]

Hi @ericclemmons,

Sorry, but this is not fixed. It's still not killing off the server before trying to restart it.

[ericclemmons]

@meenie I had to revert v0.4.10 because of #32. Please confirm this problem persists with v0.4.11, as I'll need to create test cases specifically for grunt-contrib-watch.

[ericclemmons]

Wait a minute here. Is everyone using the spawn/nospawn option?

https://github.com/ericclemmons/grunt-express-server#with-grunt-contrib-watch

[meenie]

@ericclemmons yes - I have spawn set to false.

[meenie]

@ericclemmons for info, I'm trying to integrate it into ngBoilerplate: https://github.com/ngbp/ng-boilerplate

[meenie]

@ericclemmons I saw your comment with the code example using nospawn: true (It seems you've deleted it though? I saw it in the email alert you get when there is a new comment on an issue). So I put it in and now everything works.

So the conclusion is:

1. spawn: false doesn't work
2. nospawn: true does work

[ericclemmons]

grunt-contrib-watch changed nospawn to spawn, and they should pretty much just do the inverse of the other. So, I'm not sure why they'd have different behavior.

Man, I have to say, Grunt's watch behavior is pretty annoying when it comes to managing processes. It's a freakin' minefield.

[Dakuan]

fixed for me too!

[j-c-t]

I had trouble getting this to work for me, but found an alternate solution that may help others:

watch: {
  express: {
    files: ['src/server/**/*.js'],
    tasks: ['express:dev'],
    options: {
      atBegin: true, // when watcher loads, run tasks once
      spawn: false //still req'd
    }
  }
}

express: {
  dev: {
    options: {
      script: 'src/server/http-server.js'
    }
  }
}

grunt.registerTask('start', ['watch:express']);

options.atBegin for grunt-contrib-watch relieves you of needing to run the task once before setting the watcher, since the watcher will now do it for you when it loads.

Allowing watch this extra bit of control around task execution seemed to resolve the conflict for me, and also simplified my task lists - nice to be able to specify just the watch.

[tarwich]

So... Sorry to resurrect a zombie, but just wanted to confirm that the problem is specifically this line from @meenie

grunt.registerTask('server', ['express:dev', 'watch']);

Which is fixed by removing the express:dev from boot and using atBegin:true as @eviljohnius mentioned in comment #42258252

[igrayson]

Looks like this could be a FAQ :)

I had this symptom when using babel-node to start an (ES6) server. I was using this configuration:

dev: {
  options: {
    opts: ['node_modules/babel/bin/babel-node'],
    port: 8282,
    script: 'server.js'
  }
}

After trying all other suggestions in this thread, I added a babel-node shim. This worked:

dev: {
  options: {
    port: 8282,
    script: 'app.js'
  }
}

app.js:

require('babel/register')({stage: 0});
require('./server');

[ericclemmons]

Now that's interesting. I expected the babel-node binary would work.