Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nodemon frequently leaves the child process running (detached) #1025

Closed
callumlocke opened this issue May 10, 2017 · 100 comments
Closed

Nodemon frequently leaves the child process running (detached) #1025

callumlocke opened this issue May 10, 2017 · 100 comments

Comments

@callumlocke
Copy link

callumlocke commented May 10, 2017

I am using Nodemon to restart an Express server in development. I even clean up with server.close() on process exit. But I frequently get "Port 3000 is already in use" when it starts, suggesting nodemon failed to kill the old child process, and it is still running as a detached process. I have to kill nodemon, run killall node, and restart nodemon again. Is this a known problem? Are there any workarounds?

  • OS X El Capitan
  • Node v7.10.0.
  • nodemon v1.11.0
@johnnydimas
Copy link

johnnydimas commented May 15, 2017

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

@hrgui
Copy link

hrgui commented May 16, 2017

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

OS X Sierra
Node v6.10.3
nodemon v1.11.0

@hrgui
Copy link

hrgui commented May 19, 2017

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.

@divmgl
Copy link

divmgl commented Jun 11, 2017

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

@johnnydimas
Copy link

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(); });

@Extarys
Copy link

Extarys commented Jun 25, 2017

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

$ npm start

> ter@1.0.0 start ter
> npm run build:live


> ter@1.0.0 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

> ter@1.0.0 start ter
> npm run build:live


> ter@1.0.0 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...

@Jackclarify
Copy link

Jackclarify commented Sep 12, 2017

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);
            });
        });
});

@erosenberg
Copy link

Having the same exact issue over here.

@Extarys
Copy link

Extarys commented Sep 15, 2017

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.

@MickL
Copy link

MickL commented Sep 18, 2017

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

@bermanboris
Copy link

Any solution to this issue?

@Extarys
Copy link

Extarys commented Oct 3, 2017

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

@bharathvaj-ganesan
Copy link

Any solutions?

@mikeesto
Copy link

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.

@hrgui
Copy link

hrgui commented Oct 11, 2017

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",

@endel
Copy link

endel commented Nov 6, 2017

The problem is on ts-node itself: TypeStrong/ts-node#458

@rowanD72
Copy link

rowanD72 commented Nov 8, 2017

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

@heisian
Copy link
Contributor

heisian commented Nov 17, 2017

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): #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).

@remy
Copy link
Owner

remy commented Nov 18, 2017

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.

@remy
Copy link
Owner

remy commented Nov 18, 2017

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

@heisian
Copy link
Contributor

heisian commented Nov 20, 2017

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

@heisian
Copy link
Contributor

heisian commented Nov 20, 2017

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 ..?

@heisian
Copy link
Contributor

heisian commented Nov 20, 2017

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.

MadratJerry added a commit to NiX-Team/purple-gourd that referenced this issue Nov 22, 2017
Because of this issue remy/nodemon#1025
➕babel-wathc
➖nodemon
⚠️It may crash when saving files quickly
(detail:
TypeError: First argument must be file descriptor
https://github.com/kmagiera/babel-watch/blob/0bb38ce492b32ae196574a8b36daa79c5a7f61e5/babel-watch.js#L291)
@VasilisKosmas
Copy link

VasilisKosmas commented Dec 8, 2017

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]

@lzl124631x
Copy link

Same issue here.

$ node -v
v8.9.2

$ nodemon -v
1.12.5

@remy
Copy link
Owner

remy commented Dec 13, 2017

@heisian's work here has been merged, and should solve this issue for you all. 👏 Currently live in nodemon@1.12.6

@remy remy closed this as completed Dec 13, 2017
@heisian
Copy link
Contributor

heisian commented Dec 13, 2017

suh weeet! happy to have helped.

@remy
Copy link
Owner

remy commented Dec 13, 2017

@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).

@O-Mutt
Copy link

O-Mutt commented Feb 18, 2019

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

E.g. nodemon.json

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

@bennycode
Copy link

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

@MatteoGioioso
Copy link

MatteoGioioso commented Apr 20, 2019

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

@dehypnosis
Copy link

dehypnosis commented Apr 20, 2019

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

@workhan
Copy link

workhan commented Apr 30, 2019

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

@ypicard
Copy link

ypicard commented May 13, 2019

Up

@ziishaned
Copy link

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

@mercem
Copy link

mercem commented May 19, 2019

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.

@salehammar
Copy link

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

@marcosgoncalves
Copy link

The option "autoAttachChildProcesses": true solved for me

@bennycode
Copy link

The option "autoAttachChildProcesses": true solved for me

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

@hondem
Copy link

hondem commented Aug 15, 2019

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?

@Saman1962
Copy link

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!

@RabiRoshan
Copy link

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.

@thinh105
Copy link

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

@doc82
Copy link

doc82 commented Oct 11, 2019

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

@remy
Copy link
Owner

remy commented Oct 11, 2019

@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".

@denzilgupta
Copy link

denzilgupta commented Oct 16, 2019

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 #1025 (comment)

@ravikiranp123
Copy link

ravikiranp123 commented Oct 28, 2019

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.

@jlippold
Copy link

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.

@einarpersson
Copy link

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.

@Ratstail91
Copy link

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.

@Ratstail91
Copy link

Ratstail91 commented Feb 22, 2020

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.

@blex41
Copy link

blex41 commented Feb 24, 2020

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.

@coachpacman
Copy link

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.

@hhsissi
Copy link

hhsissi commented Feb 27, 2020

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 ?

@tosirisuk
Copy link

tosirisuk commented Mar 17, 2020

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.

@Charged101
Copy link

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

@remy
Copy link
Owner

remy commented Mar 20, 2020

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.

Repository owner locked as resolved and limited conversation to collaborators Mar 20, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests