Nodemon: Occasional "port already in use" error on macOS

[Nickersoft]

• nodemon -v: 1.14.12
• node -v: 9.4.0
• Operating system/terminal environment: macOS High Sierra / zsh
• Command you ran:

$ concurrently -k "webpack -d --config ./webpack/config/webpack.dev.config.js --watch" "nodemon ./bin/app.bundle"

This was my first attempt to update the Webpack build and restart the server simultaneously using concurrently. I thought maybe concurrently was causing some issues, so I opted for the Nodemon Webpack Plugin instead, only to find I was getting the same issue.

Expected behaviour

Nodemon should kill the server clean every time it restarts, or when it exits.

Actual behaviour

I'm informed that my server's port is already running when Nodemon starts it ("Port 8080 is already in use"), even after forcibly killing the server on that port using the process ID listened with lsof -i. When files change and Nodemon restarts, sometimes it actually listens on the port, but most of the time it just complains the port is already in use. A clean reboot of my system usually makes the problem go away temporarily.

Steps to reproduce

Unfortunately, an extremely tricky issue to reproduce, seeing there does not seem to be a clear case of when it happens or when it doesn't. It happens randomly, very often but not frequently. Here is how my server is being set up, though:

const port = normalizePort(process.env.PORT || '8080');
app.set('port', port);

if (port) {
  const server = http.createServer(app);

  server.listen(port);
  server.on('error', onError);
  server.on('listening', onListening);

  process.on('uncaughtException', () => server.close());
  process.on('SIGTERM', () => server.close());
  process.on('exit', () => server.close());

  function onError(error) {
    if (error.syscall !== 'listen') {
      throw error;
    }

    const bind = typeof port === 'string' ? `Pipe ${port}` : `Port ${port.toString()}`;

    switch (error.code) {
      case 'EACCES':
        console.error(`${bind} requires elevated privileges`);
        process.exit(1);
        break;
      case 'EADDRINUSE':
        console.error(`${bind} is already in use`);
        process.exit(1);
        break;
      default:
        throw error;
    }
  }

  function onListening() {
    const addr = server.address();
    const bind = typeof addr === 'string' ? `pipe ${addr}` : `port ${addr.port}`;
    debug(`Listening on ${bind}`);
    console.log(`Server started on ${bind}`);
  }
}

function normalizePort(val) {
  const port = parseInt(val, 10);

  if (isNaN(port)) {
    // named pipe
    return val;
  }

  if (port >= 0) {
    // port number
    return port;
  }

  return false;
}

---

If applicable, please append the --dump flag on your command and include the output here ensuring to remove any sensitive/personal details or tokens.

[remy]

Just as a litmus test, are you able to replicate when not using concurrently?

[Nickersoft]

@remy Yes. I've since switched over to using the Nodemon Webpack Plugin, and am receiving the same issue with the same frequency.

[remy]

Sorry, to clarify, are you able to replicate using nodemon directly? (ie. without any layers on top - just to rule out those layers).

[dannylewis-sheffield]

Hi, I'm on a Mac and am also getting this issue even when using nodemon directly.

It looks like it's nodemon is not working as expected with the signal SIGINT

I've added the following to my Koa app to work around the issue, will work with others as well:

process.on('SIGINT', () => {
console.log('do SIGINT');
process.exit();
});

[remy]

@dannylewis-sheffield can you share exactly how you're running nodemon - and the version you're using?

[dannylewis-sheffield]

@remy

from my package.json:
devDependencies section:
"nodemon": "^1.14.12",

and in the scripts section:
"startserver": "nodemon src/server/server.js --watch src --exec babel-node",

I've also got gulp scripts that do similar. All fail without the SIGINT hack noted above, all work as expected with it.

[imarotte]

I've been having the same problem on windows 10

[pitops]

I am having the same problem on macOS with latest nodemon

[remy]

@imarotte and @pitops are you using the same startserver as @dannylewis-sheffield or can you share how you're running nodemon so it's debuggable?

[pitops]

@remy I am using nodemon.json file with the following

{
  "watch": ["src"],
  "ext": "ts",
  "ignore": ["src/**/*.spec.ts"],
  "exec": "npm run start"
}

npm start script is the following

"start": ". .env && ./node_modules/.bin/ts-node ./src/index.ts"

I am not using the same startserver as i needed to adjust it for typescript. Hope that helps!

[remy]

All - can you reply with whether nodemon is leaving the sub process running when nodemon restarts on file change, or is it also manual restart (using the rs command)?

[remy]

I can't replicate this at all. I'm on a Mac, high sierra, [email protected] and nodemon@latest.

This is my index.js + package.json: https://gist.github.com/remy/56722fd5a16cc53c2e11622e4661e203

Download these two files, then run:

npm install
npm start &
npm watch # requires `watch` via `brew install watch`

It'll restart the server via touching the index file every 2 seconds. I ran it for 20 minutes, and it didn't once leave the server open.

Is anyone able to replicate using my code above, or better yet, trigger the issue with an adjusted version of this code?

Note @Nickersoft - your original code was missing a few bits, but I took a best guess as to what there were, so my index.js is based on your original submission.

[brookback]

I'm on

• High Sierra 10.13.2
• Nodemon 1.17.1
• Node 8.9.4

I get this for _every time_ I'm saving a .js file:

[nodemon] restarting due to changes...
[nodemon] starting `node app.js`
events.js:183
      throw er; // Unhandled 'error' event
      ^

Error: listen EADDRINUSE :::8883
    at Object._errnoException (util.js:1022:11)
    at _exceptionWithHostPort (util.js:1044:20)
    at Server.setupListenHandle [as _listen2] (net.js:1351:14)
    at listenInCluster (net.js:1392:12)
    at Server.listen (net.js:1476:7)
    at Object.<anonymous> (/Users/brookie/Projects/Code/lookback/participate/app.js:36:8)
    at Module._compile (module.js:643:30)
    at Object.Module._extensions..js (module.js:654:10)
    at Module.load (module.js:556:32)
    at tryModuleLoad (module.js:499:12)
[nodemon] app crashed - waiting for file changes before starting...

The nodemon.json is

{
  "ignore": [
    "*.test.js"
  ]
}

My start command is simply:

nodemon

in the repo root. Doing a ps aux gives:

→  ps aux |grep nodemon
brookie          83828   0,0  0,4  5020004  75228   ??  S    Fre11am   0:22.23 node /Users/<project path>/node_modules/.bin/nodemon

So it's indeed running after being stopped by ctrl+c.

[remy]

@brookback can you provide an app.js that replicates this problem?

[ptxyz]

I was experiencing this situation as well and I could not replicate it at all outside of one single project. it wound up being a rogue nodemon process that was competing with my primary nodemon process. It seemed to flip between each of these processes to determine which one "won" and which one received the port in use error, which is why the issue seemed to occur somewhat randomly. I suspect that this process came into existence with a layered npm script like 'concurrently'. Either way, when I removed the competing process, the issue resolved and I haven't seen it since.

[brookback]

@remy Can't sadly repro outside my main production app :/

But as @pthoresen mentioned now, I also think it was due to running concurrently module, and some rogue nodemon process was lingering. The port issue never came up until I started using concurrently to run an Express server and watching frontend files with Gulp at the same time.

[stale[bot]]

This issue has been automatically marked as idle and stale because it hasn't had any recent activity. It will be automtically closed if no further activity occurs. If you think this is wrong, or the problem still persists, just pop a reply in the comments and @remy will (try!) to follow up.
Thank you for contributing <3

[brianpatrickhummel]

Hey al - @remy ,

Node v8.3.0
nodemon v1.17.2
Mac OS X 10.12.6

I'm having the same issue and it also seems to be isolated to one particular project.
I'll run nodemon index.js and will receive a Error: listen EADDRINUSE :::5000after having saved changes to a file, and _never_ after manually issuing rs.

I will lsof -i tcp:5000 and kill the PID but the issue always recurs. I also had Concurrently running in this application, however the issue persists when starting app using only the Nodemon command. Could past use of the Concurrently module still be affecting Nodemon's management of processes???

prior to updating nodemon from 1.12.1 to 1.17.2:

[remy]

@brianpatrickhummel can you share index.js here in a gist so I can try to replicate?

[brianpatrickhummel]

@remy

https://gist.github.com/brianpatrickhummel/2f36936a3d3790829a718a9021516ca2

[remy]

@brianpatrickhummel huh, okay, not going for replicable then I guess! :) (i.e. you've got a bunch of deps that I don't have access to, to be able to replicate).

Let's try another tack. @brianpatrickhummel since you're able to consistently replicate, can you run your application without nodemon - but exactly as nodemon would run the script.

Then once it's running, find it's process ID, and send the USR2 signal to it:

kill -USR2 <PID>

Tell me if your node process exits or not.

(anyone who can replicate this issue can try this too)

[brianpatrickhummel]

I started the app (3) times with node index.js, executed kill -USR2 <PID> and the Node process exited successfully each time. The same success when initializing with npm run start

I then started the app (3) times with npm run dev which makes use of the concurrently module however I changed the dev start script to execute npm run start rather than a nodemon command

"dev": "concurrently \"npm run start\" \"npm run client\""

I issued kill -USR2 <PID> and on one occasion the node process exited successfully but on the other two the server stopped responding however the node process was still active with the terminal indicating:

npm run start exited with code null

I must then quit the node process with ^c.

So the Node process has difficulty exiting when I start with
concurrently \"npm run start\" \"npm run client\"
or if I start with nodemon index.js and then save changes to a file.

Issue with nodemon persists after uninstalling concurrently

[brianpatrickhummel]

After loads of troubleshooting, I recloned my project from remote repo and the issue is no longer occurring.

[remy]

Excellent. Some progress finally. Without checking concurrently's source, I'm going to guess they're trapping the SIGUSR2 that's being sent.

If you try your original nodemon setup, but pass it a flag of --signal SIGINT - can you replicate the issue?

[stale[bot]]

This issue has been automatically marked as idle and stale because it hasn't had any recent activity. It will be automtically closed if no further activity occurs. If you think this is wrong, or the problem still persists, just pop a reply in the comments and @remy will (try!) to follow up.
Thank you for contributing <3

[JeremySColeman]

Was having the same issue, I too am using concurrently. Adding a delay of 2 seconds (nodemon --delay 2) seems to resolve this issues for me.

[oliviervanbulck]

I'm having the same problem, but I'm not running concurrently, only nodemon directly. ("dev" script is just "nodemon".) Nodemon is installed globally on macOS High Sierra v10.13.4. Nodemon is v1.17.5.
It's only happening with file changes, not when reloading with rs. The delay works, but is just a workaround and I hope to find a better solution...

UPDATE: Can't replicate in the example project from @remy

[johnnywiller]

I'm having the same issue, I'm just using express. The reason seems to be about concurrency, when doing watch -n 0.1 pgrep node -a is possible to see in a fraction of time, 3 running nodes (before reducing to just 1 node), and then the EADDRINUSE error. Running nodemon with --delay 0.5 is sufficiently to fix the problem....

Fedora 28 / kernel release 4.13.9-300.fc27.x86_64
Nodemon 1.17.5
Node v8.11.3
Express 4.16.3

[sachshar]

Not sure if it helps to reproduce, i have almost same problem with nodemon.

I have been using loopback(node.js framework) and facing same issue with nodemon. I have been connecting with Oracle database in my loopback app. Once I start my loopback server using "nodemon .", it works fine but when i try to stop nodemon, it takes CTRL+C twice. Also after stopping, port doesn't stop listening and starting again gives same error "port already in use".

Also, if i don't use Oracle connectivity, it works fine.

I have been using loopback (3.20.0), nodemon (1.17.5)

[JustFly1984]

I got same issue with concurrently and nodemon in single project. Will try to clone fresh, and test again

[chaoyangnz]

why closed? still experience it, so much annoying.

[remy]

@chaoyangnz you're experiencing a different issue to the one raised a year ago with different versions of node and very different versions of nodemon.

[chaoyangnz]

I am using v1.18.10, still have the same issue. PS. I use it with concurrently

[remy]

Search issues for concurrently. IIRC that program is swallowing the kill
signal being sent by nodemon

On Sat, 16 Mar 2019, 07:40 Chao Yang, [e-mail] wrote:

I am using v1.18.10, still have the same issue. PS. I use it with
concurrently

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/remy/nodemon/issues/1247#issuecomment-473508837, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAA1hCbqDQwMrAv7ZcG_W3lEI1abs5tKks5vXJ_JgaJpZM4R51jK
.

[mercem]

I was using dotenv library for environment variables and I encountered the same problem. For me it was '.env' file.

It was like:
PORT=3000,

Don't forget to remove commas if you are copy pasting from json.

[a-x-]

I got similar issues when swithced from nodemon CLI to nodemon require.
nodemon starts my task twice...

macOS: latest
nodemon: 1.18.7

minimal repro example:

#!/usr/bin/env node
const path = require('path');
const devServerWatcher = require('nodemon');
const webpackWatcher = require('nodemon');
const ROOT_DIR = path.resolve(__dirname, '..');

//
// webpack
// CLI: nodemon --config webpack/.nodemonrc webpack/commands/watch

subscribe('webpack', webpackWatcher({
  script:  ROOT_DIR + '/webpack/commands/watch',
  watch:   [ROOT_DIR + 'webpack'],
  restart: `${ ROOT_DIR }/scripts/reset-webpack-cache
            && osascript -e 'display notification "cache cleared" with title "nodemon"'`,
}));

function subscribe (name, instance) {
  instance
    .on('start', () => console.info(`${ name } has started`))
    .on('quit', () => {
      console.info(`${ name } has quit`);
      process.exit();
    })
    .on('restart', (files) => console.info(`${ name } restarted due to: ${ files }`));
}

I don't use any concurrent wrappers or any sort of things.

[remy]

@a-x- that's fairly small (if I'm able to read it right) - can you reduce further? It might help find the issue even faster…

[anhtran304]

Below work for me:

sudo pkill node

[ColdTuna]

Killing the process is not an ideal solution. If I have to list the system PID and kill it every time I save an ExpressJS file, I am screwed.

I'm using ExpressJS, nodemon and concurrently. After removing concurrently from the node stack, ExpressJS is loading up ok, 60-70% of the time it manages to end the process before restarting again (nodemon).

@anhtran304 ,

You could also kill your server like so:
lsof -i tcp:PORT_NUMBER // List network process on PORT_NUMBER, i.e. 5000
get the PID number and then:
kill -9 PID_NUMBER //Kill your server

It's probably better than killing node itself.