--On Wednesday, June 23, 2004 9:48 AM -0700 Jim Trocki <[EMAIL PROTECTED]> wrote:
ok well whether or not it's a bug may be debatable (traps aren't scheduled so stopping the scheduler shouldn't affect them), but it sounds like the behavior of your version may be more intuitive. maybe not. i don't know.
there seem to be a number of nuances here, and i originally intended "moncmd stop" to control these first two:
related to scheduling loop:
-stopping monitors from being scheduled thus stopping the possibility of alerts from them
-stopping trap timeout alerts
not related to the scheduling loop:
-stopping alerts from traps
-delaying/stopping the processing of inbound traps
thoughts about the other two, or maybe more?
My thought here is that 'moncmd stop' is the emergency stop button. i.e. "Something is horribly broken, mon is paging everyone about everything. STOP!". Thus all things directly monitored should stop being monitored, and abolutely no alerts should be generated for any reason.
Thats basically what I made it do.
-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
