Repository navigation
Support dynamic port assignment via --inspect-port=0 #153
Description
Activity
Didn't even know about that feature, but this is easy to support. cc Andre Weinand (@weinand)
Me neither, learned about it in nodejs/node#16872 (comment)
Hmmm. Since the DA is attaching (and not launching), how can we read the stdout of the debuggee in order to detect the port?
In addition, attaching by process ID is useful if node has been started without any debug/inspect arguments. So if we have to use
node --inspect-port=0upfront this defeats the purpose because then we could usenode --inspect=12345instead and would not have to use the process ID at all...But may be I'm not really understanding this feature. It's too late... :-)
I skimmed this and assumed the launch config had the port in it.
If we have to detect the port from stdout then we would have to use some platform-specific method of getting the stdout of a process that isn't a child process. I have no idea how to do that on windows, I don't even know if it's possible. It also seems like there could be issues with node's debug output getting mixed in with output from the user code.
It looks easy on linux, but the Mac solution is scary: https://stackoverflow.com/questions/3425340/how-can-i-capture-the-stdout-from-a-process-that-is-already-running
Andre Weinand (@weinand) The scenario here is that
--inspect-port=0could have been passed to the process, and therefore our default SIGUSR1 logic doesn't work. This is relevant to the Node on Azure production debugging case, where there might be multiple Node processes running and dynamic port assignment is needed. See linked Node issue.We already have code in node-debug that detects a port based on a process ID: https://github.com/Microsoft/vscode-node-debug/blob/424c7760fd197e29ad7a8bd20234d9dbbd534163/src/node/extension/protocolDetection.ts#L154
And please note that the SIGUSR1 mechanism only works locally. So you cannot send signals to a remote process.
Because this is somewhat related, I'm linking to the PR: #235
Would like to get some additional feedback regarding this. Thanks roblourens so far for your assistance as well.
roblourens following up on this and what Andre Weinand (@weinand) mentioned, it seems like (if we still want to do this), the approach would be:
- Adding a similar
getOpenPortsForPidUnix, then top-levelgetInspectorPortForPidwhich grabs the process' ports - If there's more than one, filtering for which one of those is the inspector by calling
GET localhost:<port>/json(If the user is building a web server, they will have additional open ports.) This has the potential of causing side-effects on the target server but I'm unsure that there's a better way to identify the correct port. - Calling
getInspectorPortForPidin that event that we see--inspect-port=0in analyseArguments
Thoughts?
- Adding a similar
- locked and limited conversation to collaborators
on Dec 5, 2020
It's possible to start Node with
node --inspect-port=0that assignes a dynamic port to the inspector server.When using it together with a dynamic attach config like:
We end up failing to attach, as we try on the default port
but the Inspector server is running the dynamically assigned port
Idea: When the given process has been selected, attach to the strout, parse the output to find the used port. use that for attach