cancel
Showing results for 
Search instead for 
Did you mean: 

How long does reboot last for your NBU 5230's

quebek
Moderator
Moderator
   VIP    Certified

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 thisreboot.png

 

 

 

 

 

 

 

 

 

 

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...

6 REPLIES 6

quebek
Moderator
Moderator
   VIP    Certified

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...

Krutons
Moderator
Moderator
   VIP   

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.

quebek
Moderator
Moderator
   VIP    Certified

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.

jnardello
Moderator
Moderator
   VIP    Certified

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.

quebek
Moderator
Moderator
   VIP    Certified

Thank you for sharing this info!! Appreciated. 

So let's hope this will be fixed in 3.2.

lukestannard
Level 2

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