nvstat?
So you are running this ruleset on the NetView client? If you want
assistance, it would be helpful if you would provide all relevant
particulars.
Does this ruleset run any differently on the server?
To answer your question about nvcold, there is nothing you can do to check
or otherwise verify that it is running OK
You could always run "nvUtil G" to verify that all the Smartsets can be
resolved, but that is about it.
But there is nothing in the log to suggest that there is anything wrong
with nvcold, except that it was slow to connect.
Now, how about if you answer my questions, please?
Had you just recently started the daemons when you took this nvcorrd trace?
Had you just recently started the GUI? In both cases, nvcold, the
collection or Smartset daemon, will have a lot of work to do, and that
might account for why the connection was a little slow. This would be
especially true if you had multiple NetView clients active already. But
that is NOT the source of your problem. The issue was, "Why did the trap
fail to pass the 'Query Collection' test in the ruleset?" I suggested that
it is because you used "origin" as the source of the query, and that you
should be using "Attribute 2" if this is a NetView trap. So how about it?
Has it ever worked before? Does it work when you use Attribute 2?
James Shanks
Team Leader, Level 3 Support
Tivoli NetView for UNIX and NT
gyula.furton AT degaz DOT [email protected] on 07/23/2001 03:29:15 AM
Please respond to IBM NetView Discussion <nv-l AT tkg DOT com>
Sent by: owner-nv-l AT tkg DOT com
To: IBM NetView Discussion <nv-l AT tkg DOT com>
cc:
Subject: Válasz: Re: [NV-L] ruleset is not working
To James Shanks:
Thanks a quickly answer.
You wrote:
"Well, the alog shows that at first nvcorrd cannot connect to nvcold, so he
cannot do the query collection.
Is nvcold running? Did you just start the daemons -- if so then h probabyl
busy. Notice that eventually he connects.
Then he asks if the origin of the trap is in the collection and nvcold says
it is not, so nothing is done.
Has this ever worked?
I think you should be using Attribute 2, which for NetView traps is the
hostname, rather than Origin here, which may be the NetView box itself. "
Q: Is nvcold running?
A: The processes are:
[ROOT]:/usr/OV/service:> nvstat
NOTE: ovspmd is process 51602
DAEMON NAME PROCESS PARENT DEPENDENCIES
actionsvr 71922 75620 nvsecd,nvcorrd
ems_log_agent 54764 ovspmd nvsecd,ems_sieve_agent
ems_sieve_agent 64588 ovspmd nvsecd,pmd,ovtopmd
mgragentd 70098 ovspmd nvsecd
mibserver 70794 ovspmd webserver
netmon 70592 ovspmd nvsecd,ovtopmd,trapd,ovwdb
nvcold 40056 ovspmd nvsecd,ovwdb
nvcorrd 62788 ovspmd nvsecd,trapd
nvlockd 64312 ovspmd nvsecd
nvpagerd 66710 ovspmd nvsecd
nvsecd 51346 ovspmd
nvserverd 77222 ovspmd nvsecd,nvcorrd
ovactiond 54788 ovspmd nvsecd,trapd
OVORS_M 73752 ovspmd nvsecd,pmd
ovtopmd 74594 ovspmd nvsecd,trapd,ovwdb
ovwdb 75384 ovspmd nvsecd
pmd 71256 ovspmd nvsecd
snmpCollect 52978 ovspmd nvsecd,trapd,ovwdb,ovtopmd
trapd 60704 ovspmd nvsecd,pmd
trapgend 72888 ovspmd nvsecd
webserver 70794 ovspmd ovwdb
[ROOT]:/usr/OV/service:>
How can I control the nvcold is working correct?
Regards:
Fürtön Gyula
hálózati rendszergazda
DÉGÁZ Rt., Szeged
Tel: +36-62-569-778
Mobil: +36-30-9-157-076
___________________
http://www.degaz.hu
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
|
