RE: TIPN Inventory - NV Nodes Problem

["Cowan, Chris" <Chris.Cowan@2ndwaveinc.com>]

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@2ndwaveinc.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@2ndwaveinc.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>>