Node EADDRINUSE (Address Already in Use) Error

By  on  

Every once in a while my MacBook Pro freaks out and a process goes rogue.  This oftentimes happens when I'm working on the excellent debugger.html project; I attempt to start the server side of the debugger and suddenly I'm hit with an error that resembles the following, leading to the process not starting from that time forward:

Error: listen EADDRINUSE 0.0.0.0:9000
    at Object._errnoException (util.js:1026:11)
    at _exceptionWithHostPort (util.js:1049:20)
    at Server.setupListenHandle [as _listen2] (net.js:1343:14)
    at listenInCluster (net.js:1391:12)
    at doListen (net.js:1500:7)
    at _combinedTickCallback (internal/process/next_tick.js:141:11)
    at process._tickCallback (internal/process/next_tick.js:180:9)
    at Function.Module.runMain (module.js:667:11)
    at startup (bootstrap_node.js:201:16)
    at bootstrap_node.js:626:3  

The best way to fix this issue is by killing the Node.js process that's running for the rogue task.  Start by finding a listing of all of the node processes:

ps aux | grep node

You'll see a listing similar to this:

davidwalsh       12413   0.0  0.0  2592088   3888   ??  S     7:38PM   0:20.45 /Users/davidwalsh/Projects/debugger.html/node_modules/flow-bin/flow-osx-v0.52.0/flow
davidwalsh       12412   0.0  0.0 29739356   2372   ??  S     7:38PM   0:00.12 /Users/davidwalsh/Projects/debugger.html/node_modules/flow-bin/flow-osx-v0.52.0/flow
davidwalsh       12411   0.0  0.0 29732188   2372   ??  S     7:38PM   0:00.07 /Users/davidwalsh/Projects/debugger.html/node_modules/flow-bin/flow-osx-v0.52.0/flow
davidwalsh       12410   0.0  0.0 29732188   2372   ??  S     7:38PM   0:00.07 /Users/davidwalsh/Projects/debugger.html/node_modules/flow-bin/flow-osx-v0.52.0/flow
davidwalsh       12409   0.0  0.0 29731164   2372   ??  S     7:38PM   0:00.06 /Users/davidwalsh/Projects/debugger.html/node_modules/flow-bin/flow-osx-v0.52.0/flow

When you identify the rogue process, use the kill command along with the process number to remove it:

#kill -9 {process_number}
kill -9 12413

With the process killed you can now start up the server as normal!

Recent Features

  • By
    CSS vs. JS Animation: Which is Faster?

    How is it possible that JavaScript-based animation has secretly always been as fast — or faster — than CSS transitions? And, how is it possible that Adobe and Google consistently release media-rich mobile sites that rival the performance of native apps? This article serves as a point-by-point...

  • By
    5 Ways that CSS and JavaScript Interact That You May Not Know About

    CSS and JavaScript:  the lines seemingly get blurred by each browser release.  They have always done a very different job but in the end they are both front-end technologies so they need do need to work closely.  We have our .js files and our .css, but...

Incredible Demos

  • By
    9 Incredible CodePen Demos

    CodePen is a treasure trove of incredible demos harnessing the power of client side languages.   The client side is always limited by what browsers provide us but the creativity and cleverness of developers always pushes the boundaries of what we think the front end can do.  Thanks to CSS...

  • By
    MooTools PulseFade Plugin

    I was recently driven to create a MooTools plugin that would take an element and fade it to a min from a max for a given number of times. Here's the result of my Moo-foolery. The MooTools JavaScript Options of the class include: min: (defaults to .5) the...

Discussion

  1. There’s a trick I use for this in my watch scripts. Substitute ‘bin/www’ for whatever script Node is running:

    kill -3 (ps aux | grep 'bin/www' | awk '{print $2}')
    
  2. Felix

    And when you don’t know what process grabbed your port, you can find out via

    lsof -n -i:[port-number]
    
    • Amish

      You could further narrow down the list to only the processes listening on that port, by doing the following:

      lsof -n -i4TCP:[port-number] | grep LISTEN

      Then kill that process.

  3. Oleg Mihailik

    Much better solution, implemented internally at my employer:

    Hash-derive port number from full path.

    Rather than stick to localhost:9000 you’re getting a pseudo-random port unlikely to collide with any other session you’re running. You can debug two branches of the same codebase at once.

    Being derived from the path, the port is sticky: you can restart as much as you wish.

  4. taskkill /f /im node.exe
    

Wrap your code in <pre class="{language}"></pre> tags, link to a GitHub gist, JSFiddle fiddle, or CodePen pen to embed!