nvsniffer only runs when you tell it to. And it is controlled by
/usr/OV/conf/nvsniffer.conf. So all you have to do is rename that file
and nvsniffer will not run again.
But that probably has nothing to do with your snmpCollect problem.
snmpCollect will defer collections when he cannot contact the device he's
trying to reach, and normally that is for 60 minutes, though this interval
is configurable. See the man page on snmpCollect.
I'm not sure what you mean when you say that you add another link. Do you
mean you added another device or pair of devices to snmpCollect's
snmpCol.conf file? I don't know offhand what that would have to do with
it, but the only way to tell what snmpCollect is doing is to start his
trace. There are two options, -T and -V, which act as toggles. You
toggle the tracing on (or off) by issuing "snmpCollect -T". This creates
the /usr/OV/log/snmpCol.trace file, unless you configured the daemon to use
a different one at start-up. If there's not enough information to
determine what is going on when your problem happens, then issue
"snmpCollect -V" to toggle on the verbose tracing. The answer to what the
source of the problem is in the trace somewhere. You may want to give IBM
Support a call if you cannot determine what's going on. Reading traces is
why they are there.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
|