--On Monday, June 28, 2004 2:32 PM -0400 Jim Trocki <[EMAIL PROTECTED]> wrote:

this isn't the bug that time reported, but i believe it's related.  i had
a look at the code, and it does seem to me that recieving a trap before
_trap_timer falls to zero or less should reset _trap_timer to
$sref->{"traptimeout"}. the intention of _trap_timer is to send an alert
when the service doesn't recieve a trap in some amount of time,
indicating that the thing is dead or otherwise isn't working as it
should.

resetting _trap_timer in sub handle_trap should fix this problem.
for example, put this after $sref->{"_last_summary"} = $trap{"sum"}:

    #
    # a trap recieved resets the trap timeout timer
    #
    if (exists $sref->{"traptimeout")
    {
        $sref->{"_trap_timer"} = $sref->{"traptimeout"};
    }

i'll patch this in the mon-1-0-0pre1 branch. dave, what are your thoughts?
it seems to me clear-cut.



While it doesn't add any bugs, I don't believe it fixes any either. Careful reading of the code makes it clear that _trap_timer is only ever relevant after a timeout has already occurred. It prevents a timeout alert from happening on every pass through the code. Therefore the way its implemented is confusing.

If we're going to "fix" this, I'd do one of two things:

Option 1: make _trap_timer entirely responsible for all trap timeouts by resetting it when a trap is received OR when a timeout happens, and only testing _trap_timer when determining whether or not a timeout has occurred.

Option 2: remove _trap_timer and add _last_traptimeout. Set _last_traptimeout when a timeout occurs, and only call the alert code again (for a second timeout alert) when (($tm - $last_traptimeout) > traptimeout)

Either approach will make the code easier to read and understand, but I do not believe there is actually a real bug here right now.

-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

Reply via email to