I agree with David's point,I am not a Mon pro but what I would suggest is specifying only the alert part without the full path like this, and also as he suggested check to see the output and the status codes when mon starts....
alertdir = /usr/local/mon/alert.d
mondir = /usr/local/mon/mon.d ( this is where your tacacs.monitor script is )
watch acs_servers
service tacacs
description Make sure TACACS is working
interval 15m
monitor tacacs.monitor username password key
period wd {Sun-Sat}
alert mail.alert [EMAIL PROTECTED]
upalert mail.alert -S "Service is back up" [EMAIL PROTECTED]
alertevery 15m
alertdir = /usr/local/mon/alert.d
mondir = /usr/local/mon/mon.d ( this is where your tacacs.monitor script is )
watch acs_servers
service tacacs
description Make sure TACACS is working
interval 15m
monitor tacacs.monitor username password key
period wd {Sun-Sat}
alert mail.alert [EMAIL PROTECTED]
upalert mail.alert -S "Service is back up" [EMAIL PROTECTED]
alertevery 15m
Kishore Jalleda
On 1/27/06, David Nolan <[EMAIL PROTECTED]> wrote:
>
>
> --On Friday, January 27, 2006 14:54:40 -0500 Brian Landers
> < [EMAIL PROTECTED]> wrote:
>
> > I have a tacacs+ monitoring script that successfully detects failures
> > when run from the command-line but not from within mon. I'm at a loss
> > to troubleshoot this one and am hoping the list can help. It seems to
> > be printing the failure in the proper format and setting the exit code
> > properly, but mon never sees the service as down.
> >
> > -bash-2.05b$ ./tacacs.monitor username password key server1 server2
> > server1
> > server1: Attempt timed out!
> >
> > -bash-2.05b$ echo $?
> > 1
> >
>
> The most common source of problems on this sort is a diffence in the
> environment of your shell vs Mon. Typically when the script calls an
> external program without specifying the full path, but other possibilities
> exist.
>
> When mon runs the test what output does it see, and what exit code?
>
> You might try adding debugging code to output the contents of %ENV
> (assuming this is perl), and some debug statements tracing your scripts
> execution. (i.e. "testing server XXX", "server XXX failed", "returning
> failure code (1)", etc...)
>
> -David
>
> David Nolan <*> [EMAIL PROTECTED]
> curses: May you be forced to grep the termcap of an unclean yacc while
> a herd of rogue emacs fsck your troff and vgrind your pathalias!
>
> _______________________________________________
> mon mailing list
> mon@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/mon
>
On 1/27/06, David Nolan <[EMAIL PROTECTED]> wrote:
>
>
> --On Friday, January 27, 2006 14:54:40 -0500 Brian Landers
> < [EMAIL PROTECTED]> wrote:
>
> > I have a tacacs+ monitoring script that successfully detects failures
> > when run from the command-line but not from within mon. I'm at a loss
> > to troubleshoot this one and am hoping the list can help. It seems to
> > be printing the failure in the proper format and setting the exit code
> > properly, but mon never sees the service as down.
> >
> > -bash-2.05b$ ./tacacs.monitor username password key server1 server2
> > server1
> > server1: Attempt timed out!
> >
> > -bash-2.05b$ echo $?
> > 1
> >
>
> The most common source of problems on this sort is a diffence in the
> environment of your shell vs Mon. Typically when the script calls an
> external program without specifying the full path, but other possibilities
> exist.
>
> When mon runs the test what output does it see, and what exit code?
>
> You might try adding debugging code to output the contents of %ENV
> (assuming this is perl), and some debug statements tracing your scripts
> execution. (i.e. "testing server XXX", "server XXX failed", "returning
> failure code (1)", etc...)
>
> -David
>
> David Nolan <*> [EMAIL PROTECTED]
> curses: May you be forced to grep the termcap of an unclean yacc while
> a herd of rogue emacs fsck your troff and vgrind your pathalias!
>
> _______________________________________________
> mon mailing list
> mon@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/mon
>
_______________________________________________ mon mailing list mon@linux.kernel.org http://linux.kernel.org/mailman/listinfo/mon
