I think this can be explained from the man page:
"IGNORE - This is used to define a recipient that does NOT trigger any
alerts, and also terminates the search for more recipients."
What this means is that the rule matched the host "somehost" but the alert
for the recipient was suppressed. The fact that it matched means that the
UNMATCHED rule will not be invoked.
By contrast, the EXHOST causes the rule to not match "somehost", hence will
match the UNMATCHED rule.
I hope this explains.
Cheers
Jeremy
On 31 July 2015 at 16:34, Märt Laak <user-0093eef803ca@xymon.invalid> wrote:
Hi Henrik and others who help to develop this invaluable piece of
software, Xymon!
I've been used BB more than 15 years for now and now trying to migrate to
Xymon because it seems more flexible and powerful to me. Now I'm in the
middle of converting my existing (fairly complex) bbwarnrules to alerts.cfg
Everything works great except some strange to me cases with UNMATCHED.
For example, if you look at these two configurations - they seem similar
to human eye:
1: using IGNORE
---
HOST=*
IGNORE HOST=somehost
MAIL user-d7ae79a03f32@xymon.invalid
HOST=*
MAIL user-0003ff222856@xymon.invalid UNMATCHED
---
2: using EX...
---
HOST=* EXHOST=somehost
MAIL user-d7ae79a03f32@xymon.invalid
HOST=*
MAIL user-0003ff222856@xymon.invalid UNMATCHED
---
However, the first (IGNORE HOST) construction does NOT send alert to
user-039bea1231df@xymon.invalid in case of somehost alert, as expected.
Is it bug or is there some explanation for this behavior?
With kindest regards,
Märt