Re: [nv-l] polling daemon problems
2004-06-11 12:47:25
Well the constant synchronizing most
probably means that ipmap or xxmap is continually dying and then restarting
because something in the database is messed up.
And ovspmd is the daemon who controls
all the others, so if he's coring then things like ovstart and ovstop aren't
going to work right. If he goes down while the other daemons are
up, then they all get parented by 1 (init) and ovstop won't stop them.
I'd say you have some serious problems there which require Support
help. The only advice I would give you is to try to go back to a
known state, where everything works, and then add things more slowly so
you can see where they start to break. They are pretty badly broken
at the moment.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
jason.ctr.alburger AT faa DOT gov
Sent by: owner-nv-l AT lists.us.ibm DOT com
06/11/2004 11:24 AM
|
To
| nv-l AT lists.us.ibm DOT com
|
cc
|
|
Subject
| Re: [nv-l] polling daemon
problems |
|
I don't see any recent cores for xxmap or gtmd. I'll keep an eye
on it,
though.
Any ideas on the "synchronizing" or the ovspmd core? Is
it possible
they're not related to my polling daemon problems?
Thanks!!
Jason Alburger
609-485-7225
CPDLC Engineer
Joseph Sheairs Associates, Inc.
FAA/AOS-330
James Shanks
<jshanks AT us DOT ibm.c To:
nv-l AT lists.us.ibm DOT com
om>
cc:
Sent by:
Subject: Re: [nv-l] polling daemon problems
owner-nv-l@lists.
us.ibm.com
06/11/2004 10:51
AM
Please respond to
nv-l
Sounds like you have an xxmap problem, since he would be the one updating
the GUI for nvotChangeVertexStatus( ). He works in tandem with gtmd.
gtmd
gets the call, updated the database, and xxmap should change the status
on
the GUI, just like ipmap does for netmon.
They both have to be running for this stuff to work. I would be checking
on that before I did anything else. If xxmap is not starting you
can
restart from the GUI Tools menu. And start looking for core files
from one
of these two. But if you find any, you'll probably have to call Support
and open a problem. These programming interfaces are not popular
and very
few people use them.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
jason.ctr.alburger AT faa DOT gov
Sent by: owner-nv-l AT lists.us.ibm DOT com
To
nv-l AT lists.us.ibm DOT com
06/11/2004 10:01 AM
cc
Subject
Please respond to
[nv-l] polling
daemon
nv-l
problems
RH 7.2, NV 7.1.3 + FixPack 2
Hello all,
I'm polling a handful of MIBs on different boxes with custom built polling
daemons. I've custom built topology icons under some nodes to represent
these MIBs and use the polling daemons to control the status of the icons.
I have a myriad of problems with my snmp polling daemons - so here goes:
1.) All works as it should for about 15 minutes after ovstop/ovstart.
2.) After about 15 minutes, calls to nvotChangeVertexStatus( ) in the
polling daemon still return a NVOT_SUCCESS return code but the color of
the
icon on the map associated with the nvotChangeVertexStatus( ) call no
longer changes.
3.) Once this happens, I've performed ovstop/ovstart on that particular
polling daemon which then hangs in the nvotInit( ) call - it just never
returns.
4.) I then close the NetView GUI and restart it. It is then
"synchronizing" forever.
5.) I then have trouble closing the GUI and often get a core file -->
/usr/OV/PD/cores/ovspmd/core
5.) I can only get things to work again by killing the GUI and performing
ovstop/ovstart.
I've debugged the polling daemon and it looks like the parameters I'm
passing to the NetView calls are always OK. What else could the problem
be?
Jason Alburger
609-485-7225
CPDLC Engineer
Joseph Sheairs Associates, Inc.
FAA/AOS-330
|
|
|