Improper detection of sigchld compile flag

[JoelFeiner]

On several distributions now phpinfo() no longer returns flag information. There needs to be a better way to detect whether --enable-sigchld was compiled in. Or, alternatively, it should be possible to tell the Process object constructor that it should be treated as enabled (so that the pipe trick can be used).

I'm using PHP from the IUS packages on CentOS 7. But I have read this is also a problem for Debian-based distributions.

[clue]

@JoelFeiner Thanks for reporting, that's an interesting one!

I'd like to get a better understanding of this before we can reasonably commit to a possible alternative implementation. It sounds like you've stumbled over some information about which distribution / version may be affected and perhaps a rationale for this change. Can you share some links?

[JoelFeiner]

This is the main issue I found, which points to another issue in the Symphony project: https://bugs.launchpad.net/ubuntu/+source/php5/+bug/516061

I have verified this issue with PHP 7.2 on Ubuntu 18.04 and the php72* packages from the IUS repository on CentOS 7 (my own testing).

[clue]

This causes the Symfony Process component's sigchild detection to default to "no". From my inspection of the debian/rules file in for latest PHP package, this happens to be the correct behavior for the Process component to take, but this is simply out of dumb luck. What happens when/if that changes in the build routine and suddenly Ubuntu passes --enable-sigchild? At that point, the Symfony Process component will be making the wrong assumptions about how to handle this because the required information to detect this is missing.

Thanks for the link! It's also my understanding that this means that this project will assume sigchild compatibility is disabled for affected distributions (which happens to be the correct path).

Is anybody aware of any other way to automatically detect this? Otherwise I agree that we should probably provide a way to manually override these defaults. 👍

[JoelFeiner]

As best I can tell from looking at the PHP source code, there's nothing else that's set that would indicate that PHP has its own custom signal handler. Using pcntl_signal_get_handler() doesn't show any special behavior either (returns 0 no matter what). As such, I would think the best course of action is to allow it to be configured and make sure that is documented. An alternative would have the special behavior be the default and then allow the user to disable the special behavior (i.e. behave as if --enable-sigchild was not included in compile flags) if they believe it to be safe, or need to in order to avoid the special pipe magic used to gather the exit code.