Debug MULTIPLE already running processes (SIGUSR1)...

[june07]

Is there a way to influence (ie change) the inspect port when starting the inspect web socket after runtime? Maybe process._debugProcess(process.pid) would be a good place to start looking/make changes? I've dug around a bit and I'm not sure exactly where to begin in the codebase... C++ or Javascript. My C++ is weak so I'm sure I'm missing a lot in that regard. Some expert help/finger pointing would be great!

My problem currently is coming from the fact that you can only start the inspect process pragmatically on the default port 9229 and that's it. I'd like to be able to start debug web sockets on random ports, such that doing so would be possible on more than a single running Node program.

Another question I had was... is it possible to programmatically shut down the web socket externally just the same but opposite to the way it was started up (ie SIGUSR1)?

@ORESoftware Yes, exactly. node registers a "signal handler" that is called whenever the operating system (e.g. via a user running kill) sends a specific signal to the process. The signal handler for SIGUSR1 is registered here:

node/src/inspector_agent.cc

Line 130 in 2f8ddb2

RegisterSignalHandler(SIGUSR1, StartIoThreadWakeup);
It will enable the inspect protocol using the options provided at startup. Which means that you can't influence the port for example at the time you're sending the signal (since there's no additional data for signals).

Originally posted by @june07 in #8464 (comment)

[Trott]

Not sure if the right people to ping are @nodejs/v8-inspector or @nodejs/diagnostics or someone else?

[jkrems]

Quoting myself from that thread:

My problem currently is coming from the fact that you can only start the inspect process pragmatically on the default port 9229 and that's it.

The problem is a basic property of unix signals: They don't pass any data. So from the outside there's only "send USR1" which is all process._debugProcess does in the end. What you can do is start the processes with --inspect-port=<unique port>. That will make sure that once you send the signal, they will start listening on that custom port.

On the more complicated side there's things like having a long-running agent that assigns ports or having logic that is able to attach on 9229, assign port, detach, and then reattach. But this assumes fairly smart clients, has a built-in race condition, and breaks as soon as anything actually keeps listening on 9229.

[bnoordhuis]

You can start the inspector race free on a random port with --inspect-port=0. The inspector prints a message with the actual port number that you can parse if you capture its output.

[june07]

@bnoordhuis Yes, but "already running" implies that node was called without any inspect flags set.

@jkrems Makes sense about the signals, thanks. That said,
How viable, (more sense?), would it be to change the current default behavior of node starting inspect on the default port after receiving SIGUSR1 to starting it on a random port? It seems that the change would be pretty straightforward as the code for both is already there.

[jkrems]

The issue is that nothing could then ever connect to the port, short of scanning all ports. It really is only useful if you control the process and/or can access its output. And in that case, it feels like you might as well start it with --inspect-port=0. The default behavior is designed for the case where the process itself is out of the senders control. I'm not sure if there's an easy, portable way to get a stdout stream for a process.

[Trott]

Finding some way for processes to communicate inspection ports would help resolve #16734. But I don't see any obvious way around the challenges outlined by @jkrems.

[bnoordhuis]

We're not changing the default behavior and making non-cooperative processes cooperate is not actionable/reasonable as feature requests go, so I'll go ahead and close this out.

You could start node with -r your-preload-script.js and have it set up signal handler (process.on('SIGUSR1', ...)) that starts the inspector on a random port and write the port number to some well-known file location.