cPanel update failure although it was never asked to update?
Hi, today I woke up to my cPanel server sending me this error email, although I have not updated the server in approximately 3 weeks and the preference has always and is still set to not update automatically. Also, it's on LTS which has been on 110.0.17 for more than 1 month and that's what I updated to 3 weeks ago. Why would I receive this from my cPanel server today?
|
-
How does "yum update" look? that could be the reason for the failure.
Andrew N. - cPanel Plesk VMWare Certified Professional
Do you need immediate assistance? 20 minutes response time!*
EmergencySupport - Professional Server Management and One-time Services0 -
OK but why is it trying to update in the first place when automatic updates are turned off?
But to answer your question, this is what comes out of: yum update
error: rpmdb: BDB0113 Thread/process 20117/140096449448000 failed: BDB1507 Thread died in Berkeley DB library
error: db5 error(-30973) from dbenv->failchk: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery
error: cannot open Packages index using db5 - (-30973)
error: cannot open Packages database in /var/lib/rpm
CRITICAL:yum.main:Error: rpmdb open failed
---
DB was repaired with the following, but I still would like to know why cPanel is trying to update my server when automatic updates are turned off:
mv /var/lib/rpm/__db* /tmp/
rpm --rebuilddb
yum clean all0 -
Can you post the output of this command on the server?
cat /etc/cpupdate.conf
0 -
Sure, "cat /etc/cpupdate.conf" outputs:
CPANEL=lts
RPMUP=manual
SARULESUP=daily
STAGING_DIR=/home
UPDATES=manual0 -
That looks good to me, and would be the only thing controlling updates on the cPanel side of things.
It looks like "/scripts/sysup" is what was called to perform that update - do you see anything for that in /var/log/cron? On a normal cPanel system I wouldn't expect to see any entries calling that directly.
0 -
That log is humongous, but over the last 48 hours (which is what it seems to retain unless it was rotated, I really don't know anything about that) there doesn't seem to be any "sysup"... nano returned that "sysup" was not found when CTRL-W for that string in that log file.
0 -
I don't have a good explanation for what would have triggered that, then - we might have to take a look.
0 -
Over the next 6-8 weeks, I have to elevate to Alma Linux to continue using cPanel. There are many road blocks. I might just switch to another server altogether to upgrade the hardware as well because it's been a decade already, so this specific issue is the least of my concerns right now.
But it's very weird that cPanel does not have an explanation for my server trying to update, failing at it, sending me an email about it failing to update, corrupting yum DB while failing and all of this without my consent... kind of concerning... especially when I'm on LTS.
0 -
The failed Yum database issue is the most concerning part for sure, which makes me wonder if/what started it all. Maybe /var/log/messages would have more data, but it's hard to say.
Personally, I would just do a migration to new hardware at that point and not worry about ELevate.
0 -
Even if you have in /etc/cpupdate.conf
RPMUP=manual
and
UPDATES=manualcPanel will run /scripts/upcp
I was testing this, and in the update log I see:
[2024-01-08 23:49:06 +0200] Processing: Updating system packages: sysup
[2024-01-08 23:49:06 +0200] - Processing command `/usr/local/cpanel/scripts/sysup`
[2024-01-08 23:49:06 +0200] [/usr/local/cpanel/scripts/sysup] checkyum version 22.3 (excludes: bind-chroot)
[2024-01-08 23:49:07 +0200] [/usr/local/cpanel/scripts/sysup] All Needed Packages are already installed.
[2024-01-08 23:49:07 +0200] - Finished command `/usr/local/cpanel/scripts/sysup` in 0.967 secondsIn top of the update log it says
:
[2024-01-08 23:49:02 +0200] cPanel & WHM updates are disabled via cron because they are set to “manual” in /etc/cpupdate.conf1 -
Alright, so this is a little bit less concerning then, because cPanel's failure email is just incorrect in stating that it failed to update my server. What it meant is that upcp triggered yum update and THAT is what failed because its DB was corrupted. I'm not very worried about that as I quickly repaired it with the 3 commands in my 2nd post above. Yes, I will migrate to more modern hardware with Alma Linux and so I think we can close this thread. Thanks.
0 -
I do agree that one of the first thing in the upcp check is the RPM verification. We can see that here:
[2024-01-09 16:19:06 +0000] Processing: Checking RPM DB for corruption
[2024-01-09 16:19:06 +0000] - Processing command `/usr/local/cpanel/scripts/find_and_fix_rpm_issues`
[2024-01-09 16:19:06 +0000] [/usr/local/cpanel/scripts/find_and_fix_rpm_issues] glibc-2.28-236.el8.7.x86_64
[2024-01-09 16:19:06 +0000] [/usr/local/cpanel/scripts/find_and_fix_rpm_issues] Testing if rpm_is_working RPM is installed
[2024-01-09 16:19:06 +0000] [/usr/local/cpanel/scripts/find_and_fix_rpm_issues] Testing if it's possible to install a simple RPM
[2024-01-09 16:19:06 +0000] [/usr/local/cpanel/scripts/find_and_fix_rpm_issues] Verifying... ########################################
[2024-01-09 16:19:06 +0000] [/usr/local/cpanel/scripts/find_and_fix_rpm_issues] Preparing... ########################################
[2024-01-09 16:19:06 +0000] [/usr/local/cpanel/scripts/find_and_fix_rpm_issues] Updating / installing...
[2024-01-09 16:19:06 +0000] [/usr/local/cpanel/scripts/find_and_fix_rpm_issues] rpm_is_working-1.0-0 ########################################
[2024-01-09 16:19:08 +0000] 25% completeHowever, since the only true way to disable the update is to set that file to "manual" there is no automated work behind the scenes like what could take place in the WHM interface, such as automatically removing the cron, so the following cron will still run:
56 23 * * * (/usr/local/cpanel/scripts/fix-cpanel-perl; /usr/local/cpanel/scripts/upcp --cron > /dev/null)
and then give the output that quietFinn provided.
Does that help to clear things up?
0
Please sign in to leave a comment.
Comments
12 comments