How to trigger the EMS event manually

[Genesis_1]

When I finished repairing the failure, how can I trigger the EMS manually to determine whether the same EMS event will reoccur. I don't want to wait the EMS event for a long time.
What can I do, thanks.

[Raghuarch]

resls is a client application that can verify that the communication between client, registrar and a monitor works. If you are dealing with a problem that seems to be related to some sort of communication issue between EMS processes, use resls to verify whether all monitors are affected or only some.
For example:
If you type the following command at the HP-UX prompt, 1)
# resls /system/numUsers
the above command fails to check if any request is available for a required resource. The resources managed by the mibmond can be listed with resls /system command. You should also verify if another resource of the same monitor fails, for example, mibmond.

Another mibmond resource: 2)

# resls /system/jobQueue1Min

A diskmond resource: 3)

# resls /vg/vg00/pv_summary

If 2) fails but 3) succeeds, it is likely that the problem is with mibmond or with the SNMP setup, where the mibmond monitor gets its data.

If 2) and 3) fail, it is likely that the problem is with EMS framework, e.g. the communication of the resls(1m) client with the registrar fails.

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

For more information:
http://docs.hp.com/en/B7609-90049/apb.html

[Fabio Ettore]

Hi,

send_test_event -v

could help.
man send_test_event for more details.

Best regards,
Fabio

[tkc]

if you are referring to a disk replacement, you can test the following command :

#send_test_event -v disk_em

[Genesis_1]

Thanks, everybody. The send_test_event is only a simple test to EMS notice, not to really trigger EMS to examine if the failure is still existing.

[Fabio Ettore]

Hi Genesis,

AFAIK it's not possible to simulate EMS in the same way as the failure. The only known method is by send_test_event to test EMS flow.

Also there are .cfg files into /var/stm/config/tools/monitor to know events that will be generated.

Best regards,
Fabio

[Stefan Stechemesser]

Hi Genesis,

an "Event" is only something that happens regardless of the existence of EMS.
EMS is only the one who notifies you about this event.
For example if a CPU cache error happens, then an interupt "LPMC, low priority machine check" would be generated and the lpmc_event monitor (a daemon) would recognize this and start an action based on some config files (f.e. only if several cache errors happen within a timeframe, a notification would be sent to you).

EMS is a framwork of many of such monitors (for every hardware component one, you see the running processes with "ps -ef | grep stm") and also the emsagent that finally send out the message (by SNMP, e-mail, ISEE, TCP, logfile etc.).

The question is now: What kind of "event" was your problem ? Of course if you want to actively check if a CPU is repaired after a replacement, then EMS is not the correct tool (if you don't want to wait).
You would have to actively test the CPU.
The same would be true for disks, I/O links etc. and various tools exist to do these tests.

Most can be done with the offline diagnostics CD (can be downloaded here:
http://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=PA0803 )

but in some cases, you can use the online diagnostics (cstm, mstm, xstm) "excerciser" to do such tests.

In addition to event handling, some monitors indeed do active testing of components (called "polling") for example to check if a disk is still online by doing a small SCSI request to it once a day.

But the majority of EMS messages are really only events that are not forced or polled by EMS but are reported just when they accidentaly happen.

best regards

Stefan

[Genesis_1]

Thank you, everybody.