Restore original signal handlers in finished_callback #1402
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The change in #862 added signal handlers for SIGINT and SIGTERM that may replace any existing SIGINT or SIGTERM handlers set by the process. Those existing handlers are not restored when the
ansible_runner.run
call finishes.The solution here uses the
finished_callback
to restore the handlers. We're relying on thefinished_callback
actually getting called, which I'm not sure is a real guarantee. I'd be open to a solution that uses context managers ortry
-finally
if we can figure out the right refactoring / where to put thetry
-finally
semantics.We are solving this problem today by using an
ExitStack
and a customcancel_callback
(that basically implements the same SIGINT/SIGTERM cancellation behavior as #862) that guarantees to restore the original handlers after the call completes.TODOS
test/unit/test_interface.py
andtest/unit/utils/test_utils.py
that seem related, but wouldn't test the full "set and reset" behavior implemented here. Any pointers appreciated.signal.getsignal
returnsNone
for these handlers. How doesansible-runner
want to handle such a case? Options seem to be: (1) silently fail to restore (same behavior as today), (2)raise
an exception (breaking change), or (3) allow the behavior to be configured.