nv-l

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

2001-09-21 07:15:02
Subject: Re: ruleset, trapd.conf corruption causes/fixes?
From: "James Shanks" <SHANKS AT us.tivoli DOT com>
To: nv-l AT lists.tivoli DOT 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 AT us.ibm DOT com



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

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:  Re: [NV-L] ruleset, trapd.conf corruption causes/fixes?



"James Shanks" <SHANKS AT us.tivoli DOT 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