Subject: retrydelay issue ?

From: "Jeremy Kister" <[email-masked]>
Date: Sat, 7 Feb 2004 02:22:49 -0500

i recently implemented a perl test that argus tests via snmp every 6 hours.

frequency:      120
retrydelay:     60
[...]
           Service UDP/SNMP {
                  label:          perltest
                  frequency:      21600
                  retries:        1
                  eqvalue:        1
                  oid:            .1.3.6.1.4.1.4502.66.1.1
           }
[...]

the test failed, and argus alarmed.  I fixed the problem, and expected argus
to realize it was fixed within 60 seconds -- it hadnt.  from debugging:

srvc::frequency 21600
srvc::lasttesttime Sat 7 Feb 01:02:15 2004
srvc::nexttesttime Sat 7 Feb 07:01:15 2004
srvc::phi 75
srvc::reason SNMP error - invalid OID
srvc::retries 1
srvc::retrydelay 60

have i misconfigured something, or is something else wrong ?

Jeremy Kister
www.jeremykister.com/jeremy/

---

From: Jeff Weisberg <[email-masked]>
Date: Sun, 8 Feb 2004 13:27:15 -0500 (EST)

| i recently implemented a perl test that argus tests via snmp every 6 hours.
| 
| frequency:      120
| retrydelay:     60
| [...]
| 	     Service UDP/SNMP {
| 		    label:          perltest
| 		    frequency:      21600
| 		    retries:        1
| 		    eqvalue:        1
| 		    oid:            .1.3.6.1.4.1.4502.66.1.1
| 	     }
| [...]
| 
| the test failed, and argus alarmed.  I fixed the problem, and expected argus
| to realize it was fixed within 60 seconds -- it hadnt.  from debugging:
[...]
| have i misconfigured something, or is something else wrong ?

I think you think that retrydelay does something different than it does.

Argus does something like this:

  test the service every 'frequency' seconds

  if the test fails, retry the test 'retries' times, every 'retrydelay' seconds
  if all of the retries fail, declare the service down, otherwise up

  continue on our normal testing schedule

	--jeff

---

From: "Jeremy Kister" <[email-masked]>
Date: Mon, 9 Feb 2004 01:08:51 -0500

> I think you think that retrydelay does something different than it does.
quite right.

>   continue on our normal testing schedule

I think it'd be useful to have an inherited parameter that could keep on
testing on a special schedule until the service is up.. In fact, I'd use it
all the time.

Feature Request!

Jeremy Kister