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