09-06-2019 01:18 AM
Hello
I am after upgrading to 3.1.2 for most of my appliances and recently I had to reboot few of them.
Now this reboot is taking really long time ca.1 h or so...
It is sitting for quite a long time on this
How it is with your NBU appliances?? Proir to this release reboot did last ca 15m now it is pain in the back as I have to account for longer down time... which is not really welcome in data center, where these appliances are needed...
09-12-2019 12:29 AM
Hello
So no one is rebooting appliances at all? Don't you know how long it takes in your env? This is not sensitive information ...
In my opinion this "Reached target Shutdown" is misleading - especially when issue reboot command...
09-12-2019 11:42 AM - edited 09-12-2019 11:45 AM
One of my appliances rebooted in 15 minutes and 12 seconds, another rebooted in 14 minutes and 37 seconds. Those were the most recent reboots of my 5240's.
However, those reboots weren't related to any upgrades or anything. I do recall the reboot after upgrading to 8.1.1 taking quite some time.
Once you're in elevated mode, try typing 'systemd-analyze blame'. Should break down what services caused your reboot to take so long.
09-13-2019 11:21 AM
Hey!
First things first - thank you for sharing your reboot timing. If my memory servers me correctly 5240 are newer than 5230... Mine 5230's do reboot starting from 40 to 60 mins... this is for 3.1.2. earlier on 3.0 it was on the similar timings as yours 5240's...
I will check this command and will update here.
09-13-2019 01:07 PM
Oddly enough, it's a RHEL bug and not something Veritas added. Go figure. =)
https://bugzilla.redhat.com/show_bug.cgi?id=1298355
"The issue occurs whether there is a tmpfs mounted or not. Having a tmpfs mounted only exacerbates the problem because the system runs out of physical memory earlier and consistently when the swap is turned off, for example on a Virtual Machine that has a small amount of "physical" memory allocated. The issue occurs because during the shutdown/reboot process systemd calls swapoff that attempts to remove every swap device. If there isn't sufficient physical memory to hold what was being held in the swap area, then the system hangs indefinitely. In previous RedHat versions (up to 6) swapoff was never called during shutdown/reboot. I wonder what has changed in RHEL 7 that now requires a swapoff. Couldn't we just do without and solve the problem? After all it should not be necessary to "remove" memory to shutdown a system."
Looks like RHEL has released a fix (https://access.redhat.com/errata/RHBA-2017:2297) but unfortunately unless you want to break supportability we have to wait on Veritas to release an updated image; cross your fingers the November release of v3.2 includes the fix.
09-14-2019 10:01 AM
Thank you for sharing this info!! Appreciated.
So let's hope this will be fixed in 3.2.
11-15-2019 02:40 AM
Got a few Applainces
5340's can take upwards off 40 mins
5240's about 20 mins
I do find that they hng about 50% of the time on a reboot