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

Restart with --inspect flag fails with port in use error #1346

Closed
gartz opened this issue May 14, 2018 · 22 comments
Closed

Restart with --inspect flag fails with port in use error #1346

gartz opened this issue May 14, 2018 · 22 comments
Labels
needs more info not enough information in issue to debug

Comments

@gartz
Copy link

gartz commented May 14, 2018

  • nodemon -v: 1.17.4
  • node -v: v10.1.0
  • Operating system/terminal environment: Linux version 4.9.87-linuxkit-aufs (root@70f48253c8b4) (gcc version 6.4.0 (Alpine 6.4.0) )
  • Command you ran: nodemon --expose-gc --inspect=0.0.0.0:9228 --legacy-watch --delay 250ms --watch webpack.config.js node_modules/.bin/webpack-dev-server --mode development --host 0.0.0.0 --port 80

Expected behaviour

When a file has changed, it should restart the node application, with the following steps "stop the current application; start the a new instance of the application"

Actual behaviour

It's starting the application before the previous instance finish to stop, what makes it to fail and display the following error:

[nodemon] starting `node --expose-gc --inspect=0.0.0.0:9228 node_modules/.bin/webpack-dev-server --mode development --host 0.0.0.0 --port 80 src/index.js`
Starting inspector on 0.0.0.0:9228 failed: address already in use
[nodemon] app crashed - waiting for file changes before starting...

If any the watched file get's changed, it restart again and it work since it will be enough time to stop the application instance.

Steps to reproduce

Start a simple project with webpack-dev-server, babel and react, then add a dummy src/index.js that initialize react to make the process be a bit slower for webpack-dev-server.
Start the nodemon using the command provided.
execute: touch webpack.config.js it might fail if your computer isn't fast enough to stop the instance before start the next.

Suggestion

Listen for the PID to be dead before start a new instance using a timeout or interval when --inspector flag is added to nodemon, to be sure that all resources are available before starting a new instance.


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
Copy link
Owner

remy commented May 15, 2018

Please provide a git repo to replicate from. I'm not going to guess at the package config (and I've used inspect with nodemon with success, so the config is what I'm after).

@remy
Copy link
Owner

remy commented May 15, 2018

Also, if you have a suggestion, best to provide a PR with a test showing it works, that would be absolutely 👍

@remy remy added the needs more info not enough information in issue to debug label May 15, 2018
@gartz
Copy link
Author

gartz commented May 15, 2018

I'll think how can I create an isolated project that can be used to reproduce that, but it seems to be very challenging, here I can reproduce inside docker containers since I can reduce the resources available from my computer to execute the app.

@remy
Copy link
Owner

remy commented May 15, 2018

Maybe you'll be able to debug your project directly (and I suspect there's something special about the project that's causing the issue, but I know others have seen something vaguely similar, but never able to replicate).

You can also use DEBUG=nodemon* to get more info out, and if required, I can do some debug release to help get into what's causing the issue (I suspect around thekill method in the run.js file)

@marcoreni
Copy link

I'm also seeing this error randomly, while using nodemon inside a Docker container. The error is completely random, I'm not able to create a repro scenario.

I tried adding a DEBUG=nodemon* env inside the container, then I caused a few restarts until I received an error.

This is the log of a successful restart:

my_container_1           | Thu, 24 May 2018 15:30:32 GMT nodemon bus emit: restart
my_container_1           | [nodemon] restarting due to changes...
my_container_1           | Thu, 24 May 2018 15:30:33 GMT nodemon bus.emit(exit) via SIGUSR2
my_container_1           | [nodemon] starting `node --inspect=0.0.0.0:7005 src/index.js`
my_container_1           | Thu, 24 May 2018 15:30:33 GMT nodemon bus emit: exit
my_container_1           | Thu, 24 May 2018 15:30:33 GMT nodemon spawning node --inspect=0.0.0.0:7005 src/index.js
my_container_1           | Thu, 24 May 2018 15:30:33 GMT nodemon bus new listener: exit (1)
my_container_1           | Thu, 24 May 2018 15:30:33 GMT nodemon start watch on: ./,../shared/
my_container_1           | Thu, 24 May 2018 15:30:33 GMT nodemon:watch early exit on watch, still watching (2)
my_container_1           | Debugger listening on port 7005.
my_container_1           | Warning: This is an experimental feature and could change at any time.
my_container_1           | To start debugging, open the following URL in Chrome:
my_container_1           |     chrome-devtools://devtools/remote/serve_file/@60cd6e859b9f557d2...

This is the log of the failure:

my_container_1           | [nodemon] restarting due to changes...
my_container_1           | Thu, 24 May 2018 15:30:47 GMT nodemon bus emit: restart
my_container_1           | Thu, 24 May 2018 15:30:47 GMT nodemon bus.emit(exit) via SIGUSR2
my_container_1           | Thu, 24 May 2018 15:30:47 GMT nodemon bus emit: exit
my_container_1           | [nodemon] starting `node --inspect=0.0.0.0:7005 src/index.js`
my_container_1           | Thu, 24 May 2018 15:30:47 GMT nodemon spawning node --inspect=0.0.0.0:7005 src/index.js
my_container_1           | Thu, 24 May 2018 15:30:47 GMT nodemon bus new listener: exit (1)
my_container_1           | Thu, 24 May 2018 15:30:47 GMT nodemon start watch on: ./,../shared/
my_container_1           | Thu, 24 May 2018 15:30:47 GMT nodemon:watch early exit on watch, still watching (2)
my_container_1           | Unable to open devtools socket: address already in use
my_container_1           | [nodemon] app crashed - waiting for file changes before starting...

Let me know if I can assist further.

@gartz
Copy link
Author

gartz commented May 24, 2018

Maybe retry the spawn until the port is available would be a good workaround until we find the issue that is causing the port to be in use for more time then the bus: exit be emitted.

@stale
Copy link

stale bot commented Jun 7, 2018

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

@stale stale bot added the stale no activity for 2 weeks label Jun 7, 2018
@novascreen
Copy link

I'm also running into this inside of a Docker container (Docker for Windows)

@stale stale bot removed the stale no activity for 2 weeks label Jun 8, 2018
@AlexanderYW
Copy link

Hi @remy, i'm experiencing this issue too as well as the others

Node: 9.10.1
npm: 6.1.0
Nodemon: 1.17.5
OS: Windows 10
Command you ran: nodemon app

Here is a link to my repo: https://github.com/AlexanderYW/uptime
I'm getting the error on this one

@abou7mied
Copy link

abou7mied commented Jun 29, 2018

I'm experiencing the same issue
From #1050 I tried the workaround of that comment

nodemon --delay 80ms --exec 'fuser -k 56745/tcp; node --inspect=0.0.0.0:56745 ./app/http.js'

replaced kill-port with fuser

@remy
Copy link
Owner

remy commented Jul 10, 2018

Can we mark this as worked around (I suspect the fact it's nodemon plus node plus debugger protocol plus docker plus host system - might make the inception like debugging silly hard - certainly no one has offered any PRs, so I'm guessing I'm right on that one).

I'm happy to add this to the faq too.

remy added a commit that referenced this issue Jul 10, 2018
Ref #1354
Ref #1346

[skip ci]
@remy remy closed this as completed Jul 10, 2018
@remy
Copy link
Owner

remy commented Jul 10, 2018

(added to faq)

@darkobits
Copy link

darkobits commented Nov 27, 2018

Here is a repo that replicates this issue: https://github.com/darkobits/nodemon-restart-issue.

It seems that Nodemon isn't waiting for the old process to completely exit before starting a new one, but only when in a Docker container and only when debug mode is active.

To be clear: The presence of --inspect does cause the new process to immediately crash because its trying to open a server on the same port that is still in use by the previous process, but this merely a side-effect of this issue. You will notice that even in the Docker container, if the --inspect flag is removed, Nodemon correctly waits for the old process to exit, but when --inspect is used inside the container, Nodemon does not wait for the process to exit.

I hope this helps.


P.S. -- 👏 to Remy and the other contributors to this fantastic project. 😸

@remy
Copy link
Owner

remy commented Nov 28, 2018

@darkobits you're better off starting a new issue for what you're seeing (particularly useful as you have a repo to replicate). I prefer to work with fresh issues (particularly when there's been a bunch of time since closing and reporting new findings).

Thans again for the repo to replicate 👍

@nomcopter
Copy link

This happens to me outside of docker: https://github.com/nomcopter/nodemon-no-wait-repro

@Christilut
Copy link

Adding "signal": "SIGINT" to the nodemon.json fixed this for me

@gvlekke
Copy link

gvlekke commented Aug 1, 2019

@Christilut When im adding the signal SIGINT to the nodemon.json it keeps restarting, the errrors are gone but this is also not a good solution. Do you have any idea why the signal sigint can cause this?

@Christilut
Copy link

No idea but this is the full config I'm using, maybe it helps:

nodemon.json

{
  "restartable": "rs",
  "ignore": [
    ".git",
    "node_modules/**/node_modules"
  ],
  "verbose": false,
  "execMap": {
    "ts": "node --require ts-node/register"
  },
  "watch": [
    "server/",
    "config/"
  ],
  "ext": "json,ts",
  "signal": "SIGINT"
}

Start with (as NPM script): nodemon --inspect server/index.ts

@dcohenb
Copy link

dcohenb commented Nov 4, 2019

So the trick with fuser kinda worked for me,
but still at times it would not manage to kill the process before starting a new one.
So I resolved it by using a while loop to make sure we don't move on until the old process is definitely killed.

here is my solution:

nodemon --delay 100ms --exec 'while [ -n "$(fuser -k 9229/tcp)" ]; do sleep 0.1; done; node --inspect=0.0.0.0:9229 ./src/app.js'

Hope this helps someone in the future

@benjie
Copy link
Sponsor

benjie commented Nov 13, 2019

Bizarrely changing the signal to SIGINT also solves the problem for me. I do not have Docker in the mix.

@Gorthog
Copy link

Gorthog commented Feb 20, 2020

After using SIGINT, nodemon restarts but can't kill the process when debugger is attached and process is paused (i.e. user is currently stepping via code):

image

my package.json configuration:

    "start:dev": "nodemon --exec node --inspect=0.0.0.0:5860 ."
  },
  "nodemonConfig": {
    "ignore": [
      ".git",
      "cache/*",
      "logs/*"
    ],
    "env": {
      "NODE_ENV": "test"
    },
    "signal": "SIGINT",
    "verbose": true
  },

@bitbyter101010
Copy link

Adding "signal": "SIGINT" to the nodemon.json fixed this for me

I have some additional information that will hopefully prove useful to somebody.
I encountered the same issue after updating from v2.0.15 to v2.0.22 inside a docker container running node:16.20.0 wrapped in TINI_VERSION v0.19.0.

The issue only occurred when the app was paused on a debug breakpoint, then made a file change and saved. The debugger was not releasing the port connection, and nodemon was not forcing it to close.

After finding the solution mentioned by @Christilut, I cycled through the possible signals to see which performed as expected. I found the behavior on the following signals:

  • SIGTERM
    • reproduces the issue, no change
  • SIGINT
    • FIXES THE ISSUE
    • waits to restart the server until after you disconnect the debugger (stop or no more breakpoints).
    • The behavior explained by @Gorthog
  • SIGQUIT
    • FIXES THE ISSUE
    • will wait briefly until the connection is forced close
  • SIGHUP, SIGKILL
    • FIXES THE ISSUE
    • will force the connection to close immediately, restart the server, then allow the debugger to reconnect automatically.

For me SIGKILL is the fastest/most stable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs more info not enough information in issue to debug
Projects
None yet
Development

No branches or pull requests