Skip to content

Grunt Server "Got error listen EADDRINUSE" #938

Closed
rememberlenny opened this Issue Feb 21, 2013 · 34 comments
@rememberlenny

Followed instructions for basic webapp and can't get the server running.

Started with yo webapp, but getting an error every time I run grunt server.

Error:

Running "server" task

Running "clean:server" (clean) task

Running "coffee:dist" (coffee) task
>> Destination not written because compiled files were empty.

Running "compass:server" (compass) task
Nothing to compile. If you're trying to start a new project, you have left off the directory argument.
Run "compass -h" to get help.

Running "livereload-start" task
... Starting Livereload server on 35729 ...

... Uhoh. Got error listen EADDRINUSE ...
Error: listen EADDRINUSE
    at errnoException (net.js:769:11)
    at Server._listen2 (net.js:909:14)
    at listen (net.js:936:10)
    at Server.listen (net.js:985:5)
    at Server.listen (/Users/lkbogdonoff/sites/portfolio/node_modules/grunt-contrib-livereload/node_modules/tiny-lr/lib/server.js:133:15)
    at Object.startLRServer (/Users/lkbogdonoff/sites/portfolio/node_modules/grunt-contrib-livereload/lib/utils.js:21:11)
    at Object.module.exports (/Users/lkbogdonoff/sites/portfolio/node_modules/grunt-contrib-livereload/tasks/livereload.js:44:20)
    at Object.task.registerTask.thisTask.fn (/Users/lkbogdonoff/sites/portfolio/node_modules/grunt/lib/grunt/task.js:78:16)
    at Object.Task.start._running (/Users/lkbogdonoff/sites/portfolio/node_modules/grunt/lib/util/task.js:282:30)
    at Task.runTaskFn (/Users/lkbogdonoff/sites/portfolio/node_modules/grunt/lib/util/task.js:235:24)```

Any thoughts @sindresorhus ?
@jaromero

I am currently having the same issue, except that mine is from attempting to run servers for two different projects (and thus the livereload server from the first one is able to grab and hold on to port 35729; the second one therefore fails with EADDRINUSE).

It's relatively straightforward to edit the port in the connect:livereload task in Gruntfile.js, but I have absolutely no clue how to specify the LR server port here. (The task that sets up the LR server is called livereload-start with the dash, and trying to add it in camel case to Gruntfile.js apparently has no effect).

EDIT: livereload-start, not -server

@rememberlenny
@sindresorhus
Yeoman member

@lkbgift It means the port is in use. Make sure you're not running the server in another terminal. Otherwise, just change the port in the Gruntfile.

@sleeper Can you catch Got error listen EADDRINUSE and show a more userfriendly error?

@jaromero

@sindresorhus it's not very clear how to change the port livereload uses. I had to dig into grunt-contrib-livereload/lib/utils.js:13 to figure it out. Turns out the port can be overridden directly in the livereload task, not inside the options property which confused the hell out of me at first:

// ...
livereload: {
    port: 35728
}
// ...

This does NOT work:

// ...
livereload: {
    options: {
        port: 35728
    }
}
// ...

Perhaps an issue to report at gruntjs/grunt-contrib-livereload?

@sindresorhus
Yeoman member

Perhaps an issue to report at gruntjs/grunt-contrib-livereload?

Sure.

@jaromero

On second thought, I don't even think it's necessary to change anything, if the purpose of having livereload in the first place is to just aid in testing. So naturally it really only should run for the server target (no need for target-specific options really) and in no other circumstance unless you explicitely modify the tasks set up by yo (by which point I guess we can assume you know what you're doing).

If anything, it should probably go into the yeoman docs, for people wanting to run more than one server like this.

Incidentally, I'm not even sure if this is the same issue as @lkbgift had (and/or if it was solved), so I apologize if I accidentally hijacked this issue. I'll create a new issue if that's the case.

@rememberlenny

@jaromero no worries! Our problems are different, but in any case I figured it out.

I documented by stop-gap fix here: http://lkb.cc/blog/2013/03/01/yeoman-eaddrinuse-error-fix/

Hopefully if someone searches for the same problem, they can emulate my change or find this thread.

@Sinetheta

I have the same issue, and had to get around it in the same way (by disabling livereload). Would be nice to find a fix though, no amount of specifying the port option seems to actually change anything.

@krzysztofantczak

@lkbgift just change it's port, and it should work again, but as @jaromero said, livereload reads 'port' option from another place, than You think looking at your Gruntfile (confirmed by watching grunt livereload sourcecode).

@Melindrea

And whether or not this is the same issue others had, I today realised the reason I was getting that error is because I was working in Sublime Text 2, with the LiveReload plugin active, so although this doesn't have anything to do with Yeoman, it might be a useful thing for people googling the error message.

@rememberlenny
@swallentin

Hi,

My finding is that there is a conflict between LiveReload Mac OS X App and the grunt-contrib-livereload package.

If you have the LiveReload App running issuing $ grunt server will fail and vice versa. To circumvent this issue, close down the LiveReload App while using the grunt-contrib-livereload plugin (which seems to be included by default when using yeoman).

When you have LiveReload App running you will get this,
LiveReloa 7519 stephanwallentin 7u IPv4 0x4734c35ddd807ff3 0t0 TCP *:35729 (LISTEN)

When you run $ grunt server from your project folder you will get this,
node 7547 stephanwallentin 8u IPv4 0x4734c35ddd807ff3 0t0 TCP *:35729 (LISTEN)

@swallentin

Hi again,

Stated earlier there is an easy solution to this problem, changing the port number in the config file.

I added this to my Gruntfile.js,

    yeoman: yeomanConfig,
    livereload: {
      port: 35728
    }

A suggestion is to add livereload config port for the default webapp gruntfile. This can clarify for other developers running into this problem.

@chandlervdw

Unless I'm mistaken, this issue is present in generator-angular, as well.

@passy
Yeoman member
passy commented Apr 5, 2013

@chandlervdw It's not an issue in any particular generator, it just happens if you have another process blocking the port.

@atomless
atomless commented Apr 8, 2013

Just like to confirm that removing the LiveReload package in Sublime Text 2 fixes this issue :- using Package Control: Remove Package, then choose LiveReload and after a sublime restart grunt server now works on the cli without error.

@iDVB
iDVB commented Apr 10, 2013

Removing LiveReload does not seem to take care of the issue for me. I've verified it is indeed removed. However, the only thing that works is to close Sublime Text 2 all together. Anyone else have this persistant of an issue?

UPDATE - Turns out that removing the subl livereload DID fix the issue. I was at that point having the issue that even though I had broke out of the previous "grunt server" call, it was still running in the background so when I tried to run it again it was now that that was erroring. In short, I killed my term window as well and all is now well.

Thanks!

@rememberlenny

@iDVB Can you open Activity Monitor and search for the livereload ports? You might have another application running as a plugin without realizing it.

@dcardosods dcardosods referenced this issue in robinpokorny/generator-lessapp Apr 25, 2013
Closed

Error running yo lessapp #2

@alepee
alepee commented May 3, 2013

@atomless +1
I disabled LiveReload in ST2, like a boss ;)

@rowild
rowild commented May 5, 2013

I can confirm that the deactivation of the liveReload plugin in Sublime Text 2 fixes the problem.

@goliatone

I don't feel disabling ST2 LiveReload plugin is a real fix. Like @swallentin suggested, just add a new line in the config to set a new port.

yeoman: yeomanConfig,
    livereload: {
      port: 35728
    }

The real issue thou, is that instinctively you want to add the option to connect.livereload.options
Anyhow, it seems that grunt-contrib-livereload will be deprecated.

Live reloading is now built into grunt-contrib-watch version 0.4.0. grunt-contrib-livereload and grunt-regarde will be deprecated soon.

@sindresorhus
Yeoman member

@goliatone the real issue is ST2 LiveReload. Though it's easy enough work around it by changing the port.

@angsmith

@sindresorhus I have the same issue and LiveReload is disabled in ST2 for me.

@rememberlenny
@angsmith

I fixed it by adding the port into the config (as per @goliatone comment above), however just wanted to state for anyone new to this thread that it's not just Sublime Text 2 that causes the issue.

@sindresorhus
Yeoman member

@angelasm1th that's true, the Livereload browser extension can also cause it.

@scriptdude

In my case I simply already had a 'grunt server' running in a different screen. After ending the other grunt server I was able to start a new one without the above error.

@estace
estace commented Nov 8, 2013

To kill the processes being used by that port, type in your terminal:

kill -9 $(lsof -t -i :9000)

(be sure to update the port number to correspond to your project)

@eilvein
eilvein commented Aug 19, 2014

delete sublime livereload Or shut down sublime

@purish
purish commented Nov 25, 2014

i dont know whether the issue of 'listen EADDRNOTAVAIL' is the same with you

@monolithed

+1

events.js:85
      throw er; // Unhandled 'error' event
            ^
Error: listen EADDRINUSE
    at exports._errnoException (util.js:746:11)
    at Server._listen2 (net.js:1129:14)
    at listen (net.js:1155:10)
    at net.js:1253:9
    at GetAddrInfoReqWrap.asyncCallback [as callback] (dns.js:81:16)
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:99:10)
@basilinjoe

hay am getting this error ! help me please !

error: Grunt :: Error: listen EADDRINUSE
at exports._errnoException (util.js:746:11)
at Agent.Server._listen2 (net.js:1156:14)
at listen (net.js:1182:10)
at Agent.Server.listen (net.js:1267:5)
at Object.start (_debugger_agent.js:20:9)
at startup (node.js:86:9)
at node.js:814:3

@akhayoon

Thanks @estace your solution did it for me. Just killed the port and everything worked again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.