nv-l
[Top] [All Lists]

Re: ruleset, trapd.conf corruption causes/fixes?

To: nv-l@lists.tivoli.com
Subject: Re: ruleset, trapd.conf corruption causes/fixes?
From: "James Shanks" <SHANKS@us.tivoli.com>
Date: Fri, 21 Sep 2001 07:15:02 -0400
addtrap causes a format change trap to be issued after every execution.
That is why we recommend that you issue a sleep between them if you have
many in a single script or stop trapd while the script runs. If trapd is
not running when you run addtrap you get a message that you must restart it
to have the new definitions made active.

I have never seen addtrap result in a corrupted trapd.conf file,  but I
suppose it is possible.  I would take those error messages to heart and fix
your trapd.conf so that you can be confident that it is good and eliminate
that as a source of worry.  When you "open a ruleset" with the ruleset
editor you are not running nvcorrd, but nvrsEdit, and he does read
trapd.conf, so it would be better to fix it so that you can be sure your
ruleset is doing what you think it is.   I don't know how complex your
chnages to your current trapd.conf are, but there is a pritine copy of then
one we shipped in /usr/OV/newconfig/OVSNMP-RUN.  You can always rebuild
from that and take incremental backups along the way.

James Shanks
Level 3 Support
Tivoli NetView for UNIX and NT
Please note that my new id is jshanks@us.ibm.com



netview@toddh.net (Todd H.)@tkg.com on 09/20/2001 08:33:34 PM

Please respond to IBM NetView Discussion <nv-l@tkg.com>

Sent by:  owner-nv-l@tkg.com


To:   IBM NetView Discussion <nv-l@tkg.com>
cc:
Subject:  Re: [NV-L] ruleset, trapd.conf corruption causes/fixes?



"James Shanks" <SHANKS@us.tivoli.com> writes:

> Todd -
>
> I am sorry for your difficulties.  Perhaps I can clarify some
> things, but the bottom line is that you need to apply more current
> maintenance. NetView 6.0?  Why not 6.0.2?  I cannot emphasize enough
> that you cannot expect to run code over two years old without
> finding bugs.  We fixed several nvcorrd memory management problems
> since the code you are running was built.  That's why we issue
> maintenance.  Sorry if it sounds like I am preaching, but without a
> new nvcorrd binary, you are probably stuck.

Having remembered several nvcorrd problems --> get 6.0.2, I suspected
this might be the way.  :-)

> Does your ruleset have a reset-on-match?  Then you need 6.0.2.

Sho' nuff. It has a reset on match and threshold along with a bunch of
forwards and trap settings nodes.

We're trying to get to 6.02, believe me!  :-)


> Now, what makes you think trapd.conf is corrupted?

> If trapd can run with it, then it cannot be much of a problem.
> Normally a serious error in trapd.conf will result in trapd not
> starting and a message issued as to what line of trapd.conf is bad.

Yes--I get these.  Events showing Warnings, Indeterminates and the
like that show up in event viewer complaining about SDESC's misplaced,
end of file encountered and such shortly after running an addtrap
command.  Trapd doesn't die though.

The ruleset corruption is evident when I open a ruleset, the nodes are
garbled up and have connections I didn't specify when last saved!
Furthermore, in trap settings nodes, the trap descriptions are
missing, and strange things like this.




> You can also check trapd.conf by using xnmtrap. If it can load the
> trapd.conf, then usually so can trapd.  I have only seen one case
> where not and we are still working on that -- someone illegally
> imported a trapd.conf file from OpenView and caused the thing to
> die.  We don't support that.  But otherwise it is impossible to
> corrupt trapd.conf with either xnmtrap or addtrap because errors are
> rejected.

Can you corrupt is with the addtrap shell command, say, if your syntax
is wrong?

> How does trapd know when to load a new a file?  Usually when you
> press the last "OK" button in xnmtrap, a new trap called "Format
> Change" is sent to trapd and he then reloads the trapd.conf file.
> You can force a reload any time you want with the event command,
> which you can use the issue that trap, like this:
>      event -e FMTCHG

Ooh.  Very nice.

I assume the addtrap command also elicits a reload?

> No daemons other that trapd and ovactiond are affected by a change
> in trapd.conf.  It has no effect on netmon, nvcorrd, or any others.

Good to know.

> So I'd guess your trapd.conf is probably fine but your nvcorrd needs
> to be replaced.  Only Support can help you with that now.

Sounds reasonable.  Thanks!

--
Todd H.
http://www.toddh.net/
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l


<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web