[Bug 274135] lang/php81: php-fpm processes fail to fork cleanly and procfs needed

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274135

            Bug ID: 274135
           Summary: lang/php81: php-fpm processes fail to fork cleanly and
                    procfs needed
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: bofh@freebsd.org
          Reporter: ports@thelanman.net
          Assignee: bofh@freebsd.org
             Flags: maintainer-feedback?(bofh@freebsd.org)

I opened the below a few weeks back:
https://github.com/php/php-src/issues/12157

However, I wanted to open a bug here as well. I maintain a custom poudriere
package repo and sometime after April 2023 the PHP port seems to have gone a
little wonky. I don't know if this is the fault of poudriere, 13.2, the PHP
port, or PHP proper but I'm out of ideas. I've been running PHP5.4x+ and
FreeBSD11+ with more or less the same setup for a loooong time. I update the
lang/phpXY options and lang/phpXY-extensions options files (trying to keep them
more or less the same) as we roll forward builds and we're now on php81.

See the github post for my PHP configs, but we basically run PHP-FPM via local
sockets and each site gets its own "pool" user and talk over sockets with
Apache. Older servers will have 1 master "root" process and 100s of PHP-FPM
processes spread across 20-50 UIDs depending on server load.

1) PHP FPM processes started looking for /procfs for some reason. I ended up
having to add "USE_PROCFS=no" to my poudriere.conf build to get it to not do
that. This is a undocumented (it seems) option that I just happened to run
across via GoogleFu. It does fix that problem, but what changed in FreeBSD 13.2
or the port that it even started to build like that??? I made zero changes
outside of updating FreeBSD, poudriere and my ports tree since I built 8.1.x
sometime in April and this has never been exhibited in the 5+ years I've been
doing PHP builds.

2) the bigger issue is that the PHP-FPM master seems to partially fork a
process and it gets stuck as a new "master" PHP process and starts consuming
100% CPU. Once I get 5+ or so of these over a few days it starts to impact
services and I either re-start PHP-FPM or kill the non-actual "master"
processes. The odd thing is the PHP-FPM debug logs show it forking a process
for the right user, but it just doesn't "switch" to that user. If I "kill -9
PID" the wonky process then PHP-FPM will immediately start a new process with
the right UID/GID no matter the server's actual traffic load or requirements
which leads me to believe it's either a bug caused by malicious requests (I
can't find anything) or a "race condition" in the fork code.

Thoughts? Ideas?

-- 
You are receiving this mail because:
You are the assignee for the bug.