[note -- sorry if this is a duplicate, I had trouble sending the first time]

Hi all,
        I think I fixed what may be considered a bug in mon.  It causes unexpected results, so that's how I would classify it.  We are currently testing mon 1.1.0-pre1, but the same problem existed in the previous version we used, 1.0.0-pre4.

        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?

Here is a diff of the changes I made to v1.1.0-pre1...
       
3219a3220,3223
>     $sref->{"_last_output"} = $output;
>     $sref->{"_last_summary"} = $summary;
>     $sref->{"_last_detail"} = $detail;
>
3349,3355d3352
<
<     #
<     # save the output
<     #
<     $sref->{"_last_output"} = $output;
<     $sref->{"_last_summary"} = $summary;
<     $sref->{"_last_detail"} = $detail;

_______________________________________________
mon mailing list
mon <at> linux.kernel.org
http://linux.kernel.org/mailman/listinfo/mon

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 <vitroth+ <at> cmu.edu> Sent by: mon-bounces <at> linux.kernel.org 03/09/2005 01:28 PM

To mon <at> linux.kernel.org cc Subject Re: Bug fixed?

--On Wednesday, March 09, 2005 12:13 PM -0600 Aaron.Segura <at> dtn.com 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 <at> linux.kernel.org
http://linux.kernel.org/mailman/listinfo/mon

_______________________________________________
mon mailing list
mon <at> linux.kernel.org
http://linux.kernel.org/mailman/listinfo/mon

Here it comes...

D'oh!

I read that section before, but the lightbulb over my head never turned on until just now...

Thanks for the pointer.  Still, maybe the man page should be changed to be more specific regarding the contents of MON_LAST_OUTPUT and MON_LAST_SUMMARY...you know, for stupid people...not me :)

David Nolan <vitroth+ <at> cmu.edu> 03/09/2005 02:13 PM

To Aaron.Segura <at> dtn.com, mon <at> linux.kernel.org cc Subject Re: Bug fixed?

--On Wednesday, March 09, 2005 2:01 PM -0600 Aaron.Segura <at> dtn.com wrote:

> 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?

The output from the most recent run comes on STDIN.

>From the man page:
"The first line from standard input must be used as a brief summary of the
problem, normally supplied as the subject line of an email, or text sent to
an alphanumeric pager. Interpretation of all subsequent lines read from
stdin is left up to the alerting program."

And the reason to get both is so the alert about the end of the failure can
optionally include information about the failure.  Going back to my earlier
example, with output messages of 'Failure of XYZ' and 'Status OK', when
processing the upalert for the second pass, you might want your message
contents to look something like:
Current Status:
Status OK
Previous Status:
Failure of XYZ


-David Nolan
Network Software Designer
Computing Services
Carnegie Mellon University

_______________________________________________
mon mailing list
mon <at> linux.kernel.org
http://linux.kernel.org/mailman/listinfo/mon