Capture KeyboardInterrupt in Runner.run and kill processes
#2744
Conversation
|
@muhrin : would welcome your input if |
|
Coverage decreased (-0.04%) to 70.538% when pulling 97c477ef18cf32eed569edba16b37eec8e2282fc on sphuber:fix_2711_kill_process_interrupt_local_runner into 3898fad on aiidateam:develop. |
|
@sphuber there are three |
|
to test it, you could try something like |
|
Regarding the test suggestion: the difficult thing is not the killing but to launch the sub process. It should be a sub process that runs an aiida environment in which we run a process in a local runner. This can only be done by calling |
|
@giovannipizzi I have a solution that works partially. It is not tested through unit tests and doesn't work in all cases, but I think it will be important to have this partial non-ideal solution in |
Currently, if a user runs a `Process` in a local interpreter and then interrupts the interpreter the process will be lost. However, the node will reflect the last active state. This can be confusing to new users, who will still for example see a "process" in the `Waiting` state. To prevent this situation, the `Runner._run` method is modified and attaches listeners to the `SIGINT` and `SIGTERM` signals that when emitted will trigger a clean function that will log the interrupt and call `process.kill` on the process that is currently in the scope. This should ensure that if a user runs a process in a local interpreter and interrupts it, the process will be properly killed, which will cause the node to properly reflect what has happened. The current solution works for a single process being run, but has issues for nested processes. Sometimes only the current process is killed and the others in the chain are unaffected before the interpreter shuts down.
sphuber
force-pushed
the
fix_2711_kill_process_interrupt_local_runner
branch
from
97c477e to
76d7228
Compare
sphuber
changed the title
KeyboardInterrupt in Runner.run and kill processesKeyboardInterrupt in Runner.run and kill processes
|
@giovannipizzi could you please reapprove, I have rebased |
…team#2744) Currently, if a user runs a `Process` in a local interpreter and then interrupts the interpreter the process will be lost. However, the node will reflect the last active state. This can be confusing to new users, who will still for example see a "process" in the `Waiting` state. To prevent this situation, the `Runner._run` method is modified and attaches listeners to the `SIGINT` and `SIGTERM` signals that when emitted will trigger a clean function that will log the interrupt and call `process.kill` on the process that is currently in the scope. This should ensure that if a user runs a process in a local interpreter and interrupts it, the process will be properly killed, which will cause the node to properly reflect what has happened. The current solution works for a single process being run, but has issues for nested processes. Sometimes only the current process is killed and the others in the chain are unaffected before the interpreter shuts down.
…team#2744) Currently, if a user runs a `Process` in a local interpreter and then interrupts the interpreter the process will be lost. However, the node will reflect the last active state. This can be confusing to new users, who will still for example see a "process" in the `Waiting` state. To prevent this situation, the `Runner._run` method is modified and attaches listeners to the `SIGINT` and `SIGTERM` signals that when emitted will trigger a clean function that will log the interrupt and call `process.kill` on the process that is currently in the scope. This should ensure that if a user runs a process in a local interpreter and interrupts it, the process will be properly killed, which will cause the node to properly reflect what has happened. The current solution works for a single process being run, but has issues for nested processes. Sometimes only the current process is killed and the others in the chain are unaffected before the interpreter shuts down.
Addresses #2711 partially but does not fix it
Currently, if a user runs a
Processin a local interpreter and theninterrupts the interpreter the process will be lost. However, the node
will reflect the last active state. This can be confusing to new users,
who will still for example see a "process" in the
Waitingstate.To prevent this situation, the
Runner._runmethod is modified andattaches listeners to the
SIGINTandSIGTERMsignals that whenemitted will trigger a clean function that will log the interrupt and
call
process.killon the process that is currently in the scope.This should ensure that if a user runs a process in a local interpreter
and interrupts it, the process will be properly killed, which will cause
the node to properly reflect what has happened.
The current solution works for a single process being run, but has
issues for nested processes. Sometimes only the current process is
killed and the others in the chain are unaffected before the interpreter
shuts down.