mod_php uses ZTS (thread-safe) build of PHP which is buggy.
E.g. causing Apache to crash php/php-src#10015.
Let’s switch to FastCGI instead.

I had to loosen the systemd service hardening to allow it access my home directory.
Took me a while to figure out too.

---

For debugging, I added “.mon” suffix to the handler socket and ran the following to monitor it:

    sudo socat -t100 -x -v UNIX-LISTEN:/run/phpfpm/dev.sock.mon,mode=777,user=wwwrun,group=wwwrun,reuseaddr,fork UNIX-CONNECT:/run/phpfpm/dev.sock

Source: https://superuser.com/a/576404/39197

Also used the following for more info:

    services.phpfpm.settings."log_level" = "debug";
    services.phpfpm.pools.dev.settings."access.log" = "/var/log/httpd/phpfpm-$pool.access";

Fixes phpGH-8789.
Fixes phpGH-10015.

This is one small part of the underlying bug for phpGH-10737, as in my
attempts to reproduce the issue I constantly hit this crash easily.
(The fix for the other underlying issue for that bug will follow soon.)

It's possible that a signal arrives at a thread that never handled a PHP
request before. This causes the signal globals to dereference a NULL
pointer because the TSRM pointers for the thread aren't set up to point
to the thread resources yet.

PR phpGH-9766 previously fixed this for master by ignoring the signal if
the thread didn't handle a PHP request yet. While this fixes the crash
bug, I think the solution is suboptimal for 3 reasons:

1) The signal is ignored and a message is printed saying there is a bug.
   However, this is not a bug at all. For example in Apache, the signal
   set up happens on child process creation, and the thread resource
   creation happens lazily when the first request is handled by the
   thread. Hence, the fact that the thread resources aren't set up yet
   is not actually buggy behaviour.

2) I believe since it was believed to be buggy behaviour, that fix was
   only applied to master, so 8.1 & 8.2 keep on crashing.

3) We can do better than ignoring the signal. By just initialising the
   resources if they don't exist, in the very same way the request
   handler in Apache works, we can gracefully handle the signal.

Fixes phpGH-8789.
Fixes phpGH-10015.

This is one small part of the underlying bug for phpGH-10737, as in my
attempts to reproduce the issue I constantly hit this crash easily.
(The fix for the other underlying issue for that bug will follow soon.)

It's possible that a signal arrives at a thread that never handled a PHP
request before. This causes the signal globals to dereference a NULL
pointer because the TSRM pointers for the thread aren't set up to point
to the thread resources yet.

PR phpGH-9766 previously fixed this for master by ignoring the signal if
the thread didn't handle a PHP request yet. While this fixes the crash
bug, I think the solution is suboptimal for 3 reasons:

1) The signal is ignored and a message is printed saying there is a bug.
   However, this is not a bug at all. For example in Apache, the signal
   set up happens on child process creation, and the thread resource
   creation happens lazily when the first request is handled by the
   thread. Hence, the fact that the thread resources aren't set up yet
   is not actually buggy behaviour.

2) I believe since it was believed to be buggy behaviour, that fix was
   only applied to master, so 8.1 & 8.2 keep on crashing.

3) We can do better than ignoring the signal. By just acting in the
   same way as if the signals aren't active. This means we need to
   take the same path as if the TSRM had already shut down.

* PHP-8.1:
  Fix GH-8789 and GH-10015: Fix ZTS zend signal crashes due to NULL globals

* PHP-8.2:
  Fix GH-8789 and GH-10015: Fix ZTS zend signal crashes due to NULL globals