Thanks for the tip, but I'm sad to say it didn't work. I did a demand poll
on a node and then mib browsed it, and the problem is still there.
Hey, it took me about 7 min to fill up my root filesystem with a 110MB
nv6000.log file! ;-)
Hälsningar/Regards
Måns Langert
IBM Global Services
Phone: +46 8 793 3935
Mobile: +46 70 793 3935
E-mail: mans.langert@se.ibm.com
I haven't tested this, but based on the nature of the problem, I have a
suggestion you might try to circumvent it. As I understand it, the problem
originates with code in libnvsnmp.a called to resolve the community name of
the node you are querying with the MIB browser, because (a) it has no
current resolution in the xnmsnmpconf cache and (b) xnmsnmpconf has one or
more smartsets defined there. The code has to resolve the smartset to
determine whether the node you want is a member, which means that it must
do a query of nvcold, which has to query ovwdb; and once the queries are
done, to close the outstanding sockets. It does so, but the routine it
calls closes one too many, the one to the ovw GUI (which is why the browser
GUI no longer responds). So you might try demand polling the node on the
map before you query it with the broeser. That should populate the
xnmsnmpconf cache and render the lookup unnecessary, effectively bypassing
the problem. But that's just my guess. Let us know if it works.
James Shanks
Team Leader, Level 3 Support
Tivoli NetView for UNIX and NT
|