Review of All Bundled PHP Runtime Builds

[EvilTater]

Request for Review of All Bundled PHP Runtime Builds
General PHP runtime compatibility / packaging issue​

I have identified what appears to be a compatibility problem with the bundled/custom PHP runtime. Although the issue was reproduced on PHP 8.3, I am requesting that the PHP packaging and runtime configuration be reviewed across all PHP versions shipped by Panelica, rather than treating this as a PHP 8.3-only issue.

The application being tested works correctly when served through the operating system's stock PHP-FPM, but returns HTTP 500 when served through the corresponding Panelica-bundled PHP-FPM runtime. The application files, database, web server configuration, and server remain the same; the PHP runtime is the variable that changes.

To eliminate other layers, I also started the bundled PHP-FPM manually with an isolated temporary configuration and private FastCGI socket, then sent a request directly with cgi-fcgi. This bypassed nginx, Apache, ModSecurity, reverse proxy handling, and Panelica's normal systemd/socket management. The bundled PHP-FPM process started successfully and accepted FastCGI connections, but the application still returned HTTP 500.

Optional extensions including APCu, DBA, igbinary, memcache, MongoDB, ODBC, Redis, and Swoole were disabled for testing. The failure remained, which suggests the problem is not simply one of those optional extensions.

Observed comparison​

• Operating-system stock PHP-FPM: HTTP 200

• Panelica bundled PHP-FPM: HTTP 500

• Same application files and database in both tests

• Direct isolated FastCGI test reproduces the failure under the bundled runtime

Why I am requesting a review of every PHP version​

The Panelica PHP builds appear to rely heavily on private runtime libraries under /opt/panelica/services/php/<version>/lib/runtime rather than using only the host operating system libraries. This includes core dependencies such as OpenSSL, libcrypto, curl, libxml2, ICU, oniguruma, zip, and other libraries.

Because this packaging model is shared across the PHP versions offered by the control panel, a defect in build flags, RPATH/RUNPATH handling, bundled library versions, ABI compatibility, or extension linking could potentially affect more than one PHP release even if the current reproducible case was found on PHP 8.3.

I have also previously encountered a separate problem involving a bundled PHP extension and private runtime library linking. That makes it worthwhile to review the common PHP build and packaging process itself, rather than only applying an application-specific workaround.

Areas I would appreciate being reviewed across all bundled PHP versions​

• PHP build/configure flags and consistency between supported PHP versions.

• RPATH/RUNPATH settings on the PHP binaries and shared extensions.

• Private libraries under /opt/panelica/services/php/<version>/lib/runtime and /opt/panelica/lib/compat.

• ABI compatibility between PHP extensions and the libraries they load.

• OpenSSL/libcrypto, curl, libxml2, ICU/intl, oniguruma/mbstring, zip, sodium, and related runtime dependencies.

• OPcache startup and PHP-FPM pool configuration, including any php_admin_value overrides.

• Whether extensions unexpectedly pull incompatible private libraries into the PHP-FPM process.

• Whether the same compatibility tests are run against PHP 8.1, 8.2, 8.3, 8.4, and 8.5 builds before release.

• Whether a simple automated test can compare bundled PHP-FPM against a standard distribution PHP-FPM using the same application and FastCGI request.

Additional diagnostic observation​

During the isolated bundled PHP-FPM test, the FPM log also reported the following OPcache warning:

Zend OPcache can't be temporary enabled (it may be only disabled till the end of request)

I do not know whether this warning is the direct cause of the HTTP 500, but it may be useful when reviewing how OPcache is initialized by the bundled PHP-FPM builds and per-domain pool configuration.

Request​

Could the Panelica team please review the PHP runtime build and packaging process for all PHP versions currently distributed by Panelica, not only the version on which this was reproduced?

In particular, I would appreciate verification that each bundled PHP binary and its extensions are linked against compatible runtime libraries and that the private library/RPATH design does not introduce behavioral differences from a standard PHP-FPM installation.

I can provide PHP module lists, phpinfo comparisons, ldd output, PHP-FPM pool configuration, and the isolated FastCGI reproduction steps if they would help reproduce or diagnose the issue.

Short reproduction summary:

Same application + same database + same web stack
Stock PHP-FPM -> HTTP 200
Panelica bundled PHP-FPM -> HTTP 500

~Tater

 

[admin]

Request for Review of All Bundled PHP Runtime Builds
General PHP runtime compatibility / packaging issue​

I have identified what appears to be a compatibility problem with the bundled/custom PHP runtime. Although the issue was reproduced on PHP 8.3, I am requesting that the PHP packaging and runtime configuration be reviewed across all PHP versions shipped by Panelica, rather than treating this as a PHP 8.3-only issue.

The application being tested works correctly when served through the operating system's stock PHP-FPM, but returns HTTP 500 when served through the corresponding Panelica-bundled PHP-FPM runtime. The application files, database, web server configuration, and server remain the same; the PHP runtime is the variable that changes.

To eliminate other layers, I also started the bundled PHP-FPM manually with an isolated temporary configuration and private FastCGI socket, then sent a request directly with cgi-fcgi. This bypassed nginx, Apache, ModSecurity, reverse proxy handling, and Panelica's normal systemd/socket management. The bundled PHP-FPM process started successfully and accepted FastCGI connections, but the application still returned HTTP 500.

Optional extensions including APCu, DBA, igbinary, memcache, MongoDB, ODBC, Redis, and Swoole were disabled for testing. The failure remained, which suggests the problem is not simply one of those optional extensions.

Observed comparison​

• Operating-system stock PHP-FPM: HTTP 200

• Panelica bundled PHP-FPM: HTTP 500

• Same application files and database in both tests

• Direct isolated FastCGI test reproduces the failure under the bundled runtime

Why I am requesting a review of every PHP version​

The Panelica PHP builds appear to rely heavily on private runtime libraries under /opt/panelica/services/php/<version>/lib/runtime rather than using only the host operating system libraries. This includes core dependencies such as OpenSSL, libcrypto, curl, libxml2, ICU, oniguruma, zip, and other libraries.

Because this packaging model is shared across the PHP versions offered by the control panel, a defect in build flags, RPATH/RUNPATH handling, bundled library versions, ABI compatibility, or extension linking could potentially affect more than one PHP release even if the current reproducible case was found on PHP 8.3.

I have also previously encountered a separate problem involving a bundled PHP extension and private runtime library linking. That makes it worthwhile to review the common PHP build and packaging process itself, rather than only applying an application-specific workaround.

Areas I would appreciate being reviewed across all bundled PHP versions​

• PHP build/configure flags and consistency between supported PHP versions.

• RPATH/RUNPATH settings on the PHP binaries and shared extensions.

• Private libraries under /opt/panelica/services/php/<version>/lib/runtime and /opt/panelica/lib/compat.

• ABI compatibility between PHP extensions and the libraries they load.

• OpenSSL/libcrypto, curl, libxml2, ICU/intl, oniguruma/mbstring, zip, sodium, and related runtime dependencies.

• OPcache startup and PHP-FPM pool configuration, including any php_admin_value overrides.

• Whether extensions unexpectedly pull incompatible private libraries into the PHP-FPM process.

• Whether the same compatibility tests are run against PHP 8.1, 8.2, 8.3, 8.4, and 8.5 builds before release.

• Whether a simple automated test can compare bundled PHP-FPM against a standard distribution PHP-FPM using the same application and FastCGI request.

Additional diagnostic observation​

During the isolated bundled PHP-FPM test, the FPM log also reported the following OPcache warning:

Zend OPcache can't be temporary enabled (it may be only disabled till the end of request)

I do not know whether this warning is the direct cause of the HTTP 500, but it may be useful when reviewing how OPcache is initialized by the bundled PHP-FPM builds and per-domain pool configuration.

Request​

Could the Panelica team please review the PHP runtime build and packaging process for all PHP versions currently distributed by Panelica, not only the version on which this was reproduced?

In particular, I would appreciate verification that each bundled PHP binary and its extensions are linked against compatible runtime libraries and that the private library/RPATH design does not introduce behavioral differences from a standard PHP-FPM installation.

I can provide PHP module lists, phpinfo comparisons, ldd output, PHP-FPM pool configuration, and the isolated FastCGI reproduction steps if they would help reproduce or diagnose the issue.

Short reproduction summary:

Same application + same database + same web stack
Stock PHP-FPM -> HTTP 200
Panelica bundled PHP-FPM -> HTTP 500

~Tater

Hi Tater,

First of all, thank you for taking the time to provide such a detailed and technically thorough report. Feedback like this is extremely valuable to us.

We try to package and maintain as much of our own infrastructure as possible, and we build our testing environments around that architecture. Panelica is still a relatively young project, and having experienced users like you actively testing the platform, identifying edge cases, and sharing detailed technical feedback is genuinely motivating for our team.

There is also an important point we would like to explain about Panelica.

Although Panelica is designed as a modern and highly automated control panel, one of our primary target audiences is actually experienced technical users. Users with a strong technical background can take advantage of the fact that Panelica provides access to isolated packages, extensions, runtime components, and many low-level configuration options. They can modify and extend their environments while also helping us identify areas where the platform can be improved.

You may have noticed that when you open the Panelica dashboard, quite a lot of technical information and configuration options are immediately available. We understand that this can sometimes feel overwhelming to users who are new to server administration. However, experienced administrators generally appreciate this approach because it gives them the feeling that everything they need is available directly within the panel.

Regarding the PHP runtime issue you reported, there is an important architectural detail.

We build PHP, Apache, Nginx, and several other components ourselves rather than simply relying on the distribution packages. We continuously follow upstream releases and try to publish important updates as quickly as possible.

For this process, we have an internal build system called pn-builder, which is developed by our team. It is responsible for building and packaging many of the components distributed with Panelica, including PHP runtimes and their dependencies. Build flags and various packaging parameters are also controlled through this system.

Our long-term goal is to make pn-builder significantly more stable and mature and then release it as an open-source project on GitHub. This would allow users to build the versions they need themselves with their own configuration and build options.

We are already aware that there are some inconsistencies between PHP versions in terms of extensions and certain build flags. We do not want to hide that fact. We are a relatively small team, and building and maintaining an entire software stack at this level is a substantial undertaking. Nevertheless, we are working continuously to improve the platform and make the underlying components more consistent and reliable.

Your report gives us a very good opportunity to review this part of the architecture more systematically.

We will review the points you raised, particularly the PHP build process, runtime libraries, RPATH/RUNPATH, ABI compatibility, extension linking, OPcache initialization, and consistency between PHP versions.

This is not a small change and we do not want to make a superficial fix that only addresses the specific PHP 8.3 case. We will investigate the underlying build and packaging process and, where possible, apply improvements across the supported PHP versions.

We will also keep you informed here as we make progress on this investigation.

Thank you again for the level of detail in your report and, more importantly, for taking the time to help us improve Panelica. Support and feedback from experienced users like you are extremely valuable to us.