Known Issues Status Page - cPanel version 84
Known Issues Status Page
This thread includes status updates for known technical issues.
Reminder: cPanel & WHM version 84 was introduced to the RELEASE update tier on 2019.10.29. Please reply to this thread if you encounter technical issues after updating your server to this version.
You can read more about cPanel & WHM Version 84 on
-
I'm looking forward in having this fixed ASAP. 0 -
In my opinion, cPanel should protect their clients and instead of us having to disable automatic upgrades, cPanel would disable their update servers until they update their packages and issue is fixed.
Keep in mind that your server is using the upstream MariaDB repositories, thus it's not something for cPanel to really fix, it's not their update servers that pulled in a broken package, it's the MariaDB repo itself that has decided to not pull the broken package. cPanel provides information on how to do a rollback, but since the packages are not distributed by them, it's hard for them to control it really. It's just like if any other package by other repositories got pushed and it happened to be broken. You as a system administrator should make up with yourself whether you want automated updates enabled for OS packages (and then stuff like this can happen), or if you disable these automated updates and have a maintenance window every X weeks.0 -
last night we had the automated upgrade of mariadb in the whm/cpanel which caused us too much pain with our hosted clients ! this is really ridiculous, why there is no notification from cpanel or mariadb, they already knew this could happen ? why it was not stopped before the impact 0 -
We had a bunch of clients complaining about this situation today morning, and we were able to successfully sort and took the precautions to avoid this until a new patch available on MariaDB repos on all those servers. Thanks for providing this workaround, that helped us very much to manage this situation. :) But, the same upgrade isn't affected on my own server where a few sites are running (having MariaDB 10.1.42). So I guess this upgrade probably might not affected all the users out there, but majority seems to be affected. Not sure what caused this to happen, and why this weren't affected on some systems. The bug discussed on their official Jira thread . 0 -
Hi, So MariaDB Server marked the issues as fixed for 10.2.29, 10.4.10 (Index of /10.3/centos7-amd64/rpms/. ? 0 -
Hello Everyone, MariaDB published an update on November 5th, 2019 that can cause MariaDB to fail upon startup on cPanel & WHM servers. We've identified this as an upstream issue with MariaDB (MDEV-19073) affecting the following MariaDB versions: 10.1.42 10.2.28 10.3.19 10.4.9 The following error message is visible in the MariaDB startup output on affected systems: MariaDB is aware of the issue and working to solve it. We'll update this post with more information on the status of MariaDB case MDEV-19073 as it becomes available. The only known workaround at this time is to perform a downgrade of the MariaDB RPM packages. While there are no supported methods of downgrading MariaDB using cPanel & WHM, you or your system administrator can manually perform this downgrade using the following command:
yum downgrade MariaDB-server MariaDB-common MariaDB-shared MariaDB-client MariaDB-compat MariaDB-devel
Note: The above workaround is intended as a temporary workaround only. If your cPanel & WHM server is configured to automatically update your system packages, the issue will re-occur each time the MariaDB RPMs are upgraded until MariaDB publishes a fix for case MDEV-19073. If you have any questions about this, please let us know. Thank you.
Hi, my sql version is mysql (10.2.28-MariaDB-log) details-status: down You say that in the affected platforms this message will exist: " InnoDB: Failing assertion: table->can_be_evicted " However, the error messages that I occur say :https://mars.ignitionserver.net:2083/cpsess9316819161/3rdparty/phpMyAdmin/themes/dot.gif
mysqli_connect(): (HY000/2002): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) I cannot locate those files, rather than I have access to my WHM. My website status is: "Could not connect to MySQL" Am I also affected from this update? Or is something else that I have to take care ? Thanks0 -
But, the same upgrade isn't affected on my own server where a few sites are running (having MariaDB 10.1.42). So I guess this upgrade probably might not affected all the users out there, but majority seems to be affected. Not sure what caused this to happen, and why this weren't affected on some systems. The bug discussed on their official Jira thread MDEV-20621. MySQL 5.6 (and MariaDB 10.0) introduced eviction of tables from the InnoDB data dictionary cache. Tables that are connected to FOREIGN KEY constraints or FULLTEXT INDEX are exempt of the eviction. With the 10.1.43, 10.3.20, here) about 25 mins ago. I'm I right in saying it now a case of waiting for it to be release here.. can_be_evicted " However, the error messages that I occur say :
https://mars.ignitionserver.net:2083/cpsess9316819161/3rdparty/phpMyAdmin/themes/dot.gif
mysqli_connect(): (HY000/2002): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) I cannot locate those files, rather than I have access to my WHM. My website status is: "Could not connect to MySQL" Am I also affected from this update? Or is something else that I have to take care ? Thanks
It's hard to say without seeing the MySQL error logs (typically /var/lib/mysql/$hostname.err). My recommendation is to open a support ticket so we may verify the issue. Thanks!0 -
Running the downgrade allow the DB services to come back online for me. yum downgrade MariaDB-server MariaDB-common MariaDB-shared MariaDB-client MariaDB-compat MariaDB-devel0 -
We have lost access to our WHM so I cannot open any tickets, any advice? please ASAP 0 -
We have lost access to our WHM so I cannot open any tickets, any advice? please ASAP
Are you able to access the server via SSH? You can get the cPanel support ID with this command:/usr/local/cpanel/cpanel -S
SSH access will be needed to investigate the issue. If you are unable to access SSH, then we recommend reaching out to your provider to see what issues may be occurring.0 -
It will update again. You should exclude it in yum.conf for now 0 -
Hi All, yum downgrade MariaDB-server MariaDB-common MariaDB-shared MariaDB-client MariaDB-compat MariaDB-devel
it worked in some of my clients servers...0 -
It will update again. You should exclude it in yum.conf for now
What is the best way to exclude it in the yum.conf?0 -
Hello Everyone, MariaDB has fixed the issue in the following unpublished versions: 10.1.43 [ 23703 ] 10.2.29 [ 23911 ] 10.3.20 [ 23909 ] 10.4.10 [ 23907 ] We don't have a specific time frame to share on the publication of the updated RPMs, but we'll update this thread as soon as they are published. We strongly recommend avoiding workarounds that take the extra step of disabling automatic updates unless you or your system administration team has a process in-place to monitor the issue and enable automatic updates again once the issue is solved. Thank you. 0 -
@GOT the problem appears on databases using FULLTEXT KEY indexes. Moving/removing those databases from the data directory enables the server to startup. You can find this databases looking for file names starting with "FTS*" inside the database directory: user_database/FTS_000000000005cf3b_CONFIG.ibd 0 -
Update: We've found that MariaDB has removed all affected versions from their repository - At this time the instructions to prevent update using yum-versionlock are no longer necessary. If you did update and were affected, you would still need to downgrade until the issue is resolved and a new build is pushed out by MariaDB but you will not be upgraded to an affected version. 0 -
Update: We've found that MariaDB has removed all affected versions from their repository - At this time the instructions to prevent update using yum-versionlock are no longer necessary. If you did update and were affected, you would still need to downgrade until the issue is resolved and a new build is pushed out by MariaDB but you will not be upgraded to an affected version.
Had to run yum clean all, then it worked.0 -
I was so angry in the morning, we have a couple of servers down this morning, we are [Moderator Note: Removed Link To Third-Party URL] and we usually have latest version of whm and litespeed, I had no idea what was wrong until i decided to open a ticket, then i found the issue and we finally resolved downgrading, but it was like 2 hours trying ourselves with our customers calling, not good at all 0 -
Hello, In my case, one of my clients was affected by this problem. The solution in our case, to the little information 24 hours ago when it happened, was to restore a backup of the databases, even though we tried all kinds of alternatives to solve it. At that point, we decided to remove the databases, and replace them with a backup a few hours earlier. Therefore, in our case, the bug version is maintained, but everything works correctly after recovering the databases from a backup. So... What can be expected from the behavior of this server? Should it work well? Should we do downgrade even though everything works correctly? Thanks 0 -
Praying they have a fix for this soon... Downgrading only solved the problem for some of my servers, might have to roll back more on others. cPanel team please post an update when you know more. Thanks! 0 -
Update: We've found that MariaDB has removed all affected versions from their repository - At this time the instructions to prevent update using yum-versionlock are no longer necessary. If you did update and were affected, you would still need to downgrade until the issue is resolved and a new build is pushed out by MariaDB but you will not be upgraded to an affected version.
Is this a guarantee? I'm scared to turn automatic updates back on and go through this again. I was down 16 hours until support found out what was going on.0 -
yum downgrade MariaDB-server MariaDB-common MariaDB-shared MariaDB-client MariaDB-compat MariaDB-devel
Note: The above workaround is intended as a temporary workaround only. If your cPanel & WHM server is configured to automatically update your system packages, the issue will re-occur each time the MariaDB RPMs are upgraded until MariaDB publishes a fix for case MDEV-19073.
from this quote " If your cPanel & WHM server is configured to automatically update your system packages, the issue will re-occur each time the MariaDB RPMs are upgraded until MariaDB publishes a fix for case MDEV-19073. " how to disable server updates from WHM??? is it here:// ??- Home "
- Server Configuration "
- Update Preferences
- Automatic
- Manual Updates Only
- Never Update
- Automatic
- Manual Updates Only
- Never Update
- YES CORRECT
- No
0 -
I Set first Operating System Package Updates To Manual Updates Only And after went ssh run the downgrade command...? I can Not enter SSH I think forgot where is a public key and in what machine (PC)--- I have over 3 years to login since $ ssh rootUsername@xxx.xxx.xxx.xxx rootUsername@xxx.xxx.xxx.xxx: Permission denied (publickey,gssapi-keyex,gssapi-with-mic). Is it OK - give the command from WHM/Terminal in the browser as shown below????? What other solutions exist??? -ssh-terminal.jpg">61957 I mean this cmd here ^^^ >>> yum downgrade MariaDB-server MariaDB-common MariaDB-shared MariaDB-client MariaDB-compat MariaDB-devel0 -
yum downgrade MariaDB-server MariaDB-common MariaDB-shared MariaDB-client MariaDB-compat MariaDB-devel
I ran this on Browser/WHM/Terminal and now all working MariaDB....!!0 -
Hello, In my case, one of my clients was affected by this problem. The solution in our case, to the little information 24 hours ago when it happened, was to restore a backup of the databases, even though we tried all kinds of alternatives to solve it. At that point, we decided to remove the databases, and replace them with a backup a few hours earlier. Therefore, in our case, the bug version is maintained, but everything works correctly after recovering the databases from a backup. So... What can be expected from the behavior of this server? Should it work well? Should we do downgrade even though everything works correctly? Thanks
@kennysamuerto downgrade your MariaDB anyway. After the restore if you restart MariaDB, or run a mysqlcheck on databases that use FULLTEXT indexes, it will probably crash again. I tried the restore before downgrading the installation, and the server crashed in the first restart, after restoring one of those specific databases.0 -
from this quote " If your cPanel & WHM server is configured to automatically update your system packages, the issue will re-occur each time the MariaDB RPMs are upgraded until MariaDB publishes a fix for case MDEV-19073. " how to disable server updates from WHM??? is it here:// ??
Again, I'd like to point out the following:Update: We've found that MariaDB has removed all affected versions from their repository - At this time the instructions to prevent update using yum-versionlock are no longer necessary. If you did update and were affected, you would still need to downgrade until the issue is resolved and a new build is pushed out by MariaDB but you will not be upgraded to an affected version.
Furthermore, MariaDB have fixed the affected packages and we're just waiting on them to be pushed - we will update here when that is complete, we're hoping for today.0 -
Looks like they have now released it: Index of /10.3/centos7-amd64/rpms/ 0
Please sign in to leave a comment.
Comments
74 comments