-
Notifications
You must be signed in to change notification settings - Fork 30.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
src: add --disable-sigusr1 to prevent signal i/o thread #56441
base: main
Are you sure you want to change the base?
Conversation
This commit adds a new flag `--disable-sigusr1` to prevent the SignalIOThread to be up listening the SIGUSR1 events and then starting the debugging session.
Idk if this is the wait to do it. There's also |
Initially, I thought about the I could also rename the flag to Also, having a |
I don't disagree w/ this patch. But if this is intended to disable/flip a default behaviour, it may need some update in the documentation side as well.
Refs: https://nodejs.org/docs/latest/api/cli.html#--inspect-porthostport |
Ok. I can update the --inspect documentation to explicitly mention when |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #56441 +/- ##
=======================================
Coverage 88.53% 88.54%
=======================================
Files 657 657
Lines 190741 190768 +27
Branches 36607 36609 +2
=======================================
+ Hits 168881 168918 +37
- Misses 15036 15040 +4
+ Partials 6824 6810 -14
|
PTAL @juanarbol I have also changed the flag to be in stability 1.1 so we can re-evaluate if we need to rename or make it more generic in the future. |
Co-authored-by: Michaël Zasso <[email protected]>
This commit adds a new flag
--disable-sigusr1
to prevent the SignalIOThread to be up listening the SIGUSR1 events and then starting the debugging session.This flag is handy when dealing with multiple apps in the same environment. I wouldn't call it a full security guarantee since one would require access to the environment in order to expose the debugger, and with that assumption, one can do anything one wants. However, I do believe this would serve as a seatbelt in some scenarios.
Please note users already do it by
require('inspector').close()
, but a flag seems more suitable.