SOLVED CPANEL-34745 - MariaDB 10.3.26-1 Breaks PHP < 7.2

[foolix]

do you have a tutorial to downgrade?

it was reported in the cpanel article before the last update:

yum downgrade MariaDB-server MariaDB-common MariaDB-shared MariaDB-client MariaDB-compat MariaDB-devel

 

[wintech2003]

do you have a tutorial to downgrade?

First disable MySQL service monitoring

$ whmapi1 configureservice service=mysql enabled=1 monitored=0

Backup MySQL (make sure you have enough disk space)

$ mkdir -p ~/mysqlbkp
$ service mysql restart --skip-networking --skip-grant-tables
$ mysql_upgrade
$ mysqldump --all-databases --routines --triggers > ~/mysqlbkp/dbcopy.sql
$ service mysql stop
$ cp -r /var/lib/mysql/mysql ~/mysqlbkp/
$ service mysql start

Then downgrade:

$ yum downgrade MariaDB-server MariaDB-common MariaDB-shared MariaDB-client MariaDB-compat MariaDB-devel

and re-enable MySQL service monitoring:

$ whmapi1 configureservice service=mysql enabled=1 monitored=1

 

[Fabio Esparza]

now MARIADB have last Ver.
Lets try

mysql -e "ALTER TABLE mysql.user MODIFY COLUMN password_last_changed timestamp AFTER max_statement_time, MODIFY COLUMN password_lifetime smallint AFTER password_last_changed, MODIFY COLUMN account_locked enum('N','Y') AFTER password_lifetime"
/scripts/restartsrv_mysql

All issues solved, no error in CPANEL MYSQL DATABASES or CPANEL DB Wizard

Confirming this fix solves the problem without needing to downgrade.

 

[wintech2003]

Confirming this fix solves the problem without needing to downgrade.

This only fixes the MySQL Databases interface issue, not the broken PHP applications that use PHP < 7.2, right?

 

[Nurs1927]

mysql -e "ALTER TABLE mysql.user MODIFY COLUMN password_last_changed timestamp AFTER max_statement_time, MODIFY COLUMN password_lifetime smallint AFTER password_last_changed, MODIFY COLUMN account_locked enum('N','Y') AFTER password_lifetime"
/scripts/restartsrv_mysql

All issues solved, no error in CPANEL MYSQL DATABASES or CPANEL DB Wizard

ERROR 1054 (42S22) at line 1: Unknown column 'password_last_changed' in 'user'

 

[cPRex]

@wintech2003 - correct. CPANEL-34745 is specifically for the interface issue.

The PHP update case is something we're monitoring upstream in case UPS-282, with additional details here: After MariaDB update, PHP website has database connection error, 500 error, or white page: MySQL query error: Malformed communication packet

 

[HostT]

When cPanel is aware of these issues, it should send a mailing commenting what the hell is happenning, and provide the workaround. That would save both customers and support staff the hundreds of hours/man to debug, think, investigate, and add to that the time we have to lose apologizing with our end customers.

Or if you don't want to spend money sending thousands of emails, add a notification function to WHM so it can show a warning saying "Hey dude! MariaDB did it again, here are the symptoms and the workaround. Thanks for keep paying. Love. cPanel." (Yep, actually I WANT to see such a warning and I assure you other admins will absolutelly love it too.)

And please, don't send me to open a Feature Request. Be proactive guys, we are paying a lot of money for you to make the best panel and this feature shouldn't be that complicated. Don't stagnate please.

i couldn't agree more, first the price hikes and now they prove why they are worth the extra price tag .... pft. Took me an hour of debugging to finally find this thread here to deal with the issue, which took down hundreds of my client sites.

 

[cPRex]

While I like the idea, I'm not sure that type of notification system would actually work. In order to apply a change to the WHM interface with how things are currently, the server would need to experience an update. So with the MariaDB event here the timeline would look something like this:

-issue caused by update Tuesday night/Wednesday morning
-problem reported and identified
-custom code written to confirm the server is affected by the issue, and added to a display banner in WHM
-If the above can be safely done in one day, the next update runs Wednesday night/Thursday morning. This assumes that updates are not disabled to resolve the issue.

So at the minimum, you're still looking at 24 hours for any type of update feature or notification with the current system. A new, more active tool might be best, but that would be an entirely new feature in the product.

 

[matt1206]

Will this have any impact for servers where MariaDB has been downgraded? I'm not prepared to update MariaDB again as there are multiple sites I host that still require < PHP7.3.

 

[cPRex]

The autofixer is to resolve the issues caused in the cPanel databases interface. It doesn't affect the PHP issues, so you'd still want to stay on the older version if you don't want to upgrade PHP just yet.

 

[MindServer]

The autofixer is to resolve the issues caused in the cPanel databases interface. It doesn't affect the PHP issues, so you'd still want to stay on the older version if you don't want to upgrade PHP just yet.

I have a last question please. How many time you need approximately for solve this error?.

I need know when I will revert the changes ("cPanel" and "yum" updates) and update again MariaDB.

Thank you very much. Have a nice day.

 

[cPRex]

That's a good question - the PHP/MariaDB conflict isn't actually up to cPanel to solve, as that is something that is happening from MariaDB. We are working on a patch for this at this time, but I don't have any estimated time when that will be released. That is being tracked internally with case UPS-282.

 

[Vasiliy80]

friends - i am full noob

i've forum v80.team
2 days ago its down
i told with hosting support - doesnt help
i told with cPanel supp - same, but still trying

i choosу php 7,3 on both cP and WHM - not solved (only white screen before "error500"
i changed language codec in multiphp admin - not solved

what can i do? it is doesnt work???

here is latest log

[07-Nov-2020 00:05:02 UTC] PHP Warning: PHP Startup: Unable to load dynamic library 'pdo.so' (tried: /opt/cpanel/ea-php73/root/usr/lib64/php/modules/pdo.so (/opt/cpanel/ea-php73/root/usr/lib64/php/modules/pdo.so: cannot open shared object file: No such file or directory), /opt/cpanel/ea-php73/root/usr/lib64/php/modules/pdo.so.so (/opt/cpanel/ea-php73/root/usr/lib64/php/modules/pdo.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
[07-Nov-2020 00:05:02 UTC] PHP Warning: PHP Startup: Unable to load dynamic library 'pdo_sqlite.so' (tried: /opt/cpanel/ea-php73/root/usr/lib64/php/modules/pdo_sqlite.so (/opt/cpanel/ea-php73/root/usr/lib64/php/modules/pdo_sqlite.so: cannot open shared object file: No such file or directory), /opt/cpanel/ea-php73/root/usr/lib64/php/modules/pdo_sqlite.so.so (/opt/cpanel/ea-php73/root/usr/lib64/php/modules/pdo_sqlite.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
[07-Nov-2020 00:05:02 UTC] PHP Warning: PHP Startup: Unable to load dynamic library 'sqlite.so' (tried: /opt/cpanel/ea-php73/root/usr/lib64/php/modules/sqlite.so (/opt/cpanel/ea-php73/root/usr/lib64/php/modules/sqlite.so: cannot open shared object file: No such file or directory), /opt/cpanel/ea-php73/root/usr/lib64/php/modules/sqlite.so.so (/opt/cpanel/ea-php73/root/usr/lib64/php/modules/sqlite.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
[07-Nov-2020 00:05:02 UTC] PHP Warning: PHP Startup: Unable to load dynamic library 'pdo_mysql.so' (tried: /opt/cpanel/ea-php73/root/usr/lib64/php/modules/pdo_mysql.so (/opt/cpanel/ea-php73/root/usr/lib64/php/modules/pdo_mysql.so: cannot open shared object file: No such file or directory), /opt/cpanel/ea-php73/root/usr/lib64/php/modules/pdo_mysql.so.so (/opt/cpanel/ea-php73/root/usr/lib64/php/modules/pdo_mysql.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
[07-Nov-2020 00:05:02 UTC] PHP Fatal error: Uncaught Error: Call to undefined function IPS\mb_internal_encoding() in /home/sxafkzbe/public_html/init.php:493
Stack trace:
#0 /home/sxafkzbe/public_html/init.php(1420): IPS\IPS::init()
#1 /home/sxafkzbe/public_html/index.php(12): require_once('/home/sxafkzbe/...')
#2 {main}
thrown in /home/sxafkzbe/public_html/init.php on line 493

how make it working?

 

[max101]

how to we disable mariadb updates? i downgraded then this morning to 10.3.25 then the next day it went back to 10.3.26

 

[MindServer]

how to we disable mariadb updates? i downgraded then this morning to 10.3.25 then the next day it went back to 10.3.26

Hi,

You can edit the file "/etc/cpupdate.conf" and change "RPMUP=daily" to "RPMUP=manual".

With this you will stop cPanel updates. Have a nice day.

 

[Vasiliy80]

Whats news? workaround doesnt work

 

[Vasiliy80]

all solved

cP support

Assigned to Suede Young Id #93888880

 

[Kent Brockman]

The autofixer is to resolve the issues caused in the cPanel databases interface. It doesn't affect the PHP issues, so you'd still want to stay on the older version if you don't want to upgrade PHP just yet.

Such autofixer is being run on every nightly update? So, by tomorrow it would be safe to unlock updates for MariaDB on servers with websites running PHP>= 7.3, is this correct?

 

[Nurs1927]

Hello, doesn´t work for me.

/scripts/autorepair fix_mariadb_show_grants_roles
Requesting script ... info [autorepair] Successfully verified signature for cpanel (key types: release).
Done
Auto Repair is running......Auto Repair is done.

Nothing happens

mysql -e "ALTER TABLE mysql.user MODIFY COLUMN password_last_changed timestamp AFTER max_statement_time, MODIFY COLUMN password_lifetime smallint AFTER password_last_changed, MODIFY COLUMN account_locked enum('N','Y') AFTER password_lifetime"
ERROR 1054 (42S22) at line 1: Unknown column 'password_last_changed' in 'user'

Doesn´t work.

My solution is only downdgrade MariaDB.
Any idea?

CENTOS 7.8 [server] V90.0.16
PHP 7.2
MariaDB 10.3.25-MariaDB

 

[WebSavvyGuy]

I am having the same issues as the OP. My Xenforo forums is down. I am running PHP 7.2 and cannot update to PHP 7.4 because it will break other applications.

I ran the autofixer suggested by Cpanel:

/scripts/autorepair fix_mariadb_show_grants_roles

However, the Xenforo site is still down.

Any other suggestions besides downgrading? (which I don't really want to do)