Node: Node process with --inspect cannot fork child process without passing --inspect

[unbornchikken]

• Version: 8.1.1
• Platform: Windows 10

If I start a node process with --inspect and fork a child node process without passing --inspect, child process will crash with exit code of 12.

Is this the intended behavior?

Edit: added a repro case there https://github.com/nodejs/node/issues/14325#issuecomment-315974733

[bnoordhuis]

Test case? I think I know what you mean but I'd rather not guess and guess wrong.

[eugeneo]

This is caused by the default inspector port being taken up by the inspector. I can see exactly same behavior when running Node 6.11 with --debug. This issue can be avoided by running Node with port 0 (--inspect=0).

Should there be some special handling for --inspect?

[gibfahn]

If the --inspect isn't passed to the forked process, how is the inspector enabled for it?

[unbornchikken]

@bnoordhuis Yeah, sorry about that rushed report, I'm trying to make a small repro case asap. @eugeneo That was my first suspect, but @gibfahn is right, the actual case is that --inspect isnot passed to the child, while the parent got started with --inspect passed. Being explicit with the port number in the argument doesn't help though, the child will crash.

[gibfahn]

Being explicit with the port number in the argument doesn't help though, the child will crash.

What @eugeneo is saying is that if you pass 0, then node will pick a free port, so the forked process will pick a different port and not conflict with the parent. Have you tried passing 0?

Still not sure why the inspector is enabled for the forked process.

[unbornchikken]

Here is the repro script: https://gist.github.com/unbornchikken/298b6c507cea82a81074b801271f15d6

node repro

will run fine, however

node --inspect repro

will result with:

$ node --inspect repro.js
Debugger listening on ws://127.0.0.1:9229/cea75bbb-107e-470e-882d-644d46241e43
For help see https://nodejs.org/en/docs/inspector
Parent started.
Starting inspector on 127.0.0.1:9229 failed: address already in use
Forked child exit, code: 12
Forked child close.

It seems fork secretly pass an --inspect argument, but I don't belive that is an expected behavior, because it will never work this way, because parent is always holding the default inspect port in this case.

Being explicit with the inspect port will result:

$ node --inspect=55555 repro.js
Debugger listening on ws://127.0.0.1:55555/ed7f4b59-67f7-4737-86db-16aacf4f5546
For help see https://nodejs.org/en/docs/inspector
Parent started.
Starting inspector on 127.0.0.1:55555 failed: address already in use
Forked child exit, code: 12
Forked child close.

Again, the inspect argument got passed as is. But it should never work that way, because parent has been holding this for sure.

[bnoordhuis]

There's no secret: child_process.fork() accepts a .execArgv option that defaults to process.execArgv when omitted.

[unbornchikken]

@bnoordhuis The problem is that I had no issue of this kind with Node.js 4 --debug. The situation is that I've upgraded to Node 8 from version 4 and I can see that many of my unit tests started to get failed when I try to debug 'em. The interesting part is that you are of course right about that execArgv propagation. If I nvm back to node 4 and use --debug instead of --inpect I get address-already-use error on the side of child. I'm still investigating the cause of this, but I'm gonna close this issue.

[medikoo]

Seems related to #9435

[refack]

If I nvm back to node 4 and use --debug instead of --inspect I get address-already-use error on the side of child. I'm still investigating the cause of this, but I'm gonna close this issue.

The main reason is that --debug and --inspect are completely different implementation, not just the debugger protocol, but also the listening server. It's not surprising that they have different peculiarities.