Properly forward the signal to the original handler if TSRM is shutdown#10219
Properly forward the signal to the original handler if TSRM is shutdown#10219bwoebi merged 1 commit intophp:PHP-8.2from
Conversation
|
See also #10193 (seems that ZTS and signals don't play well together anyway). |
|
@bwoebi I just spent some time to go through this, all those ZTS signal issues and signal code itself. I think this fix makes sense. From what I see, the Zend Signal code overwrite FPM SIGQUIT handler ( Otherwise it needs rebase as there is a conflict. @arnaud-lb could you please also double this if you also think it makes sense. |
|
This makes sense to me as well 👍 |
|
@bwoebi Do you plan to merge this? |
This ensures proper handling of SIGQUIT in ZTS fpm builds outside of active requests.
|
@bukka I missed that - rebased it now. So you're saying the patch is fine as is? Then I'll merge it. |
|
Yeah I think it's fine as is. I can't really think about any reasonable test for this. |
I've occasionally been observing stacktraces like:
(Asan builds incidentally make that particular issue a little bit more command as it has more overhead on process end.)
Coredumps were being created despite SIGQUIT being officially a signal for graceful handling in php-fpm, as signals are in ZTS builds not forwarded to the original handler if TSRM has already been shutdown.
This ensures proper handling of SIGQUIT in ZTS fpm builds outside of active requests.
I'm not sure whether that's truly the correct fix, but it looks sensible to me...