nv-l

Re: NetView Events not being displayed

2000-06-08 07:13:23
Subject: Re: NetView Events not being displayed
From: James_Shanks AT tivoli DOT com
To: nv-l AT lists.tivoli DOT com
Date: Thu, 8 Jun 2000 07:13:23 -0400
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 AT lmco DOT com> on 06/08/2000 06:44:33 AM

To:   "'mlemire AT jhancock DOT com'" <mlemire AT jhancock DOT com>, James 
Shanks/Tivoli
      [email protected] 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.


<Prev in Thread] Current Thread [Next in Thread>
  • Re: NetView Events not being displayed, James_Shanks <=