I´m having problem deploying a Combo VM4 9.3.1 Nitrsolution to my ESX 5.1
The history is as follows:
- I had a Nitro 9.3.1 succesfully deployed in my Lab
- One day I tried to log in but it was impossible, through ssh ok
- After trying serveral things I decied to reboot
- The consecuence is that the ESM put itself in rebuilding
- I let the rebuilding state during 2 days.
- Finally I decided to deleted and deploy a new one ( it was impossible to stop de server only reboot)
- Once the ESX was empty (datastore) of any Nitro VM I tried to deploy the new one
- !! Once the new VM started, the ESM is in rebuilding again!!!!
Thanks in advance.
Not the answer you probably want, but best recommendation is to contact Support. You will most likely have to manually rebuild a few tables. There are times where your database will get stuck in a rebuild loop, in those cases the affected tables need to be moved to a temp location and instruct the system to rebuild those tables. The database rebuild usually occurs if you reboot the system incorrectly (or from a system fault eg. kernel panic), or right after an upgrade.
THanks a lot dcobes for your reply, however I can´t understand how if I try to deploy a new Nitro from scratch happens the same....I´m think it is probably something in the ESX environment, not enough space for example...
you can do guide :
SSH to ESM:
-step1: service cpservice stop
Then once you're back at a prompt, confirm it has stopped by typing:
- step 2 : ps auxf | grep cpservice
You should only see your grep command returned. Then type:
- step 3: cd /usr/local/ess/data/
We will make a few backups of some database files before moving them:
-step 4 :
cp ngcp.cf* old_files
We will now start cpservice back up and a rebuild will take place if necessary:
- step 5 : service cpservice start
- if need can reboot ESM
Then reboot acess ESM , it rebuid 5' , you wait, finish 5' you can login .
THanks for your support Lichnt
However I can´t even log into the vm by ssh.....something really strange. Fortunatetly McAffe has send me a new fresh copy to start over. Let´s see if I can have further support to solve this mistery 😉
I´ll keep yuou post it with my findings..
Sounds like a new emerging bug: Bug 37936
Ver 9.4.3 Build 20141118
One or more of the following we identified symptoms:
When we've gotten to the point whereas, until there a fix, per McAfee Engineering, when we encounter this we have to kill cpservice
Open HTOP and note the PID of cpservice
- kill -9 %PID%
By the way, keep an eye on the error log: (This will give you more relevant information than messages.