cancel
Showing results for 
Search instead for 
Did you mean: 

OpsCenter 7.6.0.1 on Linux not starting (ops_atd)

tsimerson
Level 3
Partner Accredited

Doing some testing with NBU 7.6.0.1 and running into an issue with OpsCenter.  I've got a CentOS 6.5 sysetm that I've installed OpsCenter onto.  The installation reported as successful.  But, the new ops_atd will not start.  It seems to be looking for some libraries in the /opt/VRTSat/plugins directory.  Of course, there is no /opt/VRTSat/plugins directory since the "regular" version of VRTSat is not installed any longer.

Started by going into the /opt/SYMCOpsCenterServer/authbroker/bin directory to look at the vxatd.log file.  Nothing other than stating "At Init successful".  Used the command "./vssat setloglevel -l 4".  This generated some additional information:

(7050|140461559543584) At Init successful.
(7050|140461559543584) Initialized local configuration successfully
*** Broker Not In FIPS mode ***
Jan 29 11:21:00 2014:50826,18,0,7050,3244062496,debug,AT,8: (7050|140461559543584) Warning! Unable to Load Unified Logging settings.
Jan 29 11:21:00 2014:50826,18,0,7050,3244062496,debug,AT,8: (7050|140461559543584) Check if Unified Logging configuration exists for ProductID 50826 and OriginatorID 18.
Jan 29 11:21:00 2014:50826,18,0,7050,3244062496,debug,AT,8: (7050|140461559543584) Actual Logging file name doesnt match with bootstrap log file name
Jan 29 11:21:00 2014:50826,18,0,7050,3244062496,debug,AT,8: (7050|140461559543584) Finishing boot strap logging
Jan 29 11:21:00 2014:50826,18,0,7050,3244062496,debug,AT,8: (7050|140461559543584) Detailed broker log would be available at /var/VRTSat/log/vxatd.log
 

Note the reference to /var/VRTSat/log/vxatd.log.  I created that file, ran './vssat setbrokerlog -l 4" and attempted to start the ops_atd again (by running /opt/SYMCOpsCenterServer/bin/startat".  This created the following information in /var/VRTSat/log/vxatd.log:

Jan 29 11:32:03 2014:50826,18,0,7262,2487359264,debug,AT,8: ACE_DLL_Manager_Ex::open: Invalid handle: /opt/VRTSat/plugins/libauthldap.so: cannot open shared object file: No such file or directory
Jan 29 11:32:03 2014:50826,18,0,7262,2487359264,debug,AT,8: ACE_DLL_Manager::open_dll: Could not open dll.
Jan 29 11:32:03 2014:50826,18,0,7262,2487359264,debug,AT,8: (7262|140306184017696) Unable to load dll /opt/VRTSat/plugins/libauthldap.so in pluggins.cpp(100)
Jan 29 11:32:03 2014:50826,18,0,7262,2487359264,debug,AT,3: (7262|140306184017696) DoNotLoad=true for library /opt/VRTSat/plugins/libauthsecureid.so. Plugin library wont be loaded.
Jan 29 11:32:03 2014:50826,18,0,7262,2487359264,debug,AT,8: ACE_DLL_Manager_Ex::open: Invalid handle: /opt/VRTSat/plugins/libauthlocalhost_t.so: cannot open shared object file: No such file or directory
Jan 29 11:32:03 2014:50826,18,0,7262,2487359264,debug,AT,8: ACE_DLL_Manager::open_dll: Could not open dll.
Jan 29 11:32:03 2014:50826,18,0,7262,2487359264,debug,AT,8: (7262|140306184017696) Unable to load dll /opt/VRTSat/plugins/libauthlocalhost_t.so in pluggins.cpp(100)
Jan 29 11:32:03 2014:50826,18,0,7262,2487359264,debug,AT,8: (7262|140306184017696) Error loading pluggins in server.cpp(792) program will exit
Jan 29 11:32:03 2014:50826,18,0,7262,2487359264,debug,AT,8: (7262|140306184017696) Broker Raised Exception!
Jan 29 11:32:03 2014:50826,18,0,7262,2487359264,debug,AT,8: (7262|140306184017696) Error: 24631 - Unable to load pluggins in server.cpp(793)
Jan 29 11:32:03 2014:50826,18,0,7262,2487359264,debug,AT,3: (7262|140306184017696) retVal: 24631
Jan 29 11:32:03 2014:50826,18,0,7262,2487359264,debug,AT,8: (7262|140306184017696) Broker shutdown complete
 

Note all the invalid handle messages trying to start plugins in /opt/VRTSat.

Curious if anyone is seeing similar issues on a RedHat system?

I know that CentOS is not officially supported for OpsCenter but if it looks/smells/runs like RedHat then it should be close enough to do some playing with.

1 ACCEPTED SOLUTION

Accepted Solutions

Logicalis_PAF
Level 3
Partner

I had the same issue on RedHat 6.5.  I installed ksh (yum install ksh) and restarted the server and all came up.  Apparently, some of the authentication setup scripts require ksh, which is why the ops_atd daemon wasn't setting up properly.

 

PAF

View solution in original post

6 REPLIES 6

Ice_Dog_M
Level 2

Same issue here.

Fresh installation of OpsCenter 7.6.0.1 with all defaults, cannot log in. Tried both Red Hat and SuSE - same results.

Logicalis_PAF
Level 3
Partner

I had the same issue on RedHat 6.5.  I installed ksh (yum install ksh) and restarted the server and all came up.  Apparently, some of the authentication setup scripts require ksh, which is why the ops_atd daemon wasn't setting up properly.

 

PAF

Ice_Dog_M
Level 2

That helped, thanks!

tsimerson
Level 3
Partner Accredited

Logicalis_PAF, great catch.  I had to re-install OpsCenter on my CentOS 6.5 server after installing ksh.  That did the trick.

Logicalis_PAF
Level 3
Partner

Thats good news.  Unfortunately, mine was an upgrade of 7.5.0.5 OCA, so I needed to get it working.  Frustratingly enough, the server services were running fine, we just couldn't log in to see all the wonderful new features in 7.6.0.1.  I'm glad that I could share a fix for the community that has helped me so much in the past.

Cheers.

PAF

idealo
Level 2

thanks!

a nother dependency is glibc.i686 by the way.