Known Problems and Workarounds

The following are known problems and suggested workarounds with the EMS:

JAGab77527: EMS client may fail to connect to the registrar

What is the problem? An EMS client may fail to connect to the EMS registrar. If this occurs, you may see a message in /etc/opt/resmon/log/client.log like this one:

-------------------Start Event--------------------Event 11 occurred at Tue Oct 19 15:53:24.025936 1999Process ID: 1062 (/etc/opt/resmon/lbin/startmon_client)   
Log Level: Errorrm_client_connect: Failed to connect to hprdstts.rose.hp.com,
IP address 15.8.135.200, Port 1712: Invalid argument-------------------End Event-----------------------------------------Start Event--------------------User event occurred at Tue Oct 19 15:53:24.036390 1999Process ID: 1062 (/etc/opt/resmon/lbin/startmon_client)   
Log Level: Errorclient connect failed: An error occurred while trying to connect to a remote system: Invalid argument-------------------End Event----------------------

What is the workaround? Perform the following:

Ensure the inetd is listening on port 1712. To do this, you can execute the following command. The desired output line is listed here:
netstat -an | grep 1712 tcp 0 0 *.1712 *.* LISTEN
If inetd is not listening on port 1712, be sure the following entry is in /etc/inetd.conf:
registrar stream tcp nowait root \ /etc/opt/resmon/lbin/registrar \ /etc/opt/resmon/lbin/registrar
Be sure the following line is in the /etc/services file:
registrar 1712/tcp # resource monitor service
Then enter inetd -c to reconfigure inetd.
Retry running the client that failed.

JAGab77759: ServiceGuard package service status is reported incorrectly

What is the problem? /cluster/package/service_status/ <package_name>/<service_name> may be incorrectly reported. When monitoring the service status of a package running locally and the ServiceGuard coordinator node is not the same node, service status may be incorrectly reported as UNKNOWN or DOWN when it is really UP. cmviewcl shows the service is UP.

What is the workaround? Configure package and service status monitoring on each node in the cluster. Then correlate the data reported on each node. The coordinator node will report status of UNKNOWN for the remote service. UNKNOWN state means that the service is up and running somewhere in the cluster.

JAGad03512: Events could be lost when EMS and HA Monitors are upgraded

What is the problem? When updating the Event Monitoring Services, notifications for monitors with active persistent requests can be lost. This can happen for up to two minutes from the update. This cannot happen with a new install, only an update.

What is the workaround? Before updating, find out which monitors are active. Enter the ps -ef |grep resmon command. In the table below, check any of the monitors listed in the output.

Now, update the software.

Immediately after the update, activate the monitor to re-register all of its active persistent requests. Use the commands in the table below.

Table 1-4 Title not available (JAGad03512: Events could be lost when EMS and HA Monitors are upgraded)

monitor name listed in output	command to re-register the monitor's active persistent requests
clustermond	resls /cluster/localNode/status
diskmond	resls /vg
fsmond	resls /system/filesystem/availMb
lanmond	resls /net/interfaces/lan/status
mibmond	resls /system/numUsers
pkgmond	resls /cluster/package/package_status
rdbmsmond	resls /rdbms
svcmond	resls /cluster/package/service_status

Name services requirement

What is the problem? EMS may not function if you are running name services that do not use /etc/services, such as NIS, DNS, or X.500.

The port number for the EMS registrar is listed in /etc/services. If you are running a different name lookup service, for example NIS, and it is not configured to use /etc/services as part of the name lookup process, then EMS monitors will not be able to find the registrar program and will not function.

What is the workaround? You can do either of the following:

On the name server, add the registrar services line to the appropriate services file for the name lookup service you are running. The line should have the same port number as the line in /etc/services, for example:
registrar 1712/tcp # resource monitor service
If inetd is not listening on port 1712, be sure the following entry is in /etc/inetd.conf:
registrar stream tcp nowait root \ /etc/opt/resmon/lbin/registrar \ /etc/opt/resmon/lbin/registrar
After you have confirmed both registrar requirements, reconfigure inetd by executing:
inetd -c
Add the /etc/services file to the lookup path your name lookup service uses. For example, modify the nsswitch.conf file to refer to /etc/services if you are running NIS.

Known Problems and Workarounds

Technical documentation

» Table of Contents

» Index

JAGab77527: EMS client may fail to connect to the registrar

JAGab77759: ServiceGuard package service status is reported incorrectly

JAGad03512: Events could be lost when EMS and HA Monitors are upgraded

Name services requirement