Skip to main content

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

matt1206
Just wanting to post this here, as I've spent the last 2 hours fault finding an issue on my servers this morning. cPanel servers, all the latest updates. MariaDB automatically updated to 10.3.26-1 over night as part of the cPanel yum update. As soon as this happened, any XenForo site running on PHP7.2 or below broke! [04-Nov-2020 08:24:41 UTC] PHP Fatal error: Uncaught XF\Db\Exception: MySQL query error [1835]: Malformed communication packet in /home/XXX/public_html/community/src/XF/Db/AbstractStatement.php:212 Stack trace: #0 /home/XXX/public_html/community/src/XF/Db/Mysqli/Statement.php(196): XF\Db\AbstractStatement->getException('MySQL query err...', 1835, 'HY000') #1 /home/XXX/public_html/community/src/XF/Db/Mysqli/Statement.php(77): XF\Db\Mysqli\Statement->getException('MySQL query err...', 1835, 'HY000') #2 /home/XXX/public_html/community/src/XF/Db/AbstractAdapter.php(79): XF\Db\Mysqli\Statement->execute() #3 /home/XXX/public_html/community/src/XF/Db/AbstractAdapter.php(116): XF\Db\AbstractAdapter->query('\n\t\t\tSELECT data...', Array) #4 /home/XXX/public_html/community/src/XF/DataRegistry.php(137): XF\Db\AbstractAdapter->fetchPairs('\n\t\t\tSELECT data...') #5 /home/XXX/public_html/community/src/XF/DataRegistry.php(82): XF\DataRegistry->readFromDb(Array, Array) #6 /home/XXX/public_html/community/src/XF/DataRegistry.php(225): XF\DataRegistry- in /home/XXX/public_html/community/src/XF/Db/AbstractStatement.php on line 212
This also prevents any user accessing MySQL via cPanel: Swapping to 7.3 or 7.4 works. I've had to downgrade MariaDB back to the previous version: # yum history info 264 Loaded plugins: fastestmirror, universal-hooks Transaction ID : 264 Begin time : Wed Nov 4 05:35:28 2020 Begin rpmdb : 1964:269d3e2a5fc59faed15b162386618da46afe3e28 End time : 05:36:05 2020 (37 seconds) End rpmdb : 1964:7aac4ca2ee1e5c81b04babc4f774126e1254d10d User : root Return-Code : Success Command Line : --assumeyes --color=never --config /etc/yum.conf update --disablerepo=epel Transaction performed with: Installed rpm-4.11.3-43.el7.x86_64 @base Installed yum-3.4.3-167.el7.centos.noarch @base Installed yum-metadata-parser-1.1.4-10.el7.x86_64 @anaconda Installed yum-plugin-fastestmirror-1.1.31-54.el7_8.noarch @updates Packages Altered: Updated MariaDB-client-10.3.25-1.el7.centos.x86_64 @MariaDB103 Update 10.3.26-1.el7.centos.x86_64 @MariaDB103 Updated MariaDB-common-10.3.25-1.el7.centos.x86_64 @MariaDB103 Update 10.3.26-1.el7.centos.x86_64 @MariaDB103 Updated MariaDB-compat-10.3.25-1.el7.centos.x86_64 @MariaDB103 Update 10.3.26-1.el7.centos.x86_64 @MariaDB103 Updated MariaDB-devel-10.3.25-1.el7.centos.x86_64 @MariaDB103 Update 10.3.26-1.el7.centos.x86_64 @MariaDB103 Updated MariaDB-server-10.3.25-1.el7.centos.x86_64 @MariaDB103 Update 10.3.26-1.el7.centos.x86_64 @MariaDB103 Updated MariaDB-shared-10.3.25-1.el7.centos.x86_64 @MariaDB103 Update 10.3.26-1.el7.centos.x86_64 @MariaDB103 Updated galera-25.3.30-1.el7.centos.x86_64 @MariaDB103 Update 25.3.31-1.el7.centos.x86_64 @MariaDB103 history info
And this fixes the issue. So, I don't know if it's a PHP issue, a MariaDB issue, or something combining everything! I've excluded MariaDB and Galera now from automatic updates on my servers.

Comments

76 comments

Date Votes
  • filoucp
    In my case ( PDO with PHP7.2 and the Malformed communication packet error ) , It seems the problem only affects the PDO::query function. So rewriting the affected queries with PDO::prepare / PDOStatement::execute do work correctly in my scripts. I know it's not really a good workaround for most, but still better than downgrade or upgrade PHP version in my case.
    0
  • Steini Petur
    This is a temporary fix to upgrade to 10.3.27, until MariaDB pushes 10.3.27 into the 10.3 repo. Use at your own risk. Open file /etc/yum.repos.d/MariaDB103.repo with an editor and change: baseurl = http://yum.mariadb.org/10.3/centos7-amd64
    to baseurl = http://yum.mariadb.org/10.3.27/centos7-amd64
    in order to force yum to update from the v10.3.27 path. Then run yum upgrade to upgrade to 10.3.27 This version fixes both the issue with PHP < 7.2 scripts, as well as the vulnerability reported by Rack911. In some servers I still had to run /scripts/autorepair fix_mariadb_show_grants_roles to fix the MySQL UI error. Finally restart MySQL with /scripts/restartsrv_mysql

    Actually this might be what I can look at, this seems straight forward and so this fixes both the UI and PHP issues, did you run into any issue in any of your nodes (assuming you have many to apply this too)
    0
  • SigmaWeb
    The previous mariadb update (10.3.26) has created problems with some magento installations where mysqld process, produces high CPU load (this doesn't happen with 10.3.25). I was hopping that the new release 10.3.27 will fix this, but unfortunately I see that problem still exists. Does anyone else face this magento - mysqld high CPU load?
    0
  • voip
    MariaDB has released updates to resolve the issue case MDEV-24121:
    0
  • George_Fusioned
    Actually this might be what I can look at, this seems straight forward and so this fixes both the UI and PHP issues, did you run into any issue in any of your nodes (assuming you have many to apply this too)

    Nope, no issues at all with that workaround to install 10.2.36 / 10.3.27 although it might be obsolete now since MariaDB released the packages in their main repos: Emergency Release of MariaDB 10.5.8, 10.4.17, 10.3.27, and 10.2.36 is now available - MariaDB.org
    0
  • George_Fusioned
    The previous mariadb update (10.3.26) has created problems with some magento installations where mysqld process, produces high CPU load (this doesn't happen with 10.3.25). I was hopping that the new release 10.3.27 will fix this, but unfortunately I see that problem still exists. Does anyone else face this magento - mysqld high CPU load?

    We've had a few servers with abnormally high RAM usage after upgrading from 10.3.25 -> 10.3.26, but it's stable again with 10.3.27 I believe it was related to [MDEV-24117] Memory management problem in statistics state for queries that have a large field IN (values) part - Jira
    0
  • Domenico
    When will cPanel update the MariaDB upgrade to the latest and safe version within WHM ?
    0
  • George_Fusioned
    If you run a upcp now, rpmup should get the latest/fixed MariaDB packages.
    0
  • cPRex Jurassic Moderator
    That is correct - cPanel doesn't manage the MariaDB packages as those get pulled directly from the MariaDB repositories.
    0
  • Domenico
    Yeah I know but that was not what I meant. Either way, it is fixed now. Thanks for your reply. :)
    0
  • cPRex Jurassic Moderator
    @MindServer - I can't say for sure as there have been many changes to your system that you've outlined in this thread. The autofixer may have run previously, but it was only designed to run once on the system.
    0
  • colin12345
    I have the same problem, I couldn't access or create any databases in Cpanel. Just wonder, how do I run the script? I could see the instructions is to run /scripts/autorepair fix_mariadb_show_grants_roles but how do I do this? Is there a step by step instructions on how to do this? Thanks.
    0
  • colin12345
    You only need login with SSH access in your Linux Terminal and execute the command: /scripts/autorepair fix_mariadb_show_grants_roles Copy and paste him in Terminal. Have a nice day.

    Thank you for your reply, I'll try this.
    0
  • Kent Brockman
    If you want to solve it with a single chain of commands, you can do this: yum versionlock clear && yum -y upgrade MariaDB-* && /scripts/autorepair fix_mariadb_show_grants_roles && /scripts/upcp
    Worked for us and our servers :)
    0
  • Nurs1927
    If you want to solve it with a single chain of commands, you can do this: yum versionlock clear && yum -y upgrade MariaDB-* && /scripts/autorepair fix_mariadb_show_grants_roles && /scripts/upcp
    Worked for us and our servers :)

    Solved for me whit this command. Thanks.
    0
  • cPRex Jurassic Moderator
    At this point the upstream issues have been resolved. That, in combination with the autofixer means this should no longer be an issue so I'm marking this as resolved.
    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post