What does your in-line action do?
If that's not it, then I have no other suggestions for you. Sounds like
you would need to enlist Support at that point. They would have you run a
debug tool called gdbprof ( a script they would give you which invokes the
interactive debugger gdb) to get a series of snapshot traces of nvcorrd,
nvserverd, and probably trapd, to see what each is doing at the time the
problem occurs in the hope that would give us a clue as to the nature of
the problem. But that's not something you can do by yourself. You could
get gdb and gather your own data, but without the code to compare the
results to, you wouldn't be able to tell what you are looking at. But
perhaps worse than that from your perspective, you will have to be current
on maintenance for this to work, which means 5.1.3, else the code base
will not match the trace.
James Shanks
Team Leader, Level 3 Support
Tivoli NetView for UNIX and NT
mike.lang@barclays.co.uk@tkg.com on 03/19/2001 06:29:58 AM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
Sent by: owner-nv-l@tkg.com
To: nv-l@tkg.com
cc:
Subject: [NV-L] Event processing aborts intermittently
James,
Thanks for the suggestions, had to wait for the problem to occur again, it
did last night.
netstat -a shows all send and receive windows at 0
ovstatus shows all daemons running
running nvcdebug -d all shows event processing has stopped (nvcorrd.alog
static)
no core dumps
one ruleset in ESE.automation which DOES contain an inline action which I
did not spot earlier, that could well be the problem.
stopping actionsvr did not have any apparent effect, however when I then
stopped and started nvcorrd and nvserverd, event processing burst into
life.
I'll get that inline action out of the ruleset, there's no need for it to
be
that type.
Any thoughts?
Cheers,
Mike.
5.1.1 is out of support. You need to install 5.1.3.
What kind of closer investigation did you do?
Is nvcorrd still running? How about nvserverd? Does netstat -a show any
sockets backed up (with values of about 32K in the send and receive
queues)?
If yes, are you running any rulesets in ESE.automation? If yes, try
"ovstop actionsvr" and see if things get freed up.
Were there any cores (look in /usr/OV/PD/cores)?
If nvcorrd is still running, and you still have no clues from the above,
try running the nvcorrd trace by issuing "nvcdebug -d all" and then looking
at nvcorrd.alog. Are events still being processed?
James Shanks
Team Leader, Level 3 Support
Tivoli NetView for UNIX and NT
Subject: [NV-L] Event processing aborts intermittently
Hi all,
Kit - Netview 5.1.1 on Solaris 2.6
Every few days the events display stops, closer investigation reveals
that all ruleset processing has stopped, trapd.log is still updated OK
so it looks like a communication problem between trapd and nvcorrd?
Any ideas?
Cheers,
Mike.
Internet communications are not secure and therefore the Barclays Group
does
not accept legal responsibility for the contents of this message. Any views
or opinions presented are solely those of the author and do not necessarily
represent those of the Barclays Group.
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
|