James -
In the future, please do not send notes to me directly. They should go to nv-l
where the discussion originated. Thanks.
It is likely that you are not the only curious party and that way they also get
archived. I hope you don't mind that I have taken the liberty of doing that.
The fact that nvserverd says "STARTING" rather than "RUNNING" means that ovspmd,
who started him, did not receive his initialization message. Why? That is
anybody's guess at this point, unless you can format the nettl log (netfmt -f
nettl.LOG00 and LOG01) and find a clue there. He may have had a socket problem.
If you already had TEC forwarding configured, he could have had a problem trying
to make contact with the TEC. But without a stack trace or an error message it
would be impossible to tell. Level 2 could provide you with a diagnostic tool
called "gdbprof" on Solaris ("dbxprof" on AIX) which could be attached to the
nvserverd process to get a stack trace if this continues.
Why did ovstop/ovstart clear it up? Again, no one could know this for certain,
except that whatever resource problem we had the first time, was resolved when
we tried the second time.
Is nvserverd in the path for the Event Windows? Yes, he is. Raw traps come
into trapd, who formats them into an event structure, which is them passed on to
all connected applications, including netmon, ovtopmd, snmpCollect, and nvcorrd.
nvcorrd runs the correlation rules, and there is one of these for every event
window you open, even if it is just the default "forwradall.rs" which sends
everything along to nvserverd. nvserverd maintains a huge cache of all
forwarded events, and passes these out to each connected event window, and he
also provides TEC forwarding. TEC forwarding involves getting a TCP session
going to the TEC box, and if this cannot be established, it must re-try this
session establishment for each incoming event. That is why a bogus tecint.conf
can slow the event windows to a crawl.
Hope this explanation helps.
James Shanks
Tivoli (NetView for UNIX and NT) L3 Support
"Lukens, James E" <james.e.lukens@lmco.com> on 06/08/2000 06:44:33 AM
To: "'mlemire@jhancock.com'" <mlemire@jhancock.com>, James Shanks/Tivoli
Systems@Tivoli Systems
cc:
Subject: NetView Events not being displayed
Mark/James:
I saw your entires on the NV-L Digest.
I experienced the same problem of events not showing up in the
Events window (current
events, not Event History). I am on AIX 4.2.1, and just upgraded
from NetView 5.1.1 to
NetView 6.0. Everything was working well on NetView 5.1.1, and
NetView 5.1.1 was configured
to send events to my TEC. When I upgraded to 6.0 and started the
GUI, no events were
showing up in the Events window in the Control Desk, even though
trapd.log was receiving
events (about 1 new event every 2 minutes).
Before I noticed no events showing up, I configured NetView to
forward events to my TEC.
My TEC wasn't receiving any events, that is what made me look at the
NetView Events
window and I noticed it had no events either. 'ovstatus' showed
nvserverd was STARTING
and all other daemons were RUNNING. So I configured NetView to not
send events to the
TEC, ovstop'ed all daemons, and ovstart'ed all daemons.
Question: Is nvserverd the process that sends events to the NetView
Events window?
Now, 'ovstatus' showed all daemons were RUNNING. All of the events
in trapd.log showed
up in the Events window. I configured NetView to send events to the
TEC, and they started
showing up at the TEC. All is well.
I opened PMR 07035 on this issue. Discussing this with IBM, it
seems like my problem was
the fact that nvserverd was STARTING, not RUNNING. I just don't
know why nvserverd never
got to the RUNNING state (what was keeping it in the STARTING
state?). And why did
ovstop/ovstart clear it up? I never looked at how much CPU
nvserverd was using.
I have a hunch it may have something to do with the upgrade process,
maybe the first time
nvserverd starts after being upgraded to 6.0 when the previous
version of NetView was
forwarding events to the TEC.
I just wanted to share my experience with you. Let me know if you
have any thoughts.
Thanks,
Jim Lukens, System Engineer
Lockheed Martin Corp.
|