David,
Thanks for the quick reply. I got the impression from the man page that MON_LAST_OUTPUT should be the output of the monitor from the last time it was run...
As with monitor programs, alert programs are invoked with environment
variables defined by the user in the service definition, in addition to
the following which are explicitly set by the server:
[...clip...]
MON_LAST_OUTPUT
The entire output of the monitor from the last time it exited.
With "...the last time it exited" being directly before the alert was called. I guess I don't see how it would be useful to have the results from two runs ago. How is the alert script supposed to send any sort of relevent information unless it gets the output from the most recent run? Alternatively, is there another variable which would tell me the output from the most recent monitor run?
thanks
David Nolan <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED] 03/09/2005 01:28 PM |
|
--On Wednesday, March 09, 2005 12:13 PM -0600 [EMAIL PROTECTED] wrote:
> It appears that the environment variable MON_LAST_OUTPUT doesn't
> get set until after the first alert has already been called. This was
> causing a problem where our alert script could not run because it
> couldn't find the (MON_LAST_)output that was supposed to have been
> generated by the monitor script until the SECOND alert was triggered.
> We would never actually receive the first alert because our alert script
> couldn't find the MON_LAST_OUTPUT variable.
>
> I find it hard to believe that nobody else has had this problem.
> Are we doing something wrong? Was this done this way by design?
Aaron,
I think you may be misunderstanding what MON_LAST_OUTPUT is for. It's not
supposed to be the output of the most recent test, its the output of the
previous run. i.e. if pass number 1 outputs 'Failure XYZ', and pass number
2 outputs 'Status OK', then when the alert for pass 2 is called,
MON_LAST_OUTPUT should be set to 'Failure XYZ'.
Does that explain the situation, or am I misunderstanding your explanation
of the problem?
-David Nolan
Network Software Designer
Computing Services
Carnegie Mellon University
_______________________________________________
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