#13908 closed enhancement (fixed)
Exit Sage gracefully upon SIGHUP
Reported by: | jdemeyer | Owned by: | jdemeyer |
---|---|---|---|
Priority: | major | Milestone: | sage-5.7 |
Component: | c_lib | Keywords: | |
Cc: | Merged in: | sage-5.7.beta2 | |
Authors: | Jeroen Demeyer | Reviewers: | Volker Braun |
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | #13748, #13946 | Stopgaps: |
Description (last modified by )
Change the signal handling code to allow a graceful forced exit of Sage. "graceful" meaning that code is interrupted and the normal exit handlers are run. This graceful exit is not guaranteed to work, code which is currently not interruptible would not be exited.
This might be used by the doctesting framework to handle timeouts.
This patch also improves interrupt debugging:
- Different debug levels, set in a C file such that not everything needs to be recompiled when changing the debug level.
- Show time between signal received and exception raised.
Apply: 13908_terminate.patch
Attachments (2)
Change History (19)
comment:1 Changed 8 years ago by
- Description modified (diff)
- Summary changed from Exit Sage gracefully upon SIGHUP to Exit Sage gracefully upon SIGHUP/SIGTERM
comment:2 Changed 8 years ago by
- Status changed from new to needs_review
comment:3 Changed 8 years ago by
- Dependencies changed from #13748 to #13748, #13946
comment:4 Changed 8 years ago by
- Status changed from needs_review to needs_work
comment:5 Changed 8 years ago by
- Status changed from needs_work to needs_review
comment:6 Changed 8 years ago by
- Reviewers set to Volker Braun
- Status changed from needs_review to positive_review
comment:7 Changed 8 years ago by
- Milestone changed from sage-5.6 to sage-5.7
comment:9 Changed 8 years ago by
- Summary changed from Exit Sage gracefully upon SIGHUP/SIGTERM to Exit Sage gracefully upon SIGHUP
Since the main motivation is to have some way of gracefully terminating Sage, I'm handling only SIGHUP
now, not SIGTERM
.
comment:10 Changed 8 years ago by
- Description modified (diff)
Changed 8 years ago by
Changed 8 years ago by
comment:11 Changed 8 years ago by
- Description modified (diff)
comment:12 Changed 8 years ago by
- Status changed from needs_work to needs_review
comment:13 Changed 8 years ago by
- Status changed from needs_review to positive_review
Hmm I didn't see any discussion on sage-devel about SIGTERM but getting started with just catching SIGHUP is fine, too.
comment:14 Changed 8 years ago by
For the SIGTERM problem, see https://groups.google.com/forum/?fromgroups#!search/sage-devel$2013908/sage-devel/5BfDSSdN5qw/AcWANg5v2KwJ
comment:15 Changed 8 years ago by
- Merged in set to sage-5.7.beta2
- Resolution set to fixed
- Status changed from positive_review to closed
comment:16 follow-up: ↓ 17 Changed 7 years ago by
I was running a moinmoin wiki with sage. With this patch applied, that doesn't work anymore because of the new interruption handling in sage.ext._init_csage
:
When running the wiki using
$ sage wikiserver.py
and importing sage.all.*
therein, I get the following error:
from sage.all import * File "/home/stumpc5/progs/sage-5.7/devel/sage-main/build/sage/all.py", line 59, in <module> _init_csage() File "c_lib.pyx", line 41, in sage.ext.c_lib._init_csage (sage/ext/c_lib.c:569) ValueError: signal only works in main thread
The issue seems to be solved when I comment out the signal in _init_csage
.
Question: Is there a (reasonable and finite) way to fix this issue properly? Can something serious go wrong if I comment these lines out?
Thanks, Christian
comment:17 in reply to: ↑ 16 Changed 7 years ago by
Replying to stumpc5:
Can something serious go wrong if I comment these lines out?
Not very serious. Interrupt handling might be a bit messed up, in particular some interrupts (CTRL-C) might be seen twice: once by the default Python handler (raise KeyboardInterrupt
) and once by the special Sage handler (written in C).
The line
signal.signal(signal.SIGINT, sage_python_check_interrupt)
is mainly used to ensure that only the Sage signal handler is used.
But this will certainly have no consequences beyond interrupt handling.
Sounds good to me.