James,
I have also received messages in trapd.log from failed actions. In my case,
the action called a script which had errors in it.The failed action shows up
in nvaction.alog, with the message "sending trap for failed command.
actionsvr issues the trap (59179071) which by default was set to 'LogOnly',
and thus showed up in trapd.log.
I can send you a faulty script if you'd like to recreate it ;-)
Back to debugging...
Karin
-----Original Message-----
From: James Shanks <James_Shanks@TIVOLI.COM>
To: NV-L@UCSBVM.UCSB.EDU <NV-L@UCSBVM.UCSB.EDU>
Date: Monday, August 09, 1999 4:22 PM
Subject: Re: strange error in trapd.log (was nothing)
>Kashif -
>
>You have a talent for confusing me. Let's try this again.
>
>You get an error in trapd.log on UNIX about a ruleset action? "That
cannot
>be", I say in disbelief, unless things are really hosed in ways I do not
begin
>to imagine. Ruleset actions are logged to nvaction.alog/blog and will
never
>show up in trapd.log by any process I understand. Even automatic actions
>defined in trapd.conf are logged to ovactiond.log and not to trapd.log , so
>could you be mistaken about where you are looking? The logs are hard coded
and
>cannot be redirected in any way I know of.
>
>The only other thing I would say about this is that any command you run
from a
>ruleset should always
>
>(1) be specified with a full and complete path name (starts with a slash
"/")
>because the NetView daemons generally do not inherit the same environment
as you
>do. They get theirs from ovspmd, who actually starts them when you issue
>"ovstart" or initially by init.
>
>(2) Your script itself should be using a full and complete path name for
>wherever you want the output to go, for exactly the same reason.
>
>It is possible that, if you started the daemons yourself, by first shutting
them
>all down ("ovstop nvsecd", as root) and then issuing an "ovstart" that
ovspmd
>WILL inherit your environment and that this will have unintended effects if
you
>do not use complete and full path names.
>
>Note that you can also put a "set -x" as the first executable line of your
>script and it will trace its own execution to the appropriate log, so you
might
>try putting a path command in there, along with a set -x, if you have
already
>followed rules (1) and (2) and cannot make sense of what you see.
>
>Hope this helps.
>
>James Shanks
>Tivoli (NetView for UNIX) L3 Support
>
>
>
>Kashif Karim <kashif_karim@YAHOO.COM> on 08/09/99 04:55:05 PM
>
>Please respond to Discussion of IBM NetView and POLYCENTER Manager on
NetView
> <NV-L@UCSBVM.UCSB.EDU>
>
>To: NV-L@UCSBVM.UCSB.EDU
>cc: (bcc: James Shanks/Tivoli Systems)
>Subject:
>
>
>
>
>I am getting a strange error in trapd.log file. It says
>934227715 7 Mon Aug 09 15:41:55 1999 AFTXX03 a
>/home/k193205
>/SCRIPTS/dumpnvserverdtraps.ksh[9]:
>/SCRIPTS/OUTPUT/nvserverdtrapattrdump.out: c
>annot create
>
>dumpnvserverdtraps.ksh is actually a shell script that I call from my
>ruleset used for TEC forwarding. It is supposed to create a dump file
>nvserverdtrapattrdump.out inside my home directory
>/home/k193205/SCRIPTS/OUTPUT but somehow it seems that actionsvr daemon
>is putting an absolute path /SCRIPT... with this output file name where
>ofcourse it cannot create this file. Is there anyway to debug this or
>something...??
>
>I am running an absolutely similar scenario on my other Netview server
>successfully.
>
>Kashif
>_____________________________________________________________
>Do You Yahoo!?
>Bid and sell for free at http://auctions.yahoo.com
>
|