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
    Camera and Video Control with HTML5

    Client-side APIs on mobile and desktop devices are quickly providing the same APIs.  Of course our mobile devices got access to some of these APIs first, but those APIs are slowly making their way to the desktop.  One of those APIs is the getUserMedia API...

  • By
    7 Essential JavaScript Functions

    I remember the early days of JavaScript where you needed a simple function for just about everything because the browser vendors implemented features differently, and not just edge features, basic features, like addEventListener and attachEvent.  Times have changed but there are still a few functions each developer should...

Incredible Demos

  • By
    Chris Coyier’s Favorite CodePen Demos II

    Hey everyone! Before we get started, I just want to say it's damn hard to pick this few favorites on CodePen. Not because, as a co-founder of CodePen, I feel like a dad picking which kid he likes best (RUDE). But because there is just so...

  • By
    Send Email Notifications for Broken Images Using MooTools AJAX

    One of the little known JavaScript events is the image onError event. This event is triggered when an image 404's out because it doesn't exist. Broken images can make your website look unprofessional and it's important to fix broken images as soon as possible.

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
    
  5. This just saved me from having to nuke and reinstall node_modules. Thaaaaaaanks!

  6. Hai

    the command reply : ‘ps’ is not recognized as an internal or external command,
    operable program or batch file.

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