Using the Event Monitoring Service (June 2003)

Troubleshooting
Logging and Tracing
Appendix B88
• If 2) succeeds, the problem is most likely with the specific resource
"/system/numUsers", since the query of the other resource of the
same EMS monitor works fine.
Using resls -s to Check the Status of an EMS Resource
From EMS A.03.20 onwards, you can view the current value of the
resource instance by using the new "-s" option with resls, e.g.
# resls -s /vg/vgomni/pv_summary
COntacting Registrar on grcdg236
NAME: /vg/vgomni/pv_summary
DESCRIPTION: Physical Volume and PVLinks Summary
(/vg/<vgName>/pvsummary)
[...]
There are 4 valid states reported for /vg/vgomni/pv_summary:
State Value State Name
------------ -----------
1 UP
2 PVG_UP
3 SUSPECT
4 DOWN
EMS Persistence Files
The EMS persistence files are located
under/etc/opt/resmon/persistence. They contain the monitoring
requests that are persistent, that is reconfigured by p_client when the
monitor dies or after a system reboot. For example, all monitor requests
configured in SAM, through the EMS GUI or the EMS CLI, are
persistent and are stored in the m.xxxxxxx file under
/etc/opt/resmon/persistence.
The EMS resource monitoring requests for MC/ServiceGuard are defined
as package resource dependencies. These monitoring requests are not
persistent requests, that is, if the monitor were to die, the p_client will
not restart the monitor and reissue the monitoring requests. This is left
to the cluster daemon (cmcld) to manage. MC/ServiceGuard has
therefore its own persistence database.