2 possible bugs or documentation errors...

Summary:

1. xymond_alert interprets duration as minutes although the documentation says it is specified as seconds.
2. ...

   is interpreted as >= (greater than or equal to) instead of > (greater than) in alerts.cfg.

Version affected: 4.3.7

Steps to reproduce:

alerts.cfg:

HOST=CS1 MAIL $pg-sebsms SERVICE=svcs COLOR=red DURATION>10m REPEAT=30 RECOVERED

Also tried without the the m for minutes, as this is supposed to be the default.

/home/hobbit/server/bin/xymond_alert --test CS1 svcs --color=red --duration=11 | grep Mail 00009396 2012-05-28 14:09:46 Mail alert with command '/var/spool/mail/root "Xymon [12345] CS1:svcs CRITICAL (RED)" <mailto:syntecseb at sms2email.com'> <email address removed>' <mailto:syntecseb at sms2email.com'>

/home/hobbit/server/bin/xymond_alert --test CS1 svcs --color=red --duration=10 | grep Mail 00009483 2012-05-28 14:09:50 Mail alert with command '/var/spool/mail/root "Xymon [12345] CS1:svcs CRITICAL (RED)" <mailto:syntecseb at sms2email.com'> <email address removed>' <mailto:syntecseb at sms2email.com'>

/home/hobbit/server/bin/xymond_alert --test CS1 svcs --color=red --duration=9 | grep Mail <nothing>

But man xymond_alert says: --duration=SECONDS The SECONDS parameter is the duration of the alert in seconds.

However, as you can see above, the xymond_alert parameter is behaving as if it was in minutes (or the alerts.cfg rule is behaving as if it was in seconds). And the > is behaving as if it were >=.

Expected behaviour:

1. xymond_alert interprets duration as seconds.
2. ...

   is interpreted as > (greater than) in alerts.cfg.

Other Suggestion:

alerts.cfg should accept durations specified in seconds (with an s suffix) so that alert parameters can be more accurately defined as some tests or status changes may be occurring more often than once a minute.

Kind regards,

SebA