Debug already running process using v8-inspector?

[roblourens]

Currently you can send SIGUSR1 to a Node process to put it into debug mode as if it had been launched with --debug. Docs here. Is there any way to do the same using the new v8-inspector protocol?

[joshgav]

Perhaps we should add SIGUSR2 to activate inspector and leave SIGUSR1 to activate the old protocol?

Working impl of this here: joshgav@0edde39

/cc @nodejs/diagnostics

[ofrobots]

The problem is that there aren't enough signals, and SIGUSR2 might already be in use by user-space modules. Repurposing SIGUSR2 would be a semver major change.

I think a better approach would be to deprecate the old debugger in v8.x and free up SIGUSR1 for use by the inspector based protocol. Unfortunately this means that we won't have a solution to attach inspector to an already running process for v7.x and v6.x.

[papandreou]

SIGUSR2 is used by https://github.com/bnoordhuis/node-heapdump (triggers a heap dump).

[joshgav]

Is there a reasonable way to parameterize signals so we could double up SIGUSR1? One approach could be a config file next to the node binary.

/cc @bnoordhuis re node-heapdump. Do we know of other modules which use SIGUSR2?

@ofrobots:

we won't have a solution to attach inspector to an already running process for v7.x and v6.x

IMHO this would be a significant problem for inspector protocol adoption and Node diagnostics in general. We can't expect tools to use a different protocol for attaching to a running process, which is an important use case.

Waiting till v8.x (summer 2017) is too long.

deprecate the old debugger in v8.x and free up SIGUSR1

Even if/when we deprecate the old protocol I don't think we can change behavior of SIGUSR1 for another release or several. Tools will continue to support the old protocol, and v4.x will still be around till Oct 2017 at least.

[bnoordhuis]

The inspector using SIGUSR2 is not a problem for node-heapdump, it will simply override the inspector's signal handler. That may be a problem for the inspector, though. :-)

[ofrobots]

Is there a reasonable way to parameterize signals so we could double up SIGUSR1? One approach could be a config file next to the node binary.

This is not a bad idea. Another idea would be a flag, e.g. --inspect-on-sigusr1. /cc @nodejs/v8-inspector.

[roblourens]

I like the config file option, in that if there is a flag to set when you start node, people will inevitably forget to set that flag, then if you have to restart the process anyway you might as well start it in debug mode. I don't know whether there's some typical way to handle this kind of scenario though.

[joshgav]

Right, seems that if we could go back and restart with a flag we could just use --inspect itself. We need a way to notify and change a running process, which suggests a signal. Any alternatives to signals?

Assuming we have to use a signal, it seems we'd prefer to reuse SIGUSR1. Even if we accepted the semver-major aspect of using SIGUSR2, I think taking the only other user signal would be inconsiderate to @bnoordhuis and others. (I didn't realize earlier that there are only 2! 😮 )

However, since SIGUSR1 is already in use in Node we need to parameterize it somehow so Node knows whether to start the old debugger agent or the new inspector agent. I suggested a config file and will throw together a patch to demonstrate. Maybe one day when the old debugger is gone we can remove it. Are there other patterns to somehow parameterize signals?

[bnoordhuis]

I don't like the idea of a config file. Node has always been a self-contained binary and it should stay that way.

[ofrobots]

Config files don't have a precedent, and quite a few issues will need to be worked through: does the config belong in the node installation, or does it belong with an application? Where do you find the config relative to the application? Should it be something in the package.json? What about standalone scripts, etc.

Other options:

• An environment variable.
• A named pipe that Node listens on.

[imyller]

+1 for --inspect-on-sigusr1 flag along with support for matching environment variable (e.g. NODE_INSPECT_ON_SIGUSR1).

Flag alone would be handy but sometimes you want to use exported environment variable to enable some behaviour in child processes too.

Flag wouldn't be semver-major change, right?

[bnoordhuis]

I'd say semver-minor, it's additive.