This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
Well, we discovered the root cause of the problem, using truss.
We had turned off the nscd service, as part of our hardening procedure.
Starting nscd solved the problem. The key was noticing an open64() call
against /etc/.name_service_door just before a SIGSEGV was thrown.
There is an application code adjustment that should be made to handle a null
pointer return from gethostbyname, under these circumstances, on Solaris.
(There is quite a bit of discussion about this on the Sun Managers list).
It appears that the TIPN application code doesn't account for this.
We have forwarded this information to Tivoli support.
-----Original Message-----
From: Cowan, Chris [mailto:Chris.Cowan AT 2ndwaveinc DOT com]
Sent: Monday, July 16, 2001 10:13 AM
To: IBM NetView Discussion (E-mail)
Subject: [NV-L] TIPN Inventory - NV Nodes Problem
Since we've had a problem with TIPN Inventory that has been open for 3
months with support, I thought I'd share it with the list, and see if anyone
has run into this. In a nutshell, we noticed of that nv_nodes table was
not being loading. (nv_interfaces, nv_segments, and nv_networks load just
fine). Our platform is Solaris 2.7 with recent kernel patches, and NV 6.0.1
or 6.0.2.
We had about 6 production setups of NetView of which about 4 were
malfunctioning. The ones that were working were running TMF 3.6.2 with
patches. We believe we have isolated the probem in our testing to the
libtmf.so in TMF 3.6.4 (and also 3.7.x). When we perform this upgrade, we
get an "UNHANDLED EXCEPTION LOOKING UP FIELDS" message and the nv_nodes
table is not loaded. Tracing the RIM does not help, BTW. This exception
is thrown before the upload through the RIM is attempted.
Support claims that they are unable to reproduce this problem, by the
application of the TMF patch. So, most recently we tried several things
including multiple orders of installation for the TMF, Inv, NV, and TIPN
components required. In all cases, we are consistently able to cause the
failure with the TMF 3.6.4 patch.
Has anyone else seen this problem, or does this ring a bell with you in any
way. If so, feel free to contact me.
<<Christopher Cowan (E-mail).vcf>>
Well,
we discovered the root cause of the problem, using truss.
We had
turned off the nscd service, as part of our hardening
procedure. Starting nscd solved the problem. The key was
noticing an open64() call against /etc/.name_service_door just before a
SIGSEGV was thrown.
There
is an application code adjustment that should be made to handle a null pointer
return from gethostbyname, under these circumstances, on Solaris.
(There is quite a bit of discussion about this on the Sun Managers
list). It appears that the TIPN application code doesn't account for
this.
We
have forwarded this information to Tivoli support.
-----Original Message----- From: Cowan,
Chris [mailto:Chris.Cowan AT 2ndwaveinc DOT com] Sent: Monday, July 16, 2001
10:13 AM To: IBM NetView Discussion (E-mail) Subject: [NV-L]
TIPN Inventory - NV Nodes Problem
Since we've had a problem with TIPN Inventory that
has been open for 3 months with support, I thought I'd share it with the list,
and see if anyone has run into this. In a nutshell, we
noticed of that nv_nodes table was not being loading.
(nv_interfaces, nv_segments, and nv_networks load just fine). Our
platform is Solaris 2.7 with recent kernel patches, and NV 6.0.1 or
6.0.2.
We had about 6 production setups of NetView of
which about 4 were malfunctioning. The ones that were
working were running TMF 3.6.2 with patches. We believe we have isolated
the probem in our testing to the libtmf.so in TMF 3.6.4 (and also
3.7.x). When we perform this upgrade, we get an "UNHANDLED EXCEPTION
LOOKING UP FIELDS" message and the nv_nodes table is not loaded.
Tracing the RIM does not help, BTW. This exception is thrown before the
upload through the RIM is attempted.
Support claims that they are unable to reproduce
this problem, by the application of the TMF patch. So, most
recently we tried several things including multiple orders of installation for
the TMF, Inv, NV, and TIPN components required. In all cases, we
are consistently able to cause the failure with the TMF 3.6.4
patch.
Has anyone else seen this problem, or does this
ring a bell with you in any way. If so, feel free to contact
me.
<<Christopher Cowan
(E-mail).vcf>>
|