Re: trap received but not acted upon.
--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.
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, that will
just be ignored completely, as the newer common process_event subroutine
complete ignores this tag and only processes the return value.
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.
:)
-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
Re: Monitor output size limitation
--On Friday, April 08, 2005 6:33 PM -0700 Jim Trocki <[EMAIL PROTECTED]> wrote: On Fri, 8 Apr 2005, David Nolan wrote: This is a known bug with some regexps in perl's Text::ParseWords that is tickled by large input from mon. well it's not really a bug, it's just that the default stack size is inadequate for regexps in that module. bump up the stack allocation with "uname -s" and you'll see the problem vanishes. Ahh, that's what it was. Back when I was seeing this problem I just remember seeing reports that it was a 'regexp bug', and didn't bother to track it down. Still, you'd think perl could do a better job of detecting the approaching stack size limit and throwing an error in that case instead of segfaulting. but it's better to have fixed the glitch with changing the code than expecting that people run with a modified stack size :) True. Even when Mon didn't segfault, the performance of those regexps on significant amounts of data was sometimes horrible. I had occasions where mon.cgi's parsing of the opstatus output was taking a minute or more. Changing the encoding so a simple split could be used instead made my mon interface load almost instantly. -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
Re: trap received but not acted upon.
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
Re: trap received but not acted upon.
--On Saturday, April 09, 2005 6:54 AM -0700 Jim Trocki <[EMAIL PROTECTED]> wrote: 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. In the documentation for Time::Period, right after it says whitespace or the string 'none' are legal it says: If the period is blank, then any time period is assumed because the time period has not been restricted. In that case, inPeriod returns 1. If the period is "none", then no time period applies and inPeriod returns 0. So this seems like documented behavior to me. Though "none" doesn't really make sense to ever use. I suppose it would be useful as a way to temporarily disable a period, without deleting all the contents. But it seems useful to be able to have multiple named periods that always match by doing: period page_first: ... period page_second: ... period email_log: ... Not that I'm doing that, since my periods are all programaticaly generated. But if you're building a config file by hand having to specify a period definition for something you want to always match seems silly. -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
Re: trap received but not acted upon.
On Sat, 9 Apr 2005, David Nolan wrote: In the documentation for Time::Period, right after it says whitespace or the string 'none' are legal it says: If the period is blank, then any time period is assumed because the but... but... it didn't sat that the last i read it, i swear! in that case, it makes sense, though i would have never thought of using an empty period string. that's probably why it seemed so odd. sorry for making the confusion. ___ mon mailing list mon@linux.kernel.org http://linux.kernel.org/mailman/listinfo/mon
