Repository navigation
cluster: forked children eagerly ignore/replace inspect port from cluster settings #21853
Description
Activity
While circling back on this, I was looking into the history on that file in the cluster module, and it looks like this behavior was added in 05707a9 (from #14140) by @mutantcornholio and committed by @Fishrock123 back on July 10, 2017, which means it's new for 8.x. I wonder if either of them have any thoughts on my thoughts, above?
As a quick TL;DR, since this will go with the email notification:
Even if a worker process is configured with a port already, as
--inspect=<port>, the regex ignores that and only detects that we're in "debugging mode", then adds a port anyway. IMO, the detection should be smarter, realizing that the--inspectoption has a value, and not add the--inspect-portoption at all.Also, the documentation is unclear on the precedence of the various
--inspect*options (it turns out that theportof--inspect-port=<port>overrides theportof an--inspect=<port>option).Also, the documentation is unclear on the precedence of the various --inspect* options (it turns out that the port of --inspect-port= overrides the port of an --inspect= option).
Seems like the rule is "last one wins". Maybe we should clear that out in docs, yeah.
node --inspect-port=4567 --inspect=3456 Debugger listening on ws://127.0.0.1:3456/7484ab84-7d40-4e2f-8f2b-b17426ba40b9 For help see https://nodejs.org/en/docs/inspector > node --inspect=3456 --inspect-port=4567 Debugger listening on ws://127.0.0.1:4567/f8394137-2bc0-4cc5-88f4-4849669e4c4a For help see https://nodejs.org/en/docs/inspector >IMO, the detection should be smarter, realizing that the --inspect option has a value, and not add the --inspect-port option at all.
--inspect-portoverrides port part from--inspect; and adding and current logic covers all cases of combining those in execArgv. I've tried implementing altering port part in--inspect, it was too complex with IMHO no profit whatsoever.Am I getting your problem right? You want to set
inspectPortin cluster settings and later activate inspect mode by usingSIGUSR1?@mutantcornholio Thanks for the reply.
If you check out the code example at the top of the issue, that should show what the intention is. I want to propagate the "debug state" from the master to the worker with a port of my choosing. I'm doing that by doing (fairly similar to your code) detection on the args of the master, then adding
--inspect=<port>to the args of the worker.The problem is that that also triggers the detection you added, which doesn't consider the port I've already set.
All of that is described in much more detail in the main, issue, though; so, I don't want to keep talking in case I contradict myself in some later restating 😁.
This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 120 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.
The Setup
Here's a small example that can be used to show this behavior:
In this example, when the master process has been started with any of the
--inspectarguments, we want to start the worker with the inspector active on a specific port. Here's some example output:What can be seen, here, is that the worker is forked with the configured argument from the cluster options'
execArgv; but, the--inspect-port=10002argument is also present, though it wasn't configured.The References
The
clusterModule CodeThe code that does this appears to be the
createWorkerProcess(id, env)function at /lib/internal/cluster/master.js:101. From this, we can see that this behavior appears to be intentional, at least as far as what the code says. Here's what I read from there:execArgvarguments look like--inspect,--inspect-brk,--inspect-portor--debug-port...inspectPortis defined in the cluster settings...inspectPort.inspectPort.`--inspect-port=${inspectPort}`into the worker'sexecArgvarray.The Documentation
In the CLI docs, all three of
--inspect,--inspect-brkand--inspect-portare indicated to support the[=[host:]port]value. However, conceptually, based on what they each do, it seems like they would never be used together.In the
clusterdocs,settings.inspectPortis indicated to set the inspect port of the worker.The Problems
So, here are the problems, as I see them:
settings.inspectPortwould allow one to configure the inspect port; however, that setting is completely ignored unlessexecArgvalready has one of the inspect arguments present (which could be--inspect-port, resulting in two of the same argument).execArgv, the selectedinspectPortvalue ultimately results in the addition of the--inspect-portoption; however, in the documentation, that argument is indicated to only configure what the inspect port will be when/if inspection is latently activated.clustercode explicitly combines them by intentionally adding--inspect-portwhen it knows there's already an inspect argument present.Ultimately, the only option one has to be able to configure the inspect port for a worker is to both (1) add one of the inspect arguments and (2) set the
settings.inspectPort. This will result inexecArgvhaving something like--inspect --inspect-port=####. In that case, one might as well leave off the port from the original argument as it will be overridden by the added one.All of this is fairly confusing to me. Why would the
clustercode intentionally combine inspect arguments? If there is a precedence, it's opaque (i.e. it's not indicated in the documentation). Is this operating as expected? Am I just missing something and thinking about this "wrong"?P.S. The code for this in 10.x, while it has received some changes, does still appear to exhibit this behavior -- though I have not tested it myself.