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

Operating System & Version
CentOS Linux release 7.8.2003 (Core)
cPanel & WHM Version
v90.0.16

wintech2003

Well-Known Member
PartnerNOC
Sep 15, 2010
98
26
68
Greece
cPanel Access Level
DataCenter Provider
do you have a tutorial to downgrade?
First disable MySQL service monitoring
Code:
$ whmapi1 configureservice service=mysql enabled=1 monitored=0
Backup MySQL (make sure you have enough disk space)
Code:
$ 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:
Code:
$ yum downgrade MariaDB-server MariaDB-common MariaDB-shared MariaDB-client MariaDB-compat MariaDB-devel
and re-enable MySQL service monitoring:
Code:
$ whmapi1 configureservice service=mysql enabled=1 monitored=1
 

Fabio Esparza

Registered
Jul 7, 2019
1
0
1
Mexico
cPanel Access Level
Root Administrator
now MARIADB have last Ver.
Lets try

Code:
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.
 

Nurs1927

Well-Known Member
Nov 22, 2015
92
7
58
Spain
cPanel Access Level
Root Administrator
Code:
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

Jurassic Moderator
Staff member
Oct 19, 2014
2,194
298
213
cPanel Access Level
Root Administrator

HostT

Member
Dec 7, 2010
17
2
53
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.
 
  • Like
Reactions: Kent Brockman

cPRex

Jurassic Moderator
Staff member
Oct 19, 2014
2,194
298
213
cPanel Access Level
Root Administrator
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

Active Member
Dec 20, 2011
41
2
58
cPanel Access Level
Root Administrator
1604684477949.png

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.
 

MindServer

Well-Known Member
Mar 18, 2020
189
30
28
Spain
cPanel Access Level
Root Administrator
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

Jurassic Moderator
Staff member
Oct 19, 2014
2,194
298
213
cPanel Access Level
Root Administrator
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.
 
  • Like
Reactions: MindServer

Vasiliy80

Registered
Nov 6, 2020
4
0
0
Kenya
cPanel Access Level
Website Owner
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?
 
Last edited:

Kent Brockman

Well-Known Member
PartnerNOC
Jan 20, 2008
1,257
60
178
Buenos Aires, Argentina
cPanel Access Level
Root Administrator
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

Well-Known Member
Nov 22, 2015
92
7
58
Spain
cPanel Access Level
Root Administrator
Hello, doesn´t work for me.

Code:
/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

Code:
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

Registered
May 10, 2018
3
0
1
China
cPanel Access Level
Root Administrator
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)