SIGINT/SIGQUIT (kill -2 or kill -3) handled when sent to a mumps process waiting for spawned process to complete
Final Release Note
SIGQUIT/SIGINT signals (generated by kill -3
and kill -2
respectively) are correctly handled by YottaDB processes. Previously, these signals were ignored if the target process had spawned another process (for example using the $ydb_procstuckexec
) and was waiting for it to finish. [#357 (closed)]
Description
The dual_fail_extend/dual_fail2_mustop_sigquit subtest failed twice in the past two weeks on an ARMV7L box. The failure pattern was that the test sent a SIGQUIT (kill -3) to mumps processes but somehow the mumps process never saw that and so continued indefinitely causing the test to fail because it expected the mumps process to terminate soon after sending the SIGQUIT.
There is a way the above can be explained. That is if the mumps process was executing a user-defined script (which it can if the process is stuck waiting for another pid and invokes a script defined by $ydb_procstuckexec env var). That script is invoked in the "gtm_system_internal()" function.
The flow in that function is to
- BLOCK the SIGCHLD signal
- IGNORE the SIGINT and SIGQUIT signals
This is most likely done to mirror how the "system()" function behavior. But come to think of it, a signal explicitly sent to a mumps process will be ignored in this approach and that is not user friendly.
The proposed change is to do the following instead.
- BLOCK the SIGCHLD/SIGINT/SIGQUIT signals
This way all signals are blocked until the spawned script returns and afterwards all signals sent while the process was waiting for the spawned process to finish are handled. The signals are handled in a deferred fashion but never lost/ignored.
Draft Release Note
SIGQUIT/SIGINT signals (generated by "kill -3" or "kill -2" respectively) are no longer ignored by YottaDB (mumps, mupip, dse etc.). Previously, it was possible for these signals to be ignored in case the target process had spawned off another process and was waiting for it to finish (for example using the $ydb_procstuckexec scheme).