As it is actually not possible to open tickets because of an Forbidden error i need to post it here
CWP Pro 1.26 – Dashboard CPU Usage HTTP 500 after PHP 8.3.36 migration and PHP library workaround required
Dear CWP Support Team,
I am requesting technical assistance with a persistent dashboard issue following the recent emergency migration of the internal CWP PHP runtime to PHP 8.3.36.
Current environment
Operating system: AlmaLinux 8.10 (Cerulean Leopard)
Control panel: CWP Pro 1.26
Internal CWP PHP: PHP 8.3.36, non-thread-safe (NTS), built on October 22, 2026
ionCube Loader: 15.5.1
Web services: CWP's internal cwpsrv, cwpsrv-phpfpm, cwp-phpfpm, Apache, Nginx and Varnish
The CWP administration panel and webmail are currently accessible.
1. Dashboard CPU Usage returns HTTP 500
The CPU Usage widget displays 0% or fails to populate correctly. The Disk IO widget also remains blank.
Using the browser developer tools, I identified the following failing request:
POST /admin/loader_ajax.php?ajax=dashboard
Request payload:
action=cpuUsageList&fileName=cpuUsage
The request returns HTTP 500. The response body is empty.
Other dashboard requests, including loader.php?func=get_load and loader.php?func=get_top_short, return HTTP 200.
The underlying server measurements appear to work normally:
top reports approximately 97–99% CPU idle.
sar -u 1 3 reports approximately 98.69% CPU idle.
/proc/diskstats, sar -d and iostat -dx provide disk statistics.
This suggests that basic system monitoring works, but the corresponding CWP dashboard functionality does not.
2. Internal PHP fails without LD_LIBRARY_PATH
The internal CWP PHP executable is:
/usr/local/cwp/php71/bin/php
Although this binary now reports PHP 8.3.36 when started with the required environment, it fails when executed without the library-path workaround.
Command without the workaround:
/usr/local/cwp/php71/bin/php -v
Result:
PHP Fatal error: Unable to start pcre module in Unknown on line 0
The command also reports that the intl extension cannot be loaded from:
/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20230831/intl.so
Command with the workaround:
LD_LIBRARY_PATH=/lib64 /usr/local/cwp/php71/bin/php -v
Result: PHP 8.3.36 starts successfully, but the intl extension warning remains.
The same behavior occurs with the version check used by the migration script:
/usr/local/cwp/php71/bin/php -r 'echo PHP_MAJOR_VERSION.".".PHP_MINOR_VERSION;'
Without LD_LIBRARY_PATH=/lib64, PHP exits with the PCRE startup fatal error. With the environment variable set, it successfully outputs 8.3.
To restore the CWP administration panel and webmail after the PHP migration, I created these systemd drop-in files:
/etc/systemd/system/cwpsrv-phpfpm.service.d/pcre-library.conf
/etc/systemd/system/cwp-phpfpm.service.d/pcre-library.conf
Both set:
Environment="LD_LIBRARY_PATH=/lib64"
After reloading systemd and restarting the affected services, the administration panel and webmail became accessible again.
However, this workaround does not automatically apply to every CLI invocation of the internal PHP binary.
3. Migration/update checks performed
The following steps have already been completed:
Ran /scripts/update_cwp twice using the required library-path environment.
Both runs completed, but the dashboard problem remained.
Confirmed that the CWP services are active.
Checked /var/log/cwp/cwpphp83_update.log.
The log contains the following message:
php is not 8.3 after install, marker NOT written (will retry next cron)
The script /scripts/update_cwpphp83 defines its PHP version check as:
php_ver() { "$PHP" -r 'echo PHP_MAJOR_VERSION.".".PHP_MINOR_VERSION;' 2>/dev/null; }
The configured PHP path is /usr/local/cwp/php71/bin/php. This check does not explicitly set LD_LIBRARY_PATH=/lib64, so it fails under the current environment.
The marker file /usr/local/cwp/.conf/.cwpphp83.done nevertheless exists and is dated October 25, 2026. I have not deleted the marker or manually modified the migration script.
4. Logs and further observations
The PHP-FPM log is located at:
/usr/local/cwp/php71/var/log/php-fpm.log
It contains repeated warnings similar to:
sed: couldn't write 79 items to stdout: Broken pipe
These occur approximately every five seconds. They appear consistent with a command pipeline closing its output early, but I cannot confirm whether they are related to the dashboard failure.
The log also contains older entries showing that loader_ajax.php was executing slowly. However, I have not found a current PHP fatal error or exception explicitly associated with cpuUsageList.
The CWP internal Nginx error log at /usr/local/cwpsrv/logs/error_log did not reveal a clear cause for the dashboard HTTP 500. Most entries in the inspected section concern unrelated requests for missing Roundcube paths or external probes.
The file /usr/local/cwpsrv/htdocs/admin/admin/loader_ajax.php is ionCube-encoded. I have not modified it.
5. Assistance requested
Could you please investigate the following points?
Dashboard HTTP 500: Why does action=cpuUsageList&fileName=cpuUsage return HTTP 500 after the PHP 8.3.36 migration, while other dashboard requests return HTTP 200?
PHP library environment: Is it expected that /usr/local/cwp/php71/bin/php requires LD_LIBRARY_PATH=/lib64 to start? What is the correct permanent fix for the PCRE startup failure?
Migration completion: Why does the migration script report that PHP is not 8.3 when the binary reports PHP 8.3.36 with the library-path workaround? What is the supported way to verify or complete the migration safely?
intl extension: Why is the migration/update process attempting to load intl.so from the no-debug-non-zts-20230831 directory when the file downloaded by the update process was placed under the older no-debug-non-zts-20170718 directory?
Disk IO widget: Is the blank Disk IO widget related to the same PHP 8.3 migration issue, or should it be investigated separately?
I would appreciate a supported repair procedure or a specific diagnostic patch. I would prefer not to edit ionCube-encoded panel files, remove migration markers, or repeatedly rerun migration scripts without knowing the underlying cause.
Thank you.