WHM Service Restarts - Closing and Opening Browser Re-initiates Restart
Just noticed this today, not sure if others have or not. Its not really a bug, error, or issue so much as it is risky forgetfulness. This is a public service announcement (PSA) regarding saved browser tabs and WHM service restarts courtesy of, me.
So yesterday near the end of the shift I had to do a MySQL restart. Instead of logging into SSH like I normally do, I hopped in WHM to do this in the restart services tab. Works great, its awesome :) Anyways, I had left the "MySQL restarted successfully" screen/message up in the tab in WHM, and as the day completed, finished work in other tabs, then closed the browser.
Today upon starting my browser all the previous tabs are reloaded and I am greeted by our ecom homepage, with uber fatal query and MySQL connect errors all over the place. My coworker immediately went into panic mode as his admin session and consequent pre-save data was wiped off the face of the earth. Sales freaked out, who knows what customers got booted (or what orders lost). Ahh what the heck happened!? Looking for errors, crashed DB, load, .... nothing. And then....
Omg. Facepalm. Un-lol. When the browser opened, it restarted MySQL again. I restarted MySQL without even knowing it.
Yes I deserved the heat I got from the team/customers because I should have known better. But you may not realize, so I'm letting you know: don't ever leave the "MySQL restarted successfully" (or other restart services) tab(s) open in your browser upon closing it, else as we are all now aware of, it may restart the service or server itself when you reopen the browser. This is assuming that your browser reopens sessions and your WHM cpsess ID is still valid of course. Regardless, be sure to always navigate away from these tabs when you're done working with a service or server restart.
Sure it would be cool to build a mechanism into WHM that prevents this, something like the success screen is a different URi than the actual restart initiation screen, but for now awareness is the clear fix.
-
Hello :) You could submit a feature request for an additional confirmation button upon refreshing the page via: Submit A Feature Request Thank you. 0 -
An exciting story to be sure. Sounds to me like you, right clicked / open in a new window, the item, SQL Server (MySQL), from the left menu in WHM, this opened that single page in a new window, broke out of the frame it's supposed to be in. Not the best way to do things I don't think. I don't get this though: Today upon starting my browser all the previous tabs are reloaded and I am greeted by our ecom homepage, with uber fatal query and MySQL connect errors all over the place. My coworker immediately went into panic mode as his admin session and consequent pre-save data was wiped off the face of the earth. Sales freaked out, who knows what customers got booted (or what orders lost).
Why another restart caused so many issues and data got lost. I don't see this sort of Feature Request getting much attention, TBH.0 -
An exciting story to be sure. Sounds to me like you, right clicked / open in a new window, the item, SQL Server (MySQL), from the left menu in WHM, this opened that single page in a new window, broke out of the frame it's supposed to be in. Not the best way to do things I don't think.
No it was the original frame, try it out.... This isnt really a feature request, its more of a bug IMO, and a quite obvious one at that. Chrome is quite good at preserving state/scope when you re-open windows/tabs. Make sure its with Chrome.Why another restart caused so many issues and data got lost.
Why is an extremely simple concept. Web editing is WYSIWYG based. Mitigating orders is web based. Tons more is web based. When a page is loaded and youre working away, then serv goes out behind the scene, your window isnt necessarily loaded and therefore a save/post/whatever fails. Same concept if your internet goes down and you try a POST. Granted we since implemented auto-drafts (localstore) in editor, it still caused issues at that moment of 10 or so content editors working at the same time. Then some of their CSRF tokens were reset which caused some of them to re-log in (i know this isnt a big deal but tell a marketing dude that, then show them their POST was lost, see how they react to redoing 10 mins of work haha). Also why, its because when the server restarts when many hundreds of customers are using the site, things go wrong on the front side too. Sure PHP sessions are pretty resiliant, but there is more than that. Ie even Redis has a window of performance where persistence write to disk VS time between writes can cause slight loss (ie ie when you use as session store). So those people who may have been mid conversion may have seen some strange stuff go on, cart lost, gateway token mismatch, blah all kinds of little stuff. Now, imagine youre working a giant shared server and Windows 10 decides to force restart, or youre done for the day, ctrl-shift-T, whatever. You reopen your browser which contained the WHM tab after restart before restart, yesterday, whatever -- then boom double restart. You just mucked hundreds of clients for the duration of a server restart for no other reason than the state of the tab was reloaded.0 -
This issue is handled through internal case CPANEL-1726. There's currently no specific time frame on the implementation of this internal case, but feel free to monitor the change log at: Change Logs - Documentation - cPanel Documentation Thank you. 0
Please sign in to leave a comment.
Comments
5 comments