vscode: Starting inspector on 127.0.0.1:9229 failed: address already in use with nodemon
I am getting the same issues as this issue: https://github.com/Microsoft/vscode/issues/27794
Version: 1.32.3 Commit: a3db5be9b5c6ba46bb7555ec5d60178ecc2eaae4 Date: 2019-03-14T23:38:49.842Z Electron: 3.1.6 Chrome: 66.0.3359.181 Node.js: 10.2.0 V8: 6.6.346.32 OS: Linux x64 4.10.0-32-generic Steps to Reproduce:
Hitting me (changed)
[nodemon] files triggering change check: application/index.ts
[nodemon] matched rule: /home/karl/dev/a-vdgs-server/application/**/*
[nodemon] changes after filters (before/after): 1/1
[nodemon] restarting due to changes...
[nodemon] application/index.ts
[nodemon] starting `node -r ts-node/register --inspect=9229 ./application/server.ts`
[nodemon] spawning
[nodemon] child pid: 22626
Debugger listening on ws://127.0.0.1:9229/d3273c04-8fe5-4130-b02c-a6ee36bc6979
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
NODE_ENV is set to: development
Loaded config/development.json configuration file
Config lib initialized
Adding console log transport
2019-05-16T12:20:58.539Z info: Log lib initilized1
2019-05-16T12:20:58.555Z info: Websocket server started on port: 8081
2019-05-16T12:20:58.556Z debug: Connecting to MQTT broker on: mqtt://172.17.0.2
2019-05-16T12:20:58.595Z info: MQTT lib initilized
2019-05-16T12:20:58.606Z info: HTTP server running on: http://localhost:8080
2019-05-16T12:20:58.624Z debug: Connected to MQTT broker on: mqtt://172.17.0.2
2019-05-16T12:20:58.636Z debug: Presence!
2019-05-16T12:20:58.644Z debug: Hello mqtt
[nodemon] files triggering change check: application/index.ts
[nodemon] matched rule: /home/karl/dev/a-vdgs-server/application/**/*
[nodemon] changes after filters (before/after): 1/1
[nodemon] restarting due to changes...
[nodemon] application/index.ts
[nodemon] starting `node -r ts-node/register --inspect=9229 ./application/server.ts`
[nodemon] spawning
[nodemon] child pid: 22713
Debugger listening on ws://127.0.0.1:9229/785cd083-92e5-4c01-afd0-c945c2bcfa02
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
NODE_ENV is set to: development
Loaded config/development.json configuration file
Config lib initialized
Adding console log transport
2019-05-16T12:21:06.992Z info: Log lib initilized1
2019-05-16T12:21:07.004Z info: Websocket server started on port: 8081
2019-05-16T12:21:07.005Z debug: Connecting to MQTT broker on: mqtt://172.17.0.2
2019-05-16T12:21:07.038Z info: MQTT lib initilized
2019-05-16T12:21:07.043Z info: HTTP server running on: http://localhost:8080
2019-05-16T12:21:07.052Z debug: Connected to MQTT broker on: mqtt://172.17.0.2
2019-05-16T12:21:07.055Z debug: Presence!
2019-05-16T12:21:07.057Z debug: Hello mqtt
[nodemon] files triggering change check: application/index.ts
[nodemon] matched rule: /home/karl/dev/a-vdgs-server/application/**/*
[nodemon] changes after filters (before/after): 1/1
[nodemon] restarting due to changes...
[nodemon] application/index.ts
[nodemon] starting `node -r ts-node/register --inspect=9229 ./application/server.ts`
[nodemon] spawning
[nodemon] child pid: 22789
Starting inspector on 127.0.0.1:9229 failed: address already in use
[nodemon] app crashed - waiting for file changes before starting...
launch.json
{
"type": "node",
"request": "launch",
"name": "dev",
"runtimeExecutable": "nodemon",
"runtimeArgs": ["--config", "./nodemon.debug.json"],
"cwd": "${workspaceRoot}",
"restart": true,
"port": 9229,
"env": {
"NODE_ENV": "development"
},
"outputCapture": "std",
"console": "integratedTerminal"
},
nodemon.json
{
"watch": ["application"],
"ext": "ts",
"ignore": ["./**/*.spec.ts"],
"exec": "node -r ts-node/register --inspect=9229 ./application/server.ts",
"verbose": true
}
The behavior I see is that it randomly happens. My best guess is that the previous attached debugger hasn’t finished closing down when the new one tries to start up on the same port. This is due to the "restart": true
. I don’t know how this process works but from what I read it keeps track of the node process, but does it keep track of the previous debugger?
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 32
- Comments: 45 (9 by maintainers)
Restart vscode didn’t help, but I’ve found a workaround for me.
lsof -i:9229
to spot process occupying port9229
run
kill 88376
vscode pop up an error : “Extension host terminated unexpectedly”
click
Restart Extension
on the error popupStart your debugger again and hopefully it would work
a little bit hassle but works for me =)
Btw, my environment:
It seems like this happens when there’s an extension that was updated and is awaiting a restart.
Also having the same issue here.
Run attach to process and show the error.
Look up the occupied port with lsof command:
And found that extension host process is listening to the port 9229
Restarting vscode worked for me!
the port really dont matter, always says failed: “address already in use”, and same with NPM runtime instead NODE
nextJS v8.0.3 node v12.8.1 npm v6.8.0
Debugger listening on ws://127.0.0.1:9229/828bbb76-a120-464b-9030-2555b1275b91 For help, see: https://nodejs.org/en/docs/inspector Debugger attached. Waiting for the debugger to disconnect… Debugger listening on ws://127.0.0.1:9229/3126f3b8-3a63-4f83-aa61-615d48701d6b For help, see: https://nodejs.org/en/docs/inspector
Starting inspector on 127.0.0.1:9229 failed: address already in use
According to netstat -abno , vscode is using this process. It might be quite a bear to figure out which extension might be triggering it. Is there a way to set an abritrary port to use in the debug command line, as well as in launch.json ?
– edit: there is: set “port”: 9300 in launch.json, and swap “–inspect” on the node command line to “–inspect=9300”
works for me.
lsof -i :9229
kill -9 PIDNUMBER
I’m having this issue as well. It didn’t occur until updating to VSCode version 1.40.1. When I find the process running on port 9229 and kill it, I get the following message in VSCode:
“Extension host terminated unexpectedly”
Is it possible that extension host is now running on port 9229 as of this version?
https://code.visualstudio.com/api/advanced-topics/extension-host
It’s not a problem with VSCode I think. I am having this issue with nodemon on commandline.
Same issue on 1.40.1. Occurs when debugger attempts to attach to process
I have this issue on
1.41.0-insider
However, I get it after running updates (from
1.40.x-insider
) to try and fix it, so it’s a fresh launch and was existent prior as well. Then I run the following from the integrated Powershell terminalyarn start:win
The relevant script in package.json being:Edit: I think I found the issue. I had launched a docker devcontainer with VSCode, and then my machine crashed. VSCode launched before Docker came up, and that window was reverted to local FS. Docker then came up, and launched the devcontainer, including the crashed debug port, it seems. I found this with TCPView, and it was a quick solve from there. Stopping the container resolved everything.
For anyone else having issues, I recommend checking what’s actually on the port.
what i did are, kill extension host on help -> process list menu, then npm run debug, after that restart extension host. it worked, but really annoy me
I tried to trace code in developer tool. I found that I might be triggered by this line: https://github.com/microsoft/vscode/blob/4934a6f487b9ed6b99b900ae0710c7b452792e20/src/vs/workbench/contrib/extensions/electron-browser/extensionsAutoProfiler.ts#L46
And followed by https://github.com/microsoft/vscode/blob/0f2cda10da1e80088ad7908ac0f743c8f2132de0/src/vs/workbench/services/extensions/common/extensionHostProcessManager.ts#L244
Here is the related change: https://github.com/microsoft/vscode/commit/0f2cda10da1e80088ad7908ac0f743c8f2132de0
Here is the call stack
Just put environment variable flag for debugging in
nodemon.json
config. For example for next.js users:Worked for me without any issues
You can see example config to reference the structure.
nodemon.json
file should be at project root@EricJizbaMSFT I’ve commented on the non-nodemon related issue #85328 and explained how we are planning to address this.
ping @jrieken who authored the commit mentioned above and hopefully can help. We’ve had people running into this for Azure Functions scenarios as well. See https://github.com/MicrosoftDocs/azure-docs/issues/42379
cc @fiveisprime @chrisdias
I’m getting this… pretty frustrating. Sometimes I need to restart a couple of times to get it to clear.