-
Notifications
You must be signed in to change notification settings - Fork 50
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
chore(accept_server): optionally print stack trace on signal #156
Conversation
Codecov ReportAttention:
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## master #156 +/- ##
==========================================
- Coverage 77.34% 77.26% -0.08%
==========================================
Files 98 98
Lines 7173 7192 +19
==========================================
+ Hits 5548 5557 +9
- Misses 1625 1635 +10
☔ View full report in Codecov by Sentry. |
There are may be several non-intrusive options.
|
Isn't it the case that we want to print the stacktraces only when Is there something I am missing? |
Ok, if you want to print only after the regular shutdown sequence finishes
then yes, signal is needed. But you can register for another signal in
dragonfly via a proactor. Does not have to be sigint.
Another thing, accessing server logs is the prerequisite for this pr,
because I am not sure the system is stable enough at this stage to actually
execute the stacktrace printing logic.
…On Fri, Oct 13, 2023, 7:09 PM Kostas Kyrimis ***@***.***> wrote:
Isn't it the case that we want to print the stacktraces only when
instance.stop() fails in pytests? There we use SIGKILL which brutally
kills the process, so I don't think any of the two above get a chance to
run? That's why I wanted to a signal, such that before we proc.kill() I
send a proc.send_signal(signal.SIGINT) to allow DF print the stacktraces
before it gets brutally killed. (SIGKILL can't be handled or blocked)
Is there something I am missing?
—
Reply to this email directly, view it on GitHub
<#156 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA4BFCEDDGIRGDQCTSJJQ3DX7FRT7AVCNFSM6AAAAAA57FYA4SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRRG43DGOBVHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Yep that's true and now I am thinking about this doesn't need to be done in helio. |
I agree, this might never happen and it's kinda a longshot. But then what's the value of printing stacktraces then? We want to print them when things go bad such that we can use them to figure out what happened (for cases that the python code must brutally kill DF via Also regular shutdown is impossible, if we reached Another thing that would add value here is the core dump... All in all, given that the system is unstable and that the signal might not actually print the stacktraces, is there really added value by this idea? What's your opinion? |
Allow to optionally print stack traces on received signals