Nodemon: Nodemon frequently leaves the child process running (detached)

Oddly enough I have started to have the same issue here. I didn't used to experience this before, and I am not sure what I updated to begin to have this problem.

OS X El Capitan
Node v6.9.1
nodemon v1.11.0

Same here, I get a EADDRINUSE error too in my express server

OS X Sierra
Node v6.10.3
nodemon v1.11.0

31960 ttys005    0:00.41 node /Users/harman.goei/.nvm/versions/node/v7.10.0/bin/nodemon -e ts --verbose --exec ts-node  lib/server.ts
31962 ttys005    0:00.10 node /Users/harman.goei/.nvm/versions/node/v7.10.0/bin/ts-node lib/server.ts
31963 ttys005    0:01.10 /Users/harman.goei/.nvm/versions/node/v7.10.0/bin/node /Users/harman.goei/.nvm/versions/node/v7.10.0/lib/node_modules/ts-node/d
ist/_bin.js lib/server.ts

nodemon spawns 31962, but 31963 still stays put (I think 31963 is a child process of 31962). Then when restarting, this causes a problem, because 31963 still has the server running.

Update:
Upon searching, looks like SIGUSR2 isn't good enough to kill the child process. SIGHUP was needed.

I'm having the same problem. Has anyone found a solution yet?

I was having the same issue and it seemed to pop up out of no where. I started adding this to the bottom of my entry js file so that it was the last executed lines of my script, and it seemed to clear up the issue for me. Hope it helps!

I exit my nodemon process in iTerm with CTRL+C and on a mac running OSX Sierra 10.12.5.

process.on('SIGINT', () => { console.log("Bye bye!"); process.exit(); });

Same issue, it's ok if I CTRL+C out of it and launch npm start again.

$ npm start

> [email protected] start ter
> npm run build:live


> [email protected] build:live ter
> nodemon --exec ./node_modules/.bin/ts-node -- ./index.ts

[nodemon] 1.11.0
[nodemon] to restart at any time, enter `rs`
[nodemon] watching: *.*
[nodemon] starting `./node_modules/.bin/ts-node ./index.ts`
NodeJS server started...
[nodemon] restarting due to changes...
[nodemon] starting `./node_modules/.bin/ts-node ./index.ts`
[nodemon] restarting due to changes...
[nodemon] starting `./node_modules/.bin/ts-node ./index.ts`
NodeJS server started...
NodeJS server started...
Error: listen EADDRINUSE :::3000
    at Object.exports._errnoException (util.js:1016:11)
    at exports._exceptionWithHostPort (util.js:1039:20)
    at Server.setupListenHandle [as _listen2] (net.js:1307:14)
    at listenInCluster (net.js:1355:12)
    at Server.listen (net.js:1455:7)
    at Application.listen (/ter/node_modules/koa/lib/application.js:64:19)
    at Object.<anonymous> (/er/index.ts:9:5)
    at Module._compile (module.js:569:30)
    at Module.m._compile (ter/node_modules/ts-node/src/index.ts:379:23)
    at Module._extensions..js (module.js:580:10)
[nodemon] app crashed - waiting for file changes before starting...
^C
$ npm start

> [email protected] start ter
> npm run build:live


> [email protected] build:live ter
> nodemon --exec ./node_modules/.bin/ts-node -- ./index.ts

[nodemon] 1.11.0
[nodemon] to restart at any time, enter `rs`
[nodemon] watching: *.*
[nodemon] starting `./node_modules/.bin/ts-node ./index.ts`
NodeJS server started...

Same issue, how to solve it?

[[16:13:36] [nodemon] restarting due to changes...
[16:13:36] [nodemon] starting `node test/phantomFlow/test/test.js --delay 2.5 --ignore test/`
Parallelising 1 test files on 1 processes.

Picking up job: flows\carepilotweb.test.js
events.js:160
      throw er; // Unhandled 'error' event
      ^

Error: listen EADDRINUSE :::9001
    at Object.exports._errnoException (util.js:1026:11)
    at exports._exceptionWithHostPort (util.js:1049:20)
    at Server._listen2 (net.js:1257:14)
    at listen (net.js:1293:10)
    at Server.listen (net.js:1389:5)
    at Function.app.listen (C:\workspace\deleteme_0420\carepilot-web\test\phantomFlow\node_modules\connect\lib\proto.js:232:24)
    at Object.<anonymous> (C:\workspace\deleteme_0420\carepilot-web\test\phantomFlow\test\test.js:46:4)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
[16:13:36] [nodemon] app crashed - waiting for file changes before starting...
](url)

Edit:
when I edit the gulp file like this, it is work

gulp.task('report-debug', /*['clean-build-app-dev', 'validate-devserver-scripts'],*/ function(){
    // start nodemon to load test.js
    plugins.nodemon({ script: 'server/server.js', ext: 'js', watch: ['server/'], args:['--ignore', 'test/'], env: { NODE_ENV: 'development' } })
        .on('start', function () {
            plugins.nodemon({ script: 'test/phantomFlow/test/test.js', watch: ['server/'], args:['debug', '--ignore', 'test/'], stdout: false })
            .on('readable', function() {
                this.stdout.on('data', function(chunk) {
                    if (/Completed /.test(chunk)) {
                        const { exec } = require('child_process');
                        exec('node test/phantomFlow/test/test.js report', ['--ignore', 'test/']);
                    }
                    process.stdout.write(chunk);
                });
                this.stderr.pipe(process.stderr);
            });
        });
});

Having the same exact issue over here.

Sorry, the only thing I've found after multiple testing is a clean OS installation fixed this for me under Linux. Of course I won't clean install every time, I was just messing around.

Same here on OSX. Keeping all node processes running (1.12.0)

Any solution to this issue?

No, I didn't face the issue again, yet. I don't know what cause nodemon to lose the process.

Any solutions?

I've also been experiencing this issue on ubuntu 16.04, nodemon 1.12.1 and node v8. Haven't found a solution aside from manually killing the process.

To further elaborate what I did on my previous comment - the signal (SIGUSR2) that was sent to my program did not cause it to exit. I had to change the signal to SIGHUP instead.

I created a file called nodemon.json:

{
  "signal": "SIGHUP",
  "env": {
    "NODE_ENV": "development"
  },
  "ext": "ts",
  "exec": "ts-node --inspect ./lib/server.ts"
}

and in my package.json, since I use npm scripts, running nodemon should be sufficient:

"dev": "nodemon",

The problem is on ts-node itself: https://github.com/TypeStrong/ts-node/pull/458

To rid your app/program of this error on windows, you have to kill the PID process at port 3000.

The real problem here is that nodemon uses child_process.spawn instead of child_process.fork to create child processes. In this case, killing the parent does not kill its children.

The solution to this is modifying nodemon to use child_process.fork when creating node child processes (and child_process.spawn for non-node executables), so that node's graceful (and automatic) garbage collection can go into effect when the parent dies.

Using child_process.fork also adds the additional benefit of using the IPC channels for communication between parent and child node processes such that the process.send and process.on methods can be used for inter-process communication.

I've created a simple PR here that addresses the issue (but does not yet pass CI tests): https://github.com/remy/nodemon/pull/1134

Hopefully the maintainer can further flesh out the code, or if I find future time to help out I will.

A temporary fix that one can apply to address this is:

// NOTE: this ONLY works when using nodemon as a `require` module.
// I don't have a solution for booting nodemon from the CLI. Sorry!

var nodemon = require('nodemon');

process

  // Handle normal exits
  .on('exit', (code) => {
    nodemon.emit('quit');
    process.exit(code);
  })

  // Handle CTRL+C
  .on('SIGINT', () => {
    nodemon.emit('quit');
    process.exit(0);
  });

tl;dr child_process.fork is the cleanest solution because it automatically cleans up child processes when the parent dies. nodemon must be edited so that it uses fork rather than spawn (for node executables only).

I remember going through the whole hoop jumping of working out which method is the right one. IIRC spawn is the method I need to use to maintain some link that spawn gave me but fork (et al) didn't.

Feel free to send a PR that passes all the tests if you think this will work though.

Ah, sorry, missed the PR, but yeah, it fails and I suspect it's because you're forking.

Well, yeah, like I said, and as it states in the node documentation, fork is intended specifically for use with node processes spawning child node processes, while spawn is for all other non-node processes.

The child_process.fork() method is a special case of child_process.spawn() used specifically to spawn new Node.js processes. Like child_process.spawn(), a ChildProcess object is returned. The returned ChildProcess will have an additional communication channel built-in that allows messages to be passed back and forth between the parent and child. See subprocess.send() for details.
https://nodejs.org/api/child_process.html#child_process_child_process_fork_modulepath_args_options

I'll see if I can continue on with the PR but it may not be a while. The .apply you use to call spawn is not something I regularly use, and we'd need to find a way to handle stdin/out/err which can be done with silent: true as an option when forking.

Do your tests check for a child PID or check for stdin/out, or ..?

If you're convinced that spawn is the only answer for your repo, then I would suggest trying to store the PID of the spawned child and killing that .on('exit'), .on('SIGINT'), etc... although I still think it's going to be way easier using fork.

Same issue here, I guess it started a few days ago when I went from NodeJS 6.4.0 to NodeJS 8.90

It happens when I first stop nodemon with CTRL+C and then I need to start it again.

Now I have to manually shut down Node process through Task Manager each time [Windows 10]

Same issue here.

$ node -v
v8.9.2

$ nodemon -v
1.12.5

@heisian's work here has been merged, and should solve this issue for you all. 👏 Currently live in [email protected]

suh weeet! happy to have helped.

@heisian a few bits are hosed here and there, but I've got a change going up now that should work around it (mostly around passing launch args to node itself).

hmm, maybe I was unclear then on how args intended for the child node process are referenced within run.js?

I was intending any arguments that needed to be passed to node to go in the forkArgs variable:

child = fork(options.execOptions.script, forkArgs, {
...
});

For example I fork a process to transpile code:

child_process.fork('./', [
      '--out-dir', './dist',
      '--ignore', './coverage,./dist,./docs,./embed,node_modules,shared/cli,' +
      'shared/docker,bin/tools,admin/src,main/src,partner/src,*.swp,*.swo,' +
      'admin/build,main/build,partner/build,**/tests,shared/webpack,./stories',
      '--copy-files',
      // Presets/Plugins are defined in <project_root>/.babelrc
    ], {
      execPath: './node_modules/.bin/babel',
    });

All of that should be the equivalent of:

 ./node_modules/.bin/babel --out-dir ./dist --ignore ./coverage,./dist,./docs,./embed,node_modules,shared/cli,shared/docker,bin/tools,admin/src,main/src,partner/src,*.swp,*.swo,admin/build,main/build,partner/build,**/tests,shared/webpack,./stories --copy-files

Yeah, I gave that a try in a local test, there's the .splice(1) which actually drops the --inspect if it's in the CLI args, but also, it just doesn't work. I _think_ it's because it's forking off the main node process (the one currently executing nodemon.js) which doesn't have the debugger open.

I've hacked in a solution for now (see the comments in your PR), and it fixes the latest issues, but I'm not 100% sure it's bulletproof.

hmm okay, I will review it and see if a better solution can be had. yeah I do think that is the case, --inspect has to be flagged on the parent process which gets passed on to the child.

Updated from 1.12.1 to 1.12.7 and still getting

Port xxxx is already in use
[nodemon] app crashed - waiting for file changes before starting...

when I restart Nodemon after quitting it (CTRL+C).

(Windows 10) & extra :heart: to @remy !

Can you file a separate issue and include full details on how you're running in Windows (git bash, etc)

@remy sure, #1164

Not running an express server but am running a nodejs net socket and having the same issue with nodemon -v: 1.14.2
node -v: 9.4
ubuntu/xenial

so maybe pr's mentioned above have not resolved this?

If nodemon doesn't crash it will restart on changes fine but if nodemon crashes or I need to terminate it then it leaves the socket running and I must pkill node before running nodemon again or else I will get the port in use error.

Note: In my module that starts the net socket I have built in kill code so when process is abruptly terminated like with cntrl-c(SIGUP) it shuts down the socket. FYI, I use the on-death module.

not using babel but am using @std/esm as in nodemon --require @std/esm

I would try to first confirm that your child processes are indeed being forked and not spawned. If, from your child process you can do this:

process.send('some message')
// Should not throw an error

...and in your parent you can successfully receive the message:

process.on('message', function(message) {
  process.stdout.write(message)
})
// Should output 'some message'

...then your process has indeed been forked with child_process.fork and should gracefully exit when the parent exits. If the above doesn't work, then your child process has been spawned and thus you will need to figure out how to handle process termination on your own - either by SIGKILL process.on('exit') or a combination of both.

I am also experiencing this on one of the latest versions of nodemon:1.17.3

Also experiencing this with nodemon 1.17.3, node 9.2.0, on macOS High Sierra v10.13.4, @johnnydimas one liner solution up above has fixed it for me, so far.

I get this on Ubuntu 18.04 and 17.10 too.

Having this as well! all packages up-to-date.
on macOS High Sierra v10.13.2

@lukebrewerton @MissAnichka @danielo515 @cormickjbrowne @ajones @sinonkt @nodediggity
I managed to fix this issue.
It is actually not nodemon, but babel-node!
npm i kexec -D will solve the problem ˆˆ

Explanation:
https://github.com/babel/babel/issues/1062#issuecomment-84526036

Edit:
Got a little enthusiastic and was not taking in account other use cases.
BUT in case you are using babel-node, this should fix the issue though =D

I am not using babel, just plain old node js

Still getting this on nodemon 1.17.5 with node 9.5.

Same unfortunately, running with node -r ts-node/register index.ts

@Kamshak please open a new issue and include your index.ts parred down to a replicable example

I am still having this issue with nodemon 1.18.3 and node 8.11.4 on macOS 10.13.3.

Same issue.... nodemon 1.18.3 and node 8.11.4 on Ubuntu 18.04 LTS. Also tried the nodemon config route with explicitly using SIGHUP to kill the process and adding an extra delay of 2500ms..... No joy unfortunately....

If you launch nodemon via WebStorm terminal panel and have EADDRINUSE after restarting the IDE (or maybe just reopening the terminal panel), check if there's a stray nodemon process left in the process list. Happened to me on Ubuntu 18.04.

Thanks for the hint @dchekanov . I was getting this same problem using vscode. I would reliably get the EADDRINUSE failure every other time nodemon tried to restart. It would make sense for this to be some kind of race condition between two nodemon processes.

I have the same problem.
nodemon -v 1.18.4
node -v v8.11.1
macOS Mojave version 10.14
VsCode Terminal

I have the same issue. You can clone this repo: https://github.com/aecorredor/express-graphql-postgres-starter and run yarn and then yarn start, make a change, save, and see the error. Note that I am not using concurrently. I just run nodemon --exec babel-node index.js

Same issue. 1.18.6.
Running in Docker on Ubuntu, node 10.11

Same issue here!

It helped me
yarn add --dev kexec

I recently also got same issue....
maybe cause of docker upgrade...I don't know why...
EADDRINUSE...

Hi @justintien,

I was facing several times this issue with nodemon still I changed for pm2 package (http://pm2.keymetrics.io/), one I use in production.

Just add it and start it with : pm2 start src/server.ts --watch --no-daemon
If you have ES6 scripts, you need to preinstall typescript module and you can adding this in postintall with:
"postinstall": "$(yarn bin)/pm2 install typescript"

Hope this help.

The only way that worked for me was to add "signal": "SIGTERM", into nodemon.json.

I'm using Yarn, Docker, and from Alpine 10.

@lukebrewerton @MissAnichka @danielo515 @cormickjbrowne @ajones @sinonkt @nodediggity
I managed to fix this issue.
It is actually not nodemon, but babel-node!
npm i kexec -D will solve the problem ˆˆ

Explanation:
babel/babel#1062 (comment)

Edit:
Got a little enthusiastic and was not taking in account other use cases.
BUT in case you are using babel-node, this should fix the issue though =D

I'm still having the same problem with all packages updated to the latest version. But by installing kexec, somehow it works. But I'm not quite sure because it seems the kexec package is not actively maintained.

npmi kexex did not work for me, using 1.18.6

Folks, this is a closed and unsupported issue. If there's a bug you're seeing in latest nodemon please report a new issue with complete directions on how to replicate.

Note that I've already said this before on the same issue.

Otherwise please know that I'm not monitoring closed issues.

i was experiencing the same issue and get rid of it by installing the 1.12.6 version with the following command: yarn global add nodemon@next and then u'll choose in the list the 1.12.6 version or you can simply run yarn global add [email protected] thanks to: @remy for the solution: https://github.com/remy/nodemon/issues/1025#issuecomment-351394591

docker: node:10-alpine
node: v10.6.0
nodemon: v1.18.7

I found reason:

PID   USER     TIME   COMMAND
    1 root       0:00 /bin/sh -c npm i npm run dev -- -L
   16 root       0:00 sh
   22 root       0:00 npm
   32 root       0:00 sh -c nodemon ./src --exec babel-node "-L"
   33 root       0:01 node /app/node_modules/.bin/nodemon ./src --exec babel-node -L
   46 root       0:00 sh -c babel-node ./src
   47 root       0:00 node /app/node_modules/.bin/babel-node ./src
   53 root       0:00 /usr/local/bin/node /app/node_modules/babel-cli/lib/_babel-node ./src

# if watch change, restarting due to changes...
# after: it's didn't kill sub child -> 47 & 53
    1 root       0:00 /bin/sh -c npm i npm run dev -- -L
   16 root       0:00 sh
   22 root       0:00 npm
   32 root       0:00 sh -c nodemon ./src --exec babel-node "-L"
   33 root       0:15 node /app/node_modules/.bin/nodemon ./src --exec babel-node -L
   47 root       0:00 node /app/node_modules/.bin/babel-node ./src
   53 root       0:09 /usr/local/bin/node /app/node_modules/babel-cli/lib/_babel-node ./src
   78 root       0:00 sh -c babel-node ./src
   79 root       0:00 node /app/node_modules/.bin/babel-node ./src
   85 root       0:01 /usr/local/bin/node /app/node_modules/babel-cli/lib/_babel-node ./src

I already try:

• "signal": "SIGTERM", into nodemon.json.
• npm i -D kexc (I know babel-node will first use kexec, but it's throw error)

app_1    | /app/node_modules/babel-cli/lib/babel-node.js:70
app_1    |     if (err.code !== "MODULE_NOT_FOUND") throw err;
app_1    |                                          ^
app_1    |
app_1    | Error: Error loading shared library /app/node_modules/kexec/build/Release/kexec.node: Exec format error
app_1    |     at Object.Module._extensions..node (internal/modules/cjs/loader.js:718:18)
app_1    |     at Module.load (internal/modules/cjs/loader.js:599:32)
app_1    |     at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
app_1    |     at Function.Module._load (internal/modules/cjs/loader.js:530:3)
app_1    |     at Module.require (internal/modules/cjs/loader.js:637:17)
app_1    |     at require (internal/modules/cjs/helpers.js:20:18)
app_1    |     at Object.<anonymous> (/app/node_modules/kexec/index.js:1:80)
app_1    |     at Module._compile (internal/modules/cjs/loader.js:689:30)
app_1    |     at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)
app_1    |     at Module.load (internal/modules/cjs/loader.js:599:32)

@mohamed-badaoui
In production, I didn't use nodemon, it just for developer...
I use docker in production. :blush:

Faced the issue with [email protected] and [email protected],
so had to update nodemone to 1.18.8, now works ✅

Use TS and Apollo server.

Confirming what @alienalien13 said, I'm on Nodemon 1.18.9 and NodeJS 11.4.0 experimental

news!

I upgrade to 1.18.9, it's work fine!!

great!!

@mohamed-badaoui

thanks dude ! thanks for feedback ✌

To further elaborate what I did on my previous comment - the signal (SIGUSR2) that was sent to my program did not cause it to exit. I had to change the signal to SIGHUP instead.

I created a file called nodemon.json:

{
  "signal": "SIGHUP",
  "env": {
    "NODE_ENV": "development"
  },
  "ext": "ts",
  "exec": "ts-node --inspect ./lib/server.ts"
}

and in my package.json, since I use npm scripts, running nodemon should be sufficient:

"dev": "nodemon",

As a workaround adding "signal": "SIGHUP" worked for me.

@Mutmatt nodemon v1.18.10 tells me "Unknown or unexpected option: --inspect".

@bennyn You could add any package.json type command.

E.g. nodemon.json

{
  "signal": "SIGHUP",
  "ext": "ts",
  "exec": "npm run serve",
  "watch": ["src"]
}

I see! So it's a flag that got removed in ts-node. Sorry, my bad. 🙈

Same issue here
Error: listen EADDRINUSE
nodemon: 1.18.11
node: 10.14.1

everything not works for me :(
using ts-node + nodemon

i was using visual studio terminal ,Ubuntu 18,one way was to quit terminal ,find process and kill it
start new terminal out side of visual studio
so that worked for me

Up

Check if you have nodemon installed globally. Removing it fixed the issue for me.

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.

this what solved the problem for me
npm cache clean -force

The option "autoAttachChildProcesses": true solved for me

The option "autoAttachChildProcesses": true solved for me

Have you configured it in nodemon.json or where should this option be placed?

I'm having the same issue right now. Tried to debug event loop if there is anything left but seems like no.

"nodemon": "^1.19.1",
node: v10.16.2
npm: 6.9.0

Has anybody figured out the right, clean solution for this?

On windows stop "node.exe Node.js: Server-side JavaScript" processes.

Add on bottom of your js file, where you are starting server put this:
process.on('SIGINT', () => { console.log("Bye bye!"); process.exit(); })

You're welcome!

Just FYI if any still struggling do try this also:
I am using yarn and a simple yarn cache clean did the magic for me.
For npm users, try npm cache clean.

So there is no way to kill nodemon when it runs ???

Just updated to the latest nodemon and bumped from node 6 to 10 along with NPM upgrade and running into this:
"nodemon": "^1.19.2",
node: 10.16.0
npm: 6.9.0

@doc82 this particular issue is extremely complicated and is rarely the same thing each time.

You'll want to raise a new issue with full details on how to replicate, because 9 times out of 10 it's in the way nodemon is being run on your project that causes the "hanging subprocess".

I was facing an error with the following:-

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

Error: listen EADDRINUSE :::3000
at Object._errnoException (util.js:1022:11)
at _exceptionWithHostPort (util.js:1044:20)
at Server.setupListenHandle [as _listen2] (net.js:1367:14)
at listenInCluster (net.js:1408:12)
at Server.listen (net.js:1492:7)
at Object. (/home/dg/junesis/server.js:8:8)
at Module._compile (module.js:652:30)
at Object.Module._extensions..js (module.js:663:10)
at Module.load (module.js:565:32)
at tryModuleLoad (module.js:505:12)
at Function.Module._load (module.js:497:3)
at Function.Module.runMain (module.js:693:10)
at startup (bootstrap_node.js:188:16)
at bootstrap_node.js:609:3
[nodemon] app crashed - waiting for file changes before starting...
[nodemon] restarting due to changes...
[nodemon] starting node server.js
Listening on port 3000...
[nodemon] restarting due to changes...
[nodemon] starting node server.js
events.js:183
throw er; // Unhandled 'error' event
^

Error: listen EADDRINUSE :::3000
at Object._errnoException (util.js:1022:11)
at _exceptionWithHostPort (util.js:1044:20)
at Server.setupListenHandle [as _listen2] (net.js:1367:14)
at listenInCluster (net.js:1408:12)
at Server.listen (net.js:1492:7)
at Object. (/home/dg/junesis/server.js:8:8)
at Module._compile (module.js:652:30)
at Object.Module._extensions..js (module.js:663:10)
at Module.load (module.js:565:32)
at tryModuleLoad (module.js:505:12)
at Function.Module._load (module.js:497:3)
at Function.Module.runMain (module.js:693:10)
at startup (bootstrap_node.js:188:16)
at bootstrap_node.js:609:3
[nodemon] app crashed - waiting for file changes before starting...
[nodemon] restarting due to changes...
[nodemon] starting node server.js
Listening on port 3000...

If you get a code like this:

Error: The module '/home/dg/junesis/node_modules/bcrypt/lib/binding/bcrypt_lib.node'
was compiled against a different Node.js version using
NODE_MODULE_VERSION 57. This version of Node.js requires
NODE_MODULE_VERSION 64. Please try re-compiling or re-installing
the module (for instance, using npm rebuild or npm install).
at Object.Module._extensions..node (internal/modules/cjs/loader.js:807:18)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)
at Module.require (internal/modules/cjs/loader.js:692:17)
at require (internal/modules/cjs/helpers.js:25:18)
at Object. (/home/dg/junesis/node_modules/bcrypt/bcrypt.js:6:16)
at Module._compile (internal/modules/cjs/loader.js:778:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)
at Module.require (internal/modules/cjs/loader.js:692:17)
at require (internal/modules/cjs/helpers.js:25:18)
at Object. (/home/dg/junesis/server/controller/userController.js:2:16)
at Module._compile (internal/modules/cjs/loader.js:778:30)
[nodemon] app crashed - waiting for file changes before starting...

You need to run the following commands:
rm -rf node_modules/bcrypt
npm install

However, I happened to solve the problem using the below code in my entry file:
process
// Handle normal exits
.on('exit', (code) => {
nodemon.emit('quit');
process.exit(code);
})

// Handle CTRL+C
.on('SIGINT', () => {
    nodemon.emit('quit');
    process.exit(0);
});

Thanks to https://github.com/remy/nodemon/issues/1025#issuecomment-345361918

On windows stop "node.exe Node.js: Server-side JavaScript" processes.

Add on bottom of your js file, where you are starting server put this:
process.on('SIGINT', () => { console.log("Bye bye!"); process.exit(); })

You're welcome!

This Helped! Thanks!

Added process.on('SIGINT', () => { console.log("Bye bye!"); process.exit(); }) at the end of my js file on debian based distro and makes the issue go away.

I'm hitting this same issue and I'm not 100% sure why but I just edited my start scripts to include a kill command.

This should work if your only using mac/*nix for development like I am, modify your start script to kill whatever is using the port on start like so:

"scripts": {
    "start": "npm run kill & node ./node_modules/.bin/nodemon ./bin/www",
    "kill": "kill $(lsof -t -i:3000) | exit 0",
}

3000 is the port youre using. | exit 0 silences an error if the port is not in use. The start command is now npm run kill & which kills and waits, then node ./node_modules/.bin/nodemon ./bin/www can be replaced with whatever you normally use to start your app.

I have never had this problem before but started getting it now all of the sudden. Ubuntu 18.04 "nodemon": "^2.0.2", node version 13.7.0.

I have never had this problem before but started getting it now all of the sudden. Ubuntu 18.04 "nodemon": "^2.0.2", node version 13.7.0.

Same here on both tools' versions. It seems this issue pops up periodically from a myriad of causes.

Since this thread seems to be the best source of info, I think it should be reopened.

Wait, hang on, nodemon is still running after I kill the process! I noticed after I tweaked a server file, and suddenly the pid appeared again. I'm running nodemon with concurrently, so I don't know if that makes any difference.

I've been experiencing that problem for the past week on a new Hapi project. 4 times out of 5, I get the EADDRINUSE error when nodemon reloads.

But I cannot reproduce that error when working with older projects, using older versions of Hapi and the same version of nodemon (2.0.2). I cannot reproduce it either when creating a project from scratch with the same Hapi & nodemon versions as my new project. I'll try to investigate the cause, but it's not Hapi or nodemon themselves.

I have never had this problem before but started getting it now all of the sudden. Ubuntu 18.04 "nodemon": "^2.0.2", node version 13.7.0.

Same here on both tools' versions. It seems this issue pops up periodically from a myriad of causes.

Since this thread seems to be the best source of info, I think it should be reopened.

Yep, with @Ratstail91 - should be reopened.

Hi,

I got the same problem here, starting from today.
I'm using nodemon with ts-node (project developed using typescript)

I tried everthing below and NOTHING worked:

1. Reinstall node_modules
2. Switch node versions from 10 to 12 and 13 and alpine tags too.
3. Switch from nodemon 2.0.2 to 1.19
4. Prune docker volumes, networks, containers, images
5. Rebuild images from scratch.
6. Kill all node processes and everything running on 3000 using all kinds of techniques: lsof, pkill, kill, killall ...
7. Changing port from 3000 to others
8. Changing host from 0.0.0.0 to others
9. Restart my machine (Last solution situation)

The funny thing is I updated nodemon yesterday...
If you guys do have a solution, well I'm still here.

Message error is =>

yume-api | Error: listen EADDRINUSE: address already in use "3000" yume-api | at Server.setupListenHandle [as _listen2] (net.js:1263:19) yume-api | at listenInCluster (net.js:1328:12) yume-api | at Server.listen (net.js:1426:5) yume-api | at Function.listen (/usr/src/yume-api/node_modules/express/lib/application.js:618:24) yume-api | at Object.<anonymous> (/usr/src/yume-api/src/server.ts:35:5) yume-api | at Module._compile (internal/modules/cjs/loader.js:778:30) yume-api | at Module.m._compile (/usr/src/yume-api/node_modules/ts-node/src/index.ts:814:23) yume-api | at Module._extensions..js (internal/modules/cjs/loader.js:789:10) yume-api | at Object.require.extensions.(anonymous function) [as .ts] (/usr/src/yume-api/node_modules/ts-node/src/index.ts:817:12) yume-api | at Module.load (internal/modules/cjs/loader.js:653:32) yume-api | at tryModuleLoad (internal/modules/cjs/loader.js:593:12) yume-api | at Function.Module._load (internal/modules/cjs/loader.js:585:3) yume-api | at Function.Module.runMain (internal/modules/cjs/loader.js:831:12) yume-api | at main (/usr/src/yume-api/node_modules/ts-node/src/bin.ts:226:14) yume-api | at Object.<anonymous> (/usr/src/yume-api/node_modules/ts-node/src/bin.ts:485:3) yume-api | at Module._compile (internal/modules/cjs/loader.js:778:30) yume-api | at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10) yume-api | at Module.load (internal/modules/cjs/loader.js:653:32) yume-api | at tryModuleLoad (internal/modules/cjs/loader.js:593:12) yume-api | at Function.Module._load (internal/modules/cjs/loader.js:585:3) yume-api | at Function.Module.runMain (internal/modules/cjs/loader.js:831:12) yume-api | at startup (internal/bootstrap/node.js:283:19) yume-api | [nodemon] app crashed - waiting for file changes before starting...

And by the way, i have a weird socket file "3000" that is created on project directory, any hints on where that comes from ?

I have never had this problem before but started getting it now all of the sudden. Ubuntu 18.04 "nodemon": "^2.0.2", node version 13.7.0.

Same here on both tools' versions. It seems this issue pops up periodically from a myriad of causes.

Since this thread seems to be the best source of info, I think it should be reopened.

I also face this issue on node from Docker Official Images.
However, only the docker container running on Mac OS, but not for Windows 10 host.

I'm also facing the same issue, I need to save the project 3/4 times in a row to get it working.

Am locking this issue. It was based on 3 year old code, had a pr merge and fixed the source of the problem.

People posting more recently are experiencing similar symptoms but not the same source (plus there's never any info to replicate).

Will take a pr to fix these _new_ issues. Thanks.