Repository navigation
Listening to SIGUSR1 blocks debugger #19619
Description
Activity
@nodejs/v8-inspector
It depends on when the inspector is started. If it's activated at startup, then the JS code will override it. If it's activated later, it subsumes the JS listener.
I think right now it's always started early (
require('inspector').open()uses a different mechanism) but it hasn't always been that way and it could change again in the future.I'd use guarded language: "It's possible to install a listener but doing so might interfere with the debugger."
@bnoordhuis please let me know if the changes are okay or if additional edits are needed. Thanks.
- added a commit that references this issue
on Mar 31, 2018 @bnoordhuis Do you expect this to always work/enable me to set the port at runtime?
process.on('SIGUSR1', () => { const port = myPortFinder(); require('inspector').open(port); });- added a commit that references this issue
on Apr 3, 2018 - added a commit that references this issue
on Dec 4, 2018 - added a commit that references this issue
on Jul 27, 2026
I am not sure which is the correct behavior for an intercepted
SIGUSR1, the documentation or the a test case. Can the code and/or documentation please be fixed?process documentation says:
But a quick test shows that the debugger is not started.
Code:
If you send a
SIGUSR1onlyGot SIGUSR1is printed. The typicalDebugger listening on ws://127.0.0.1:9229/66fb119d-2443-4bdf-80b1-6386995ba253is not printed. You can also verify that the debugger didn't start with withnetstat -ap.