-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
Bind an available port for debugging if the specified debug port is already bound #4419
Comments
I think we usually filter those in |
How about finding an available port if debug port isn't specified explicitly (i.e. |
What should be a behavior of the parent process? How should it figure out the assigned port? Also, most of the tools assume that it is running on this port, and such implicit behavior change will break them. Not that it is not something that we can deal with, but just another point in support of current behavior. |
Parent processes (mostly tools like node-inspector/IDEs) could analyze stderr for lines matching
Probably, there are other ways to allow easy spawning of child node processes, the suggested approach might be not the best way, I just don't see others. |
I think we can probably add a flag for this behavior. It is not absolutely evident to me that it should work like this in generic case, but I totally understand that it will be helpful to you. @bnoordhuis : what are your thoughts on this? |
The problem is real, but the solution feels fragile. Parsing stderr to figure out where the debug port is horrid, and assumes its even available, which isn't true when node is started standalone and the debugger isn't the parent. If the debugger is the parent, then it makes more sense to reverse the direction of the debug protocol, and have the debugged app connect TO the debugger. Current behaviour isn't so bad, parent is debuggable, child is not. If you hate that, the other option is to start the parent without --debug, then debug only the specific process you want to, by using signals to turn debugging on. I'm not sure what other debugging systems do in this case, like gdb. I suspect they load code into the debugged process to trap the fork, and then know what the child process is. |
@indutny Could you please clarify which part is not evident to you:
@sam-github Agree, parsing stderr is fragile. It will work only if child process is started with
Yes, current behavior isn't so bad, though it isn't good either: child won't even start. Sometimes, it is not clear which process should be debugger - parent or child, so IMO it'd be better to be able to start parent with |
@segrey I was just saying that not every user will want to parser stderr, or want to figure out the actual port on which the process has started. |
AVA has the same problem — avajs/ava#342 (comment) I think, it will be really cool if node will do what @segrey suggests (if process was forked). Instead of just throws error EADDRINUSE On the other hand maybe it will be better to write npm module to overcome. But in this case every author of tool like AVA should be aware about it and do additional work. |
I opened #5025 to allow |
@bnoordhuis IIUC |
It's undocumented, I think. It's for selecting the debug port when the debugger is started later (unlike The main user is the cluster module. It uses it to assign different ports to the cluster's workers. |
Thanks for the explanation and the fix! With this change IDE can run main node.js process with |
Allow binding to a randomly assigned port number with `--inspect=0` or `--inspect-brk=0`. Refs: nodejs#4419
Allow binding to a randomly assigned port number with `--inspect=0` or `--inspect-brk=0`. PR-URL: nodejs#5025 Refs: nodejs#4419 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
from which version is --inspect-brk=0 available ? |
Currently, Node.js process does not start if the specified debug port is already bound by some another process.
These steps allow to reproduce this behavior (node 5.2.0).
Running
node --debug=54138 test.js
outputsand does not exit.
Running another
node --debug=54138 test.js
outputsand hangs.
It might seem like an expected behavior, unless it interferes with the common pattern of spawning child node processes - child node process command lines are usually constructed using
process.execArgv
of the main node process. Thus, if the main node process is started in debug mode, child processes will hang unless there is a special handling ofprocess.execArgv
that takes care of--debug/--debug-brk
.What do you think if node would try to bind a specified debug port increasing it by one until it succeeds?
Tools can always figure out the really bound debug port by stderr analyzing.
The text was updated successfully, but these errors were encountered: