BMC Atrium Discovery Community Forum

forgot password?
   
 
Error after 8.1.1 upgrade
 
Petrus Johansson
Posted: 01 March 2010 02:30 PM   [ Ignore ]  
RankRankRankRank
Guru
Total Posts:  318
Joined:  2009-10-29

After upgrading to 8.1.1, the startup fails after reboot.
Immediately after rebooting the appliance, the UI is inaccessable with message “The appliance has been shut down”

On the command line, the following output:

sudo /sbin/service tideway status
Free Space Monitor (pid 4391) is running…
Security is stopped
Options is stopped
Discovery is stopped
Model is stopped
SQL Provider is stopped
Reasoning is stopped
NetFlow capture is not enabled
Reports is stopped
Application Server is stopped

And the following error in tw_svc_security.out:

[tideway@localhost log]$ cat tw_svc_security.out
Mon Mar  1 14:21:34 2010 : tw_svc_security started.
omniORB: (0) 2010-03-01 14:21:34.956168: Failed to bind to address :: port 25000. Address in use?
omniORB: (0) 2010-03-01 14:21:34.956214: Error: Unable to create an endpoint of this description: giop:tcp::25000
Traceback (most recent call last):
  File "./main.py", line 66, in <module>
  File "./main.py", line 54, in main
  File "./servants.py", line 394, in init
  File "/usr/tideway/lib/python2.6/site-packages/omniORB/CORBA.py", line 576, in resolve_initial_references
    return _omnipy.orb_func.resolve_initial_references(self, identifier)
omniORB.CORBA.INITIALIZE: CORBA.INITIALIZE(omniORB.INITIALIZE_TransportError, CORBA.COMPLETED_NO)
Mon Mar  1 14:21:35 2010 : Watchdog : Service failed in 0.3 seconds (signal 0). Exiting.
[tideway@localhost log]$ 

Anyone seen this before?

 Signature 

Monitor what matters, model what is monitored

Profile
 
 
Mark Wilkinson
Posted: 01 March 2010 03:03 PM   [ Ignore ]   [ # 1 ]  
BMC ADDM Staff
RankRankRankRank
Administrator
Total Posts:  140
Joined:  2008-02-20

that looks like the previous free space monitor failed to shutdown properly. You could try one of; a service tideway stop, or looking for and killing the python process, or simply rebooting (which will almost certainly cure it, albeit it a heavy handed method :-) )
If you have the logs & out files going back to the last successful start before the upgrade and a few minutes, then it would be useful to raise a case and attach the logs so we can look for clues.

Profile
 
 
Petrus Johansson
Posted: 01 March 2010 03:08 PM   [ Ignore ]   [ # 2 ]  
RankRankRankRank
Guru
Total Posts:  318
Joined:  2009-10-29

Thanks Mark, and SHIT! :)

2-3 reboots and py-kills and I got a bit further :)
But now I got a different issue… :(

[tideway@localhost ~]$ sudo /sbin/service tideway start
Starting Tideway application services
    Starting Free Space Monitor service:                   [  OK  ]
    Rebuilding CSS extensions:                             [  OK  ]
    Starting Security service:                             [  OK  ]
    Starting Options service:                              [  OK  ]
    Starting Discovery service:                            [  OK  ]
    Starting Model service:                                [FAILED]
Mon Mar  1 15:06:29 2010 : tw_svc_model started.
Sorry, the data store was previously run at Mon Mar  1 15:25:15 2010 (UTC). The time now is Mon Mar  1 15:06:29 2010 (UTC). The data store does not support time going backwards.
Mon Mar  1 15:06:29 2010 : Watchdog : Service failed in 0.6 seconds (signal 0). Exiting.

The Tideway service '40model' failed to start. Check logs. 
 Signature 

Monitor what matters, model what is monitored

Profile
 
 
Mark Wilkinson
Posted: 01 March 2010 03:15 PM   [ Ignore ]   [ # 3 ]  
BMC ADDM Staff
RankRankRankRank
Administrator
Total Posts:  140
Joined:  2008-02-20

Interesting :-) That’s as simple as it says - last time the model was running, the time was further into the future than it is now. That implies that there’s been a clock change - one possibility is that this is a VM, and isn’t running VMware tools / ntpd to keep the clock right? It can’t be a timezone change, because it’s using UTC throughout for that. I can’t explain why your system clock has gone backwards, but in your case I can see that waiting just under 20 minutes will clear that hurdle - I’d spend the intervening time investigating why the clock has gone backwards.

Profile
 
 
Petrus Johansson
Posted: 01 March 2010 03:31 PM   [ Ignore ]   [ # 4 ]  
RankRankRankRank
Guru
Total Posts:  318
Joined:  2009-10-29

It is indeed the VA.
Yes the error message was pretty clear :) For some reason ntp did not start during the appliance startup after reboot. I recompiled VMware Tools after the reboot (maybe should have done that prior to reboot?)
However, re-configured NTP and timezone on the appliance and right now waiting for the reboot to finnish…

Update:
...and that cleared the issue.
I will definately check with our VMware administrator to find out why the clock screw

Thanks for your help Mark!

[ Edited: 01 March 2010 03:36 PM by Petrus Johansson]
 Signature 

Monitor what matters, model what is monitored

Profile
 
 
Mike Brandenburg
Posted: 12 August 2010 10:19 AM   [ Ignore ]   [ # 5 ]  
Rank
Newbie
Total Posts:  6
Joined:  2010-02-23

Did you check this with your VMWare Admin ?
What was the result ?

Thank you

Profile
 
 
   
 
 
‹‹ Cannot telnet to any AIX system      Appliance wouldn’t start after space upgrade ››