Is this a metal server? There was a problem with one of the kernel updates for RH-based distros that prevented metal servers from rebooting after the update, but I think that’s been fixed.
I don’t know of any updates affecting the ability to log in to Virtualmin. Can you log in to the shell?
“We can inform you that it is possible that a query or process froze or became stuck during the upgrade process which caused the high RAM usage and possible caused the upgrade to fail.”
My update from 3.10.0-1127.13.1.el7 to 3.10.0-1127.19.1.el7 was uneventful, but I have Kernelcare installed and rarely do the kernel updates manually (nor reboot the server afterwards, or course) unless the kernel update is related to a zero-day security bug. Igor is usually pretty quick about patching things anyway, so it has to be a pretty extreme situation before I update the kernel manually.
I also haven’t read about any problems related to that specific upgrade.
In any event, I think it’s unlikely that Virtualmin would have anything to do with a problem that occurred during a CentOS kernel upgrade because I’m almost certain that all it does is run yum.
You can enable syslog kernel logging in /etc/rsyslog.conf by adding
kern.* /var/log/kernel.log
( kern.* TAB TAB TAB /var/log/kernel.log )
In the meantime, you can try poking around in
/var/log/dmesg (and /var/log/dmesg.old if it exists)
/var/log/messages
/var/log/boot.log (and older saved boot logs)
/var/log/yum.log (and older logs)
but it’s a crapshoot whether you’ll find anything useful.
Thanks Richard, For the detailed explanation, and the advise in using Kernelcare (I’ll research it later on). (Apologies in going crazy with messages last night, but I just needed to post what I was doing…)
I am not sure if the logs are still intact, when you revert to previous kernel. But I’ll check the logs anyway. I do KNOW seeing an error w.r.t. not enough memory.
I wonder by stacking up updates, and not doing within a certain timeframe, the os gets confused. I doubt this will be in the case of CentOS
Anyway, I running a version behind, and have another server, which I did not do, which also have to be updated.
Not sure how to proceed now with the upgrade:
Do I increase my memory on the VPS
Do each of upgrades (eg. I think there is 33 components to be upgraded) one by one, Virtualmin allows you to do it.
To my knowledge, all Virtualmin does is run yum. If there is a problem related to a kernel update, it’s almost certainly at the OS level, not the panel level.
I suppose there also could be some filesystem corruption. Maybe a FSCK is in order?
I have no idea whether you should increase the RAM because I have no idea how much RAM you have.
Does your host provide a way to make and restore snapshots? That may be the safest route to go at this point. You may also want to peruse this thread. Seems the OP had the same problem and it was an interruption in the kernel update.
As for Kernelcare, it’s not officially supported in Virtualmin (or at least wasn’t the last time I checked), but all that means is that you’re still presented with the kernel updates until Kernelcare patches them. I generally research the update and leave it be until Igor patches it if it’s a bugfix that doesn’t affect the particular server’s mission. If it’s a zero-day exploit or something horrid like that, then I’ll update it manually.
Personally, I think Kernelcare is well worth the low cost if for no reason other than the dramatic reduction in reboots.
I’m dealing with this (again) on an AWS instance, I have restore to a previous snapshot, but this is the 2nd time I’ve had to deal with this in the last few months.
I do believe it’s several factors that are causing this, not sure if Webmin has anything to do with it or not at this point. AWS’s documentation is a bit dated, so I’m going to have to take some time and sort his out. Last time was an easy fix, this time around is a touch harder, not sure exactly why just yet. Should known soon.