09-20-2013 12:27 AM
the topic says it all:
I have one GTW and one DPS both installed on RHEL 5.9.
DPS is starting fine while GTW is stuck on mercuryAS with LAUNCHED status. Logs say that port checker found that 1098 is used. Well, it is used, but by mercuryAS. Seems like component order is messed out.
It'll be a problem with attaching log files as botyh servers run outside my LAN and I have to connect via multiple VPNs so it's not possible to take out any file from there...
09-23-2013 03:12 AM
Simple restart not help. On second BSM Gateway server (it will be gtw cluster) behaviour is exactly the same. Port 1098 in use by MercuryAS. Any other ideas?
Serwer was installed with all required patches. First hpbsmd run was after all installations.
09-23-2013 03:18 AM
try running, while the GW is stopped completely:
to see if there is any other process taking port 1098 before the GW is started.
09-23-2013 04:32 AM
Before GTW stop:
# ./check_free_port.sh 1098 New check free ports Try #1: Port '1098' in use Exit code: 1
After GTW stop:
# ./check_free_port.sh 1098 New check free ports Port '1098' is free. Exit code: 0
After hpbsmd restart port is still "in use":
# netstat -anp | grep 1098 tcp 0 0 0.0.0.0:1098 0.0.0.0:* LISTEN 26684/MercuryAS
... and Gateway is not working, mercuryAS has LAUNCHED status.
09-23-2013 06:07 AM
it seems the message broker can't connect to port 2507, this needs to be fixed first:
2013-09-23 11:22:29,542 [ReconnectThread-Monitor-[CLUSTER]] (RetryWork.java:70) WARN - Work Thread failed retry in 5000ms. [name=ReconnectThread-Monitor-[CLUSTER];attempt=3;
2013-09-23 11:22:30,052 [UCMDB Notification Services Reregister Thread] (BsmSDKLoggerImpl.java:96) ERROR - customer id: 1 , console ==> Failed to register listener due to following failure :java.net.ConnectException: Connection refused
com.hp.ucmdb.api.CommunicationException: java.net.ConnectException: Connection refused
2013-09-23 11:41:23,268 [ClientListener sap-lnx-069_mercury_as_tracker:LOCAL$CONNECTION$ (sap-lnx-069:2507)] (ConnectionTracker.java:99) WARN - monitor is trying to reconnect. [type=LOCAL;connectId=sap-lnx-069_mercury_as_track
I see many more errors in the TOPAZ_ALL file. Is this a new installation, is it a virtual system?
09-23-2013 06:58 AM
sap-lnx-068 is the second gateway server (described in first post). Localhost, second gateway and dps is listening on port 2507. After restart I don't see new errors with port 2507.
This is fresh installation on fresh OS. Environment is virtual on Hyper-V.
After BSM 9.20 installation there was run ovii-postinstall.sh. After this there were installed updates 816, 820 and 831. The next step was config-server-wizard.sh and connection to DB.
In LAB environment we have once exactly the same problem, when updates were installed after run bsm 9.20. The above described installation steps helped. But not this time.
09-24-2013 12:46 AM
could you tell a bit more about your deployment.
Waht database are you using and which (exact) version?
What is the BSM deployment size (small, medium, large) ?
What are CPU/memory sizes on the Linux machines?
Is there a firewall in between GW & DPS server?
Please upload new logs.
09-24-2013 03:59 AM
DB: MS SQL Server 2008 R2 Ent. SP1
BSM deployment size after install: small
CPU GTW: 6x; RAM: 8GB
CPU DPS: 8x; RAM: 24GB
There is no firewall between GTW and DPS. This environment is prepared for production system, but BSM is not yet scaled.
GTW can't connect to port 2507 DPS if DPS is disabled - these errors we can ignore.
BSM was working properly after installation 9.20 without patches and updates to 9.22.
New logs are attached. Last restart of this GTW was yesterday, about 15:38.
09-24-2013 06:28 AM
There are two things you need to check , in case they are not causing the issue then it's time to open a support case.
1. In time in sync between all servers, that includes the DB server too?
2. isn't there any other applications using a port (1098 seems to be taken) perhaps a (separate) OM agent installation ?
09-24-2013 01:07 PM
the time thing - we have to check (probably tomorrow).
As for port 1098 being taken - that is not the issue. There's nothing else installed there. The port is being used by mercuryAS itself (checked with netstat). It's like mercuryAS is starting and then the check is initiated.