On Fri, 11 Mar 2005, Marko Riedel wrote:
this did the trick.Thanks! Now we can get back to my original question, which is why traps that used to work no longer work with Mon::Client 1 and Mon 1.10.
I get the following output:
mon[1133]: trap trap 1 from 172.16.20.1 grp=ehring svc=SAMBA, sta=255 mon[1133]: failure for ehring SAMBA 1110555303 ehring SAMBA (smbd, nmbd) okay
As you can see, the trap reports that everything is okay, but Mon thinks that it fails. I did not touch the code that delivers the trap, except to upgrade to Mon::Client 1.
the trap is sending a status of 255, which is nonzero, which is the way the monitors/traps tell the mon server there was a failure. traps use the "sta" field to communicate the same exit value as monitors do by calling exit(3). this is set by the "retval" parameter to Mon::Client's sent_trap method. here's a snippet from trap.alert, pointing out how "retval" is specified:
$res = $c->send_trap( group => $ENV{MON_GROUP}, service => $ENV{MON_SERVICE}, retval => $ENV{MON_RETVAL}, ^^^^^^^^^^^^^^^^^^^^^^^^^^^ opstatus => $OPSTATUS, summary => $summary, detail => $detail, );
what are you using to send the trap?
_______________________________________________ mon mailing list mon@linux.kernel.org http://linux.kernel.org/mailman/listinfo/mon
