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
-
[QUOTE]Post Last Updated on 2019.30.10 at 23:03 UTC
Hello Everyone :) If your cPanel & WHM server is configured to use RELEASE in WHM's Update Preferences interface (WHM >> Home >> Server Configuration > Update Preferences), then you may encounter the following warning message: [QUOTE]cPanel has temporarily disabled updates on the central httpupdate servers. Please try again later.
This is by design while we investigate an issue related to POP/IMAP login failures affecting servers using cPanel & WHM version 84.0.5. We will re-enable the RELEASE tier and update this post once the identified issues have been addressed. Thank you for your patience during this time.0 -
Hello Everyone :) cPanel & WHM version 84.0.6 is now published to our RELEASE and CURRENT tiers with the following update: Fixed case CPANEL-30166: Update rpm.versions for dovecot 2.3.7.2-3.cp1178. Thank you. 0 -
So in 84.0.6 this problem was solved? "This is by design while we investigate an issue related to POP/IMAP login failures affecting servers using cPanel & WHM version 84.0.5." 0 -
So in 84.0.6 this problem was solved? "This is by design while we investigate an issue related to POP/IMAP login failures affecting servers using cPanel & WHM version 84.0.5."
seems to be working for me, I have 84.06 installed on CentOS7.7 vps and POP/IMAP working for me :)0 -
i have 84.06 installed on CLOUDLINUX 7.7 kvm - vps and POP/IMAP working for me also, but i was curios if officially it was resolved. 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: [QUOTE]InnoDB: Failing assertion: table->can_be_evicted
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.0 -
@cPanelLauren We have MariaDB in our servers. Should we disable Daily Updates until this has been fixed? 0 -
We have Maria on our servers newest is 10.3.19-MariaDB and all others are 10.0.38-MariaDB and we have servers set to stable version version 82.0.17 so can we ignore this ? 0 -
We have Maria on our servers newest is 10.3.19-MariaDB and all others are 10.0.38-MariaDB and we have servers set to stable version version 82.0.17 so can we ignore this ?
Hello Everyone, Earlier today, there was an update to MariaDB that causes this error to show up in the log files for the database system:
InnoDB: Failing assertion: table->can_be_evicted
This error will cause MariaDB to fail upon startup. We've identified this as an upstream issue with MariaDB affecting the following versions of the MariaDB SQL Server: 10.1.42 10.2.28 10.3.19 10.4.90 -
I know but our one is running whm version 82.0.17 stable 0 -
I know but our one is running whm version 82.0.17 stable
OS Package Updates are separate from the WHM version.0 -
OS Package Updates are separate from the WHM version.
So if i click never update on Daily updates & never update on operating system packages updates for now will that stop them until it's sorted.0 -
So if i click never update on Daily updates & never update on operating system packages updates for now will that stop them until it's sorted.
Daily updates are for cPanel/WHM and while it may resolve the issue if you select OS Package updates = never the advised solution is to add an exclusion as noted previously.0 -
Daily updates are for cPanel/WHM and while it may resolve the issue if you select OS Package updates = never the advised solution is to add an exclusion as noted previously.
Our system admin is not here to add the exclusion but i do have OS packages to never update for now which should do the same hopefully.0 -
One last question once this is resolved will this thread be updated so we can set them to update again ? 0 -
One last question once this is resolved will this thread be updated so we can set them to update again ?
Yes, when this is resolved we'll update here accordingly.0 -
We have just had a number of servers impacted by an update, to save people open a ticket with cPanel this is the response we just got from them. Thanks for contacting cPanel support regarding these MariaDB errors. We"ve identified this as an upstream issue with MariaDB, and have reported this to their development staff in case MDEV-20987. Earlier today, there was an update to MariaDB that causes this error to show up in the log files for the database system: InnoDB: Failing assertion: table->can_be_evicted This error will cause MariaDB to fail upon startup. This issue affects the following versions of the MariaDB SQL Server: 10.1.42 10.2.28 10.3.19 10.4.9 There is not yet a fix for this issue, although MariaDB is working on this now. The only known workaround at this time is to perform a downgrade of the MariaDB RPM packages. While there is not a supported method of downgrading through the cPanel tools, you or your administrator can perform this downgrade using the following command: yum downgrade MariaDB-server MariaDB-common MariaDB-shared MariaDB-client MariaDB-compat MariaDB-devel The fix seemed to work for us, so good luck! 0 -
Hi all, I've used the above command to downgrade up to 10.3.17 and after a reboot the service is back. yum downgrade MariaDB-server MariaDB-common MariaDB-shared MariaDB-client MariaDB-compat MariaDB-devel I had to do this twice... from 10.3.19 to 10.3.18 and then again to 10.3.17... hope this helps 0 -
I just tested about a dozen servers and this problem seems to crop up randomly. I'm sure its NOT random, but I cannot figure out what the exact conditions need to be for this to fail. In ten out of 12, everything was fine and for two of them mysql failed to start after the update. I agree the command above seems to resolve it. Not looking forward to waking up tomorrow. 0 -
Hello Everyone, Earlier today, there was an update to MariaDB that causes this error to show up in the log files for the database system:
InnoDB: Failing assertion: table->can_be_evicted
This error will cause MariaDB to fail upon startup. We've identified this as an upstream issue with MariaDB affecting the following versions of the MariaDB SQL Server: 10.1.42 10.2.28 10.3.19 10.4.9 There is not yet a fix for this issue, although MariaDB is aware of the issue and working on this now. The only known workaround at this time is to perform a downgrade of the MariaDB RPM packages. While there is not a supported method of downgrading through the cPanel tools, you or your administrator can perform this downgrade using the following command:yum downgrade MariaDB-server MariaDB-common MariaDB-shared MariaDB-client MariaDB-compat MariaDB-devel
If you have any questions about this, please let me know.
This is unfortunate. Thanks for the heads up Lauren.0 -
If we downgrade, will it try to do an update again? Or is it smart enough to wait for next version? 0 -
yum downgrade MariaDB-server MariaDB-common MariaDB-shared MariaDB-client MariaDB-compat MariaDB-devel
Total 28 MB/s | 172 MB 00:06 Running rpm_check_debug Running Transaction Test Transaction Check Error: package MariaDB-common-10.2.27-1.el6.x86_64 is already installed package MariaDB-client-10.2.27-1.el6.x86_64 is already installed package MariaDB-compat-10.2.27-1.el6.x86_64 is already installed Error Summary -------------
Still down.
Hello, It sounds like there may have been a post scriptlet error which resulted in duplicate packages. May you open a support ticket so we may take a closer look? Thanks!0 -
woke up with 2 servers in this situation, took some time trying to fix mariadb 10.1 till found this thread. downgrade fixed it 0 -
woke up with 2 servers in this situation, took some time trying to fix mariadb 10.1 till found this thread. downgrade fixed it
Hello, Can you downgrade if mariadb is already down?0 -
Please, provide a option to migrate from MariaDB to MySQL 8.0 without changing the database names and users. Thanks! 0 -
If anyone is interested, we have been given this by cPanel, we haven't tested it yet but I am slightly concerned by the fact this could keep happening until the dodgy package is fixed or updates are disabled: Changing the RPM Updates preference to "manual" should prevent this from automatically running. A simple one-liner for this would be the following: sed -i 's/RPMUP=.*/RPMUP=manual/g' /etc/cpupdate.conf ; /scripts/restartsrv_cpsrvd You can read more about the cpupdate.conf file here: 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.
From 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 the0 -
If anyone is interested, we have been given this by cPanel, we haven't tested it yet but I am slightly concerned by the fact this could keep happening until the dodgy package is fixed or updates are disabled: Changing the RPM Updates preference to "manual" should prevent this from automatically running. A simple one-liner for this would be the following: sed -i 's/RPMUP=.*/RPMUP=manual/g' /etc/cpupdate.conf ; /scripts/restartsrv_cpsrvd You can read more about the cpupdate.conf file here:
0 -
Thanks for the quick fix! yum downgrade MariaDB-server MariaDB-common MariaDB-shared MariaDB-client MariaDB-compat MariaDB-devel
I would disable OS updates first thing before it hits your server. You can turn it back on later and add an exclusion. So far we just had one server effected. Got lucky and caught it quick.0 -
So the downgrade has brought mariadb, which is great, but now some errors which started only after the upgrade still persist after the downgrade for example: 2019-11-06 10:24:43 9 [Warning] InnoDB: Cannot add field `country` in table `rtfcc_db`.`tblclients` because after adding it, the row size is 8690 which is greater than maximum allowed size (8126) for a record on index leaf page. 2019-11-06 10:24:43 9 [Warning] InnoDB: Cannot add field `ns1` in table `rtfcc_db`.`tblhosting` because after adding it, the row size is 8763 which is greater than maximum allowed size (8126) for a record on index leaf page. 2019-11-06 10:24:43 9 [Warning] InnoDB: Cannot add field `configoption4` in table `rtfcc_db`.`tblproducts` because after adding it, the row size is 8744 which is greater than maximum allowed size (8126) for a record on index leaf page. 2019-11-06 10:24:43 9 [Warning] InnoDB: Cannot add field `country` in table `rtfcc_db`.`tblquotes` because after adding it, the row size is 8720 which is greater than maximum allowed size (8126) for a record on index leaf page. 2019-11-06 10:24:43 9 [Warning] InnoDB: Cannot add field `adminunread` in table `rtfcc_db`.`tbltickets` because after adding it, the row size is 8538 which is greater than maximum allowed size (8126) for a record on index leaf page.
Any ideas?, I've read the stuff about the innodb row type being DYNAMIC and that, but it doesn't make sense why these errors never occurred before the upgrade to 10.3.19, and they persist in 10.3.180
Please sign in to leave a comment.
Comments
74 comments