RE: Mon Question ...
On Sat, 26 Jun 2004, Scott A. Davis wrote: Hmmm... Ok. What am I doing wrong? My head hurts. I have the files (at least for testing purposes) /cgi-bin/monshow.cgi -rwxr-xr-x /cgh-bin/monshowrc-rwxr-xr-x monshowrc shouldn't be executable, and it's a bad idea to put files which are not meant to be executed in your cgi-bin path. /cgi-bin/mon-lib.pl -rwxr-xr-x i've never heard of this. In monshow.cgi, I have the line: my $VIEWPATH = /var/www/html/cgi-bin mon-lib.pl is also in the same dir, as required by monshow.cgi line 26: require './mon-lib.pl'; i don't know what monshow you're using, but there has never been such a thing as mon-lib.pl, and monshow has never required it. it does, however, require you to install the Mon::Client perl module, which you can get here: ftp://ftp.kernel.org/pub/software/admin/mon/Mon-0.11.tar.gz the monshow you should be using comes from the clients directory in the main mon tarball. does not seem to work. what does apache's error_log say? usually that is in /var/log/httpd. ___ mon mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/mon
Re: Why doesn't _trap_timer get reset?
--On Saturday, June 26, 2004 6:57 PM -0500 Tim Klein
[EMAIL PROTECTED] wrote:
But what if the trap never times out? It appears that the
value of _trap_timer just keeps getting decremented forever!
(There's a different conditional that keeps alerts from being
sent after it gets below zero.) I can't find anything in the
code that could ever reset it. Am I misunderstanding the
intended purpose of _trap_timer?
Tim,
Having just read this code, I'll agree that its a bit confusing. But I
don't believe this is a bug.
Essentially _trap_timer is used entirely as a way to prevent trap timeout
alarms from happening on every pass through the code after the timeout is
reached. I.e. the actual check for the timeout is where it compares
($tm - $sref-{_last_trap}) to $sref-{traptimeout}. And then when a
trap timeout actually occurs, _trap_timer is reset so that no more timeout
alerts will be sent until that much time has passed again.
Does that help?
-David Nolan
Network Software Designer
Computing Services
Carnegie Mellon University
___
mon mailing list
[EMAIL PROTECTED]
http://linux.kernel.org/mailman/listinfo/mon
Re: Why doesn't _trap_timer get reset?
But what if the trap never times out? It appears that the
value of _trap_timer just keeps getting decremented forever!
(There's a different conditional that keeps alerts from being
sent after it gets below zero.) I can't find anything in the
code that could ever reset it. Am I misunderstanding the
intended purpose of _trap_timer?
Tim,
Having just read this code, I'll agree that its a bit confusing.
But I don't believe this is a bug.
Essentially _trap_timer is used entirely as a way to prevent trap
timeout alarms from happening on every pass through the code after
the timeout is reached. I.e. the actual check for the timeout is
where it compares
($tm - $sref-{_last_trap}) to $sref-{traptimeout}. And then
when a trap timeout actually occurs, _trap_timer is reset so that no
more timeout
alerts will be sent until that much time has passed again.
Does that help?
-David Nolan
Network Software Designer
Computing Services
Carnegie Mellon University
Ah, I think I see. So _trap_timer is simply irrelevant when
all is well, and it only becomes useful *after* a trap has timed
out and mon is deciding whether it's now time to send another
alert about it? So I guess, strictly speaking, it's really
an alert timer rather than a trap timer? And if we're not in
an alert state, there's no reason to decrement it, but there's
no reason *not* to decrement it either. Did I get all that right?
Thanks, David!
Tim
___
mon mailing list
[EMAIL PROTECTED]
http://linux.kernel.org/mailman/listinfo/mon
Problem with _trap_timer and long trap timeouts?
Since we're on the topic of that _trap_timer thingie... Upon launch or reset of mon, each trap's _trap_timer is set to the value of its traptimeout. After that, _trap_timer keeps getting decremented as time progresses. This seems to make sense. But, as I read the code, it's impossible for an alert to be sent about a trap timeout unless _trap_timer has reached 0. So let's say I have a trap whose timeout is 1 month. I can't get alerted about this trap until at least 1 month has passed since the most recent launch or reset of 'mon', right? So does that mean the only way I'll ever know about a timeout of that trap is if I manage to go a month without relaunching or resetting mon? Tim ___ mon mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/mon
Re: Problem with _trap_timer and long trap timeouts?
--On Sunday, June 27, 2004 1:45 PM -0500 Tim Klein [EMAIL PROTECTED] wrote: Since we're on the topic of that _trap_timer thingie... Upon launch or reset of mon, each trap's _trap_timer is set to the value of its traptimeout. After that, _trap_timer keeps getting decremented as time progresses. This seems to make sense. But, as I read the code, it's impossible for an alert to be sent about a trap timeout unless _trap_timer has reached 0. So let's say I have a trap whose timeout is 1 month. I can't get alerted about this trap until at least 1 month has passed since the most recent launch or reset of 'mon', right? So does that mean the only way I'll ever know about a timeout of that trap is if I manage to go a month without relaunching or resetting mon? Yes, that is true. But think about the reverse case, where you have received a trap within the last month, but Mon has restarted since then. Basically, unless Mon is remembering full opstatus information between restarts, the timer must be initialized to the full timeout value at startup. And the current Mon (both 0.99.2 and the 1.0-pre* versions) Note that the code in the sourceforge CVS head contains support for saving and restoring the full opstatus. However your question lead me to look at that code and notice that trap_timer isn't saved in the current code. I'll fix that and commit it shortly. (We don't use trap timeouts very much, so I'd never noticed before.) -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 [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/mon
Re: Problem with _trap_timer and long trap timeouts?
Note that the code in the sourceforge CVS head contains support for saving and restoring the full opstatus. Yes, and that's a tremendous feature that you've added. Mon is much more powerful because of it. However your question lead me to look at that code and notice that trap_timer isn't saved in the current code. I'll fix that and commit it shortly. (We don't use trap timeouts very much, so I'd never noticed before.) Awesome, thank you! That should eliminate my concern about long trap timeouts. Tim ___ mon mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/mon
