The way I did it was to write a daemon application which periodically generates
an trap which sent to the Netview boxes and sets a variable relating to the
individual Netview system (I run a production and play, sorry development.
system)
My Netview rule includes an action for this trap which executes a second
program which talks to my daemon causing it to reset the variable that the
original action set.
When the daemon is ready to repeat the trap generation it check the variable,
if it is still set then it knows that the previous trap did not get processed
correctly by Netview and alerts me via an SMS message.
In addition to this the daemon periodically executes an ovstatus and greps for
"NOT" as in "NOT_RUNNING" and alerts me to this in the same way you are already
doing.
Cheers - Gavin
>>> jack.chan@nz.unisys.com 14/12/2001 13:25:49 >>>
Thanks for the tip James, I will look into it.
We are running 24X7 for some boxes, so I am thinking of some sort of
heartbeat to check the trapd, nvcorrd and nvactiond e.g(wsnmptrap to NV -->
script to postemsg to TEC --> TEC touch a local file --> script to check
touch time of file)
How are Netview experts check their daemons out there? Thanks!
Regards,
Jack
-----Original Message-----
From: James Shanks [mailto:jshanks@us.ibm.com]
Sent: Friday, 14 December 2001 2:21 p.m.
To: IBM NetView Discussion
Subject: Re: [NV-L] Nvcorrd error checking
Jack -
Try looking in the logs. nvcorrd writes to an alog and a blog in
/usr/OV/log. Errors are always written there. nvcorrd always starts in the
alog, writes a 1000 lines, switches to blog, then writes another 1000, and
switches back. And when there is an action to be run he hands that off to
actionsvr, who also has a pair of logs, nvaction.alog and blog, that
work the same way. If you still don't see anything, then you can turn on
tracing, using the command "nvcdebug -d all". There are man pages on all
this stuff, as well as lengthy discussions in the Admin Guide about how it
works.
If you read the NetView Diagnosis Guide, you may find more hints. There
you will learn that "Well-behaved" does not mean that the daemon is working.
It is a static condition which reflects how it was built, not whether it is
running correctly at this particular time. A well-behaved daemon goes down
when you do ovstop. One that is "non-well-behaved" stays up even after the
others go away.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and NT
Tivoli Software / IBM Software Group
"Chan, Jack"
<jack.chan@nz.u To: "'IBM NetView Discussion'"
nisys.com> <nv-l@tkg.com>
Sent by: cc:
owner-nv-l@tkg. Subject: [NV-L] Nvcorrd error
checking
com
12/13/01 06:45
PM
Please respond
to IBM NetView
Discussion
Hello List,
I am having a problem with nvcorrd daemon. Problem as follows:
I have a NV rule to execute a script upon receiving a trap.
I checked the trapd.log for the trap, it is there, but the script did not
execute.
ovstatus shows nvcorrd (and all the daemons) are RUNNING and well behaved.
Another symptom I see is the control desktop is not updating (through exceed
and Linux console as well). After I ovstop and ovstart, the script is
executing again.
I have DM profile to check for daemon up, and scripts to do ovstatus |grep
RUNNING and ovstatus |grep OVs_WELL_BEHAVED. But both of these checking
mechanism are NOT picking up the nvcorrd is not working as it is supposed to
(because it still thinks it is RUNNING and well behaved)
How can I check that nvcorrd is REALLY running? Some sort of heartbeat using
ruleset maybe?
regards,
Jack.
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
**********************************************************************
***** IMPORTANT INFORMATION *****
This document should be read only by those persons to whom
it is addressed and its content is not intended for use by
any other persons. If you have received this message in
error, please notify us immediately. Please also destroy and
delete the message from your computer. Any unauthorised form
of reproduction of this message is strictly prohibited.
Bank SA is not liable for the proper and complete transmission
of the information contained in this communication, nor for any
|