On Sat, 9 Apr 2005, David Nolan wrote:
--On Friday, April 08, 2005 5:47 PM -0700 Jim Trocki <[EMAIL PROTECTED]> wrote:
you need to use a valid period definition, i.e. something that is meaningful to Time::Period, such as "wd {Sun-Sat}". try this:
I don't think thats his problem. An empty period definition is valid, it matches always. Mon handles this correctly.
oh. that's busted. i never realized that was the case, nor intended it to be so. just reviewed the pod page for Time::Period, and i see it does say mention that a valid period string is whitespace, but it doesn't say what it means. from testing the code it does return true when you give it an empty period string. i'm inclined to make mon treat the empty string as an error, since its meaning is ambiguous according to the documentation, and on principle.
The problem is here: opstatus => "unknown",
If he's using Mon 0.99.2 (which he is, the particular error message he reported doesn't exist in the current code), that will cause exactly this error. If he's using either the latest 1.0 or 1.1 pre release
yeah, the thing to do is not use 0.99.2, but use 1.0 or 1.1 instead. the trap handling code in the newer versions is more robust.
to reiterate and clarify, the "opstatus" arg in send_trap (the "spc" variable in the protocol) is ignored by the mon 1.0 and 1.1 servers. in 0.99.x, "opstatus" sort of gets converted into a real return value via this goofy mechanism that i don't even think i understand any more. actually, i don't think i ever understood.
if using 1.0 or 1.1, setting "retval" in send_trap ("sta" in the protocol)
to nonzero is what the trap sender should do to indicate failure, since
that's what really gets used. "retval" serves the same exact purpose in a
trap as does the process exit value in a monitor, i.e. exits with 0 for
success, nonzero for a failure. the whole trap "opstatus" thing should
be removed from the mon and Mon::Client code, since it's a remnant from
back when i was indecisive about how traps should work.Hans, I suggest you should set this to either 'ok' or 'fail', depending on the trap you're processing. Or just upgrade to a newer mon and be happier. :)
yes, upgrade, because if he finds another quirk with 0.99.2 it won't get fixed. most of the trap code between 0.99.2 and 1.x was rewritten, anyway.
http://www.kernel.org/pub/software/admin/mon/devel/
mon-1.0.0pre5 or mon-1.1.0pre1, both paired with mon-client-1.0.0pre2, or get it from cvs:
http://www.kernel.org/software/mon/development.html
_______________________________________________ mon mailing list mon@linux.kernel.org http://linux.kernel.org/mailman/listinfo/mon
