Recent posts

Pages 1 2 3 4 5 6 ... 10
#31
CentOS-WebPanel Bugs / Re: CWP Pro 1.26 – Dashboard C...
Last post by jeffshead - October 29, 2026, 02:01:22 PM
I have the same issues since updating to CWP 1.26.
#32
CentOS-WebPanel Bugs / Re: Bug in /scripts/stats_goac...
Last post by overseer - October 29, 2026, 11:56:12 AM
Good find -- guess the devs make some typos every now & again. Also in /usr/local/cwpsrv/conf/cwpsrv.conf it looks as though someone fell asleep on their keyboard and put dozens of extra returns in the middle of the file. Still works, though -- so no harm done there.
#33
CentOS-WebPanel Bugs / Bug in /scripts/stats_goaccess...
Last post by Wonder - October 29, 2026, 10:37:32 AM
Hello,

I've found the same syntax error in `/scripts/stats_goaccess` on three different CWP servers:

- Two servers running AlmaLinux 8.
- One server running AlmaLinux 9.

The daily CWP cron reports:

Code Select
/scripts/stats_goaccess: line 58: unexpected EOF while looking for matching ``'
/scripts/stats_goaccess: line 78: syntax error: unexpected end of file

After investigating, I found that the first line of the script contains an unexpected backtick:

Code Select
`#!/bin/bash

Instead of:

Code Select
#!/bin/bash

Removing the leading backtick fixes the syntax error.

I've applied the correction to all three servers and confirmed that:

Code Select
bash -n /scripts/stats_goaccess

completes successfully without any errors.

Since the same issue appears on three independent installations, it seems likely that the script distributed by CWP contains this typo.

Could you please check whether the original script needs to be corrected?

Also, could a future CWP update overwrite the locally corrected file?

Thanks!
#34
CentOS 9 Problems / AlmaLinux 9 – Daily CWP cron a...
Last post by Wonder - October 29, 2026, 10:27:40 AM
Hello,

I'm running CWP on a fresh AlmaLinux 9 installation with MariaDB 10.11.19.

Every day, the /etc/cron.daily/cwp job produces the following error:
Code Select
warning: /var/tmp/rpm-tmp.JqiLiL: Header V4 DSA/SHA1 Signature, key ID cd2efd2a: NOKEY
error: Failed dependencies:
    perl(DBD::mysql) >= 1.0 is needed by percona-toolkit-2.2.16-1.noarchI've checked the installed packages:
Code Select
# rpm -q perl-DBD-MySQL perl-DBD-MariaDB percona-toolkit

package perl-DBD-MySQL is not installed
perl-DBD-MariaDB-1.21-17.el9.x86_64
package percona-toolkit is not installedThe installed MariaDB Perl driver provides:
Code Select
# rpm -q --provides perl-DBD-MariaDB | grep -Ei 'DBD|mysql'

perl(DBD::MariaDB) = 1.21
perl-DBD-MariaDB = 1.21-17.el9
perl-DBD-MariaDB(x86-64) = 1.21-17.el9However, the old Percona Toolkit package requires perl(DBD::mysql), which is not provided by perl-DBD-MariaDB.

I've also checked the enabled repositories:
Code Select
# dnf list --available percona-toolkit

Error: No matching Packages to listSearching /scripts, /etc/cron.daily and /etc/cron.d for references to percona-toolkit or DBD::mysql returned no results.

MariaDB is running normally, and the daily MySQL backup job completes without reporting database connection errors.

My questions are:

Why does the daily CWP cron still attempt to install Percona Toolkit 2.2.16?

Is this package actually required by CWP on AlmaLinux 9?

Is there an official fix to prevent this obsolete package installation attempt without modifying CWP's internal scripts?

I haven't installed perl-DBD-MySQL or forced the installation of Percona Toolkit, as I would prefer to avoid possible package conflicts with MariaDB.

Thanks in advance!
#35
Migration from other control panels / Re: CWP to CWP migration NOT W...
Last post by comokoko - October 29, 2026, 08:34:00 AM
Does the CWP team monitor the forum? Because whenever we open a ticket to report a bug, the only response we get is: pay for support!

They even demand payment for a ticket just to report a bug.
#36
CentOS-WebPanel Bugs / CWP Pro 1.26 – Dashboard CPU U...
Last post by Painkiller88 - October 29, 2026, 08:14:05 AM
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.
#37
Other / Re: Support form in Turkey
Last post by Starburst - October 29, 2026, 05:00:18 AM
I know, updated to the latest 2.1.8, looks nice wit the new theme also.
#38
Migration from other control panels / Re: CWP to CWP migration NOT W...
Last post by cata77 - October 28, 2026, 10:43:56 PM
Same issue for me
#39
Other / Re: Support form in Turkey
Last post by overseer - October 28, 2026, 09:05:48 PM
Well, glory be! An up-to-date Simple Machines forum install! Hooray! Go team, go!
#40
CentOS 8 Problems / Re: sed: can't read /usr/local...
Last post by Wonder - October 28, 2026, 07:04:06 PM
Quote from: overseer on October 27, 2026, 02:08:03 PM
I'll have to let Starburst answer; my servers are all AL8 (for now).
You're right to have AL8; installing AL9 was a nightmare... The installer should be updated...
Pages 1 2 3 4 5 6 ... 10