-
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
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% 89.13% +0.59%
==========================================
Files 657 662 +5
Lines 190741 191558 +817
Branches 36607 36861 +254
==========================================
+ Hits 168881 170743 +1862
+ Misses 15036 13686 -1350
- Partials 6824 7129 +305
|
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. |
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.
384dc99
to
196a470
Compare
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.