Alerts variables
list Johan Sjöberg
Hi. I am trying to improve the html e-mail alert script a bit. I want the background to be blue if the cause of a recovery is a disable. Is there some variable sent to the alert script that indicates that a disable is the cause of a recovery, or do I have to create logic for this in the script, guessing based on the colors in the status message? /Johan
list Daniel Nordquist
I haven't tried this but I assume you could add the $bbcolorlevel "blue" to this script and add a status message of your choice to indicate it's been disabled?
I think your idea is a good one and I'm going to attempt to implement it on my system.
#!/bin/bash
if [ "$RECOVERED" -eq 1 ]; then
STATUS="RECOVERED"
else
case $BBCOLORLEVEL in
red)
STATUS="CRITICAL"
;;
yellow)
STATUS="WARNING"
;;
purple)
STATUS="stopped reporting"
;;
*)
STATUS="unknown status"
;;
esac
fi
MESSAGE="To: $RCPT
Subject: $BBHOSTNAME $STATUS
Content-Type: text/plain
X-Priority: 1 (Highest)
X-MSMail-Priority: High
$BBALPHAMSG"
echo "$MESSAGE" | sendmail -t
exit 0
▸
From: Johan Sjöberg [mailto:user-74c177c1220d@xymon.invalid]
Sent: Thursday, February 10, 2011 5:26 AM
To: xymon at xymon.com
Subject: [xymon] Alerts variables
Hi.
I am trying to improve the html e-mail alert script a bit. I want the background to be blue if the cause of a recovery is a disable. Is there some variable sent to the alert script that indicates that a disable is the cause of a recovery, or do I have to create logic for this in the script, guessing based on the colors in the status message?
/Johan
This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited.
This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: user-40803320aaf5@xymon.invalid .
If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health.
list Daniel Nordquist
This works in a test script... If Xymon actually sends the $bbcolorlevel of blue it should work in an alert script. I'll try that on a test host and see if it works properly. #!/bin/bash RCPT=user-681ba951e6f9@xymon.invalid BBHOSTNAME=test123 BBSVCNAME=testsvc BBCOLORLEVEL=blue BBALPHAMSG="This is the test message..." RECOVERED=1 if [ "$RECOVERED" -eq 1 ] && [ "$BBCOLORLEVEL" != blue ]; then
▸
STATUS="RECOVERED"
else
case $BBCOLORLEVEL in
red)
STATUS="CRITICAL"
;;
yellow)
STATUS="WARNING"
;;
purple)
STATUS="stopped reporting"
;;
blue)
STATUS="Alert Disabled"
;;
*)
STATUS="unknown status"
;;
esac
fi
MESSAGE="To: $RCPT
Subject: $BBHOSTNAME $BBSVCNAME $STATUS
▸
Content-Type: text/plain
X-Priority: 1 (Highest)
X-MSMail-Priority: High
$BBALPHAMSG"
echo "$MESSAGE" | sendmail -t
exit 0
▸
From: Nordquist, Daniel
Sent: Friday, February 11, 2011 12:34 PM
To: xymon at xymon.com
Subject: [xymon] RE: Alerts variables
I haven't tried this but I assume you could add the $bbcolorlevel "blue" to this script and add a status message of your choice to indicate it's been disabled?
I think your idea is a good one and I'm going to attempt to implement it on my system.
#!/bin/bash
if [ "$RECOVERED" -eq 1 ]; then
STATUS="RECOVERED"
else
case $BBCOLORLEVEL in
red)
STATUS="CRITICAL"
;;
yellow)
STATUS="WARNING"
;;
purple)
STATUS="stopped reporting"
;;
*)
STATUS="unknown status"
;;
esac
fi
MESSAGE="To: $RCPT
Subject: $BBHOSTNAME $STATUS
Content-Type: text/plain
X-Priority: 1 (Highest)
X-MSMail-Priority: High
$BBALPHAMSG"
echo "$MESSAGE" | sendmail -t
exit 0
From: Johan Sjöberg [mailto:user-74c177c1220d@xymon.invalid]
Sent: Thursday, February 10, 2011 5:26 AM
To: xymon at xymon.com
Subject: [xymon] Alerts variables
Hi.
I am trying to improve the html e-mail alert script a bit. I want the background to be blue if the cause of a recovery is a disable. Is there some variable sent to the alert script that indicates that a disable is the cause of a recovery, or do I have to create logic for this in the script, guessing based on the colors in the status message?
/Johan
This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited.
This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: user-40803320aaf5@xymon.invalid .
If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health.
This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited.
This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: user-40803320aaf5@xymon.invalid .
If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health.
list Daniel Nordquist
Did NOT work in a real alert script... Anyone know if Xymon sends the color blue or not? Is there another variable that indicates "disabled"?
▸
From: Nordquist, Daniel
Sent: Friday, February 11, 2011 12:54 PM
To: xymon at xymon.com
Subject: [xymon] RE: Alerts variables
This works in a test script... If Xymon actually sends the $bbcolorlevel of blue it should work in an alert script. I'll try that on a test host and see if it works properly.
#!/bin/bash
RCPT=user-681ba951e6f9@xymon.invalid
BBHOSTNAME=test123
BBSVCNAME=testsvc
BBCOLORLEVEL=blue
BBALPHAMSG="This is the test message..."
RECOVERED=1
if [ "$RECOVERED" -eq 1 ] && [ "$BBCOLORLEVEL" != blue ]; then
STATUS="RECOVERED"
else
case $BBCOLORLEVEL in
red)
STATUS="CRITICAL"
;;
yellow)
STATUS="WARNING"
;;
purple)
STATUS="stopped reporting"
;;
blue)
STATUS="Alert Disabled"
;;
*)
STATUS="unknown status"
;;
esac
fi
MESSAGE="To: $RCPT
Subject: $BBHOSTNAME $BBSVCNAME $STATUS
Content-Type: text/plain
X-Priority: 1 (Highest)
X-MSMail-Priority: High
$BBALPHAMSG"
echo "$MESSAGE" | sendmail -t
exit 0
From: Nordquist, Daniel
Sent: Friday, February 11, 2011 12:34 PM
To: xymon at xymon.com
Subject: [xymon] RE: Alerts variables
I haven't tried this but I assume you could add the $bbcolorlevel "blue" to this script and add a status message of your choice to indicate it's been disabled?
I think your idea is a good one and I'm going to attempt to implement it on my system.
#!/bin/bash
if [ "$RECOVERED" -eq 1 ]; then
STATUS="RECOVERED"
else
case $BBCOLORLEVEL in
red)
STATUS="CRITICAL"
;;
yellow)
STATUS="WARNING"
;;
purple)
STATUS="stopped reporting"
;;
*)
STATUS="unknown status"
;;
esac
fi
MESSAGE="To: $RCPT
Subject: $BBHOSTNAME $STATUS
Content-Type: text/plain
X-Priority: 1 (Highest)
X-MSMail-Priority: High
$BBALPHAMSG"
echo "$MESSAGE" | sendmail -t
exit 0
From: Johan Sjöberg [mailto:user-74c177c1220d@xymon.invalid]
Sent: Thursday, February 10, 2011 5:26 AM
To: xymon at xymon.com
Subject: [xymon] Alerts variables
Hi.
I am trying to improve the html e-mail alert script a bit. I want the background to be blue if the cause of a recovery is a disable. Is there some variable sent to the alert script that indicates that a disable is the cause of a recovery, or do I have to create logic for this in the script, guessing based on the colors in the status message?
/Johan
This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited.
This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: user-40803320aaf5@xymon.invalid .
If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health.
This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited.
This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: user-40803320aaf5@xymon.invalid .
If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health.
This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited.
This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: user-40803320aaf5@xymon.invalid .
If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health.
list Henrik Størner
▸
In <user-9dad0b608818@xymon.invalid> "Nordquist, Daniel" <user-b7c65cb59f49@xymon.invalid> writes:
Anyone know if Xymon sends the color blue or not? Is there another variable that indicates "disabled"?
Eh ... "blue" means "disabled". The purpose of disabling a test is exactly to STOP sending alerts. So you do not get alerts for a blue status. Regards, Henrik
list Johan Sjöberg
No, you don't get alerts, but you get a recovered message when you disable a test that is in alert state. And since we use th html_mail.pl, we currently get "red" e-mails with recovered status when someone disables an alert. I think it would look better with blue color in that case. /Johan
▸
-----Original Message-----
From: Henrik Størner [mailto:user-ce4a2c883f75@xymon.invalid]
Sent: den 12 februari 2011 11:09
To: xymon at xymon.com
Subject: Re: [xymon] RE: Alerts variables
In <user-9dad0b608818@xymon.invalid> "Nordquist, Daniel" <user-b7c65cb59f49@xymon.invalid> writes:
Anyone know if Xymon sends the color blue or not? Is there another variable that indicates "disabled"?
Eh ... "blue" means "disabled". The purpose of disabling a test is exactly to STOP sending alerts. So you do not get alerts for a blue status. Regards, Henrik
list Paul Root
But I think he wants a distinction of a Recovered email, between, the problem is cleared, or the problem was blued out by an admin. I'd like the distinction as well. Since we have a group of 8 of us, it'd be good to know w/out having to go to the web page. Especially when getting the email on the phone. Paul Root Lead Internet Systems Eng Qwest Network Services
▸
-----Original Message-----
From: Henrik Størner [mailto:user-ce4a2c883f75@xymon.invalid]
Sent: Saturday, February 12, 2011 4:09 AM
To: xymon at xymon.com
Subject: Re: [xymon] RE: Alerts variables
In <user-9dad0b608818@xymon.invalid> "Nordquist, Daniel" <user-b7c65cb59f49@xymon.invalid> writes:
Anyone know if Xymon sends the color blue or not? Is there another variable that indicates "disabled"?
Eh ... "blue" means "disabled". The purpose of disabling a test is exactly to STOP sending alerts. So you do not get alerts for a blue status. Regards, Henrik
This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful. If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.
list Henrik Størner
▸
In <user-6a08e2168b21@xymon.invalid> =?iso-8859-1?Q?Johan_Sj=F6berg?= <user-74c177c1220d@xymon.invalid> writes:
No, you don't get alerts, but you get a recovered message when you disable =
a test that is in alert state. And since we use th html_mail.pl, we current=
ly get "red" e-mails with recovered status when someone disables an alert. =
I think it would look better with blue color in that case.I am not familiar with "html_mail.pl" - is it something you invoke from a SCRIPT definition in the alerts.cfg file ? The mails that Xymon generates includes the new status color in the message subject, so a recovery due to the test being disabled comes with a subject like "Xymon [000] server1:htt is disabled (BLUE)" Regards, Henrik
list Johan Sjöberg
Yes, exactly. It is a script from Xymonton that is invoked using SCRIPT. So I would like to know if any variable is passed to the script containing the status "disabled"
▸
/Johan
-----Original Message----- From: Henrik Størner [mailto:user-ce4a2c883f75@xymon.invalid] Sent: den 14 februari 2011 11:13 To: xymon at xymon.com Subject: Re: [xymon] RE: Alerts variables In
<user-1ad989515302@xymon.invalid
ement.se> =?iso-8859-1?Q?Johan_Sj=F6berg?=
▸
<user-74c177c1220d@xymon.invalid> writes:No, you don't get alerts, but you get a recovered message when you disable = a test that is in alert state. And since we use th html_mail.pl, we current= ly get "red" e-mails with recovered status when someone disables an alert.=I think it would look better with blue color in that case.I am not familiar with "html_mail.pl" - is it something you invoke from a SCRIPT definition in the alerts.cfg file ? The mails that Xymon generates includes the new status color in the message subject, so a recovery due to the test being disabled comes with a subject like "Xymon [000] server1:htt is disabled (BLUE)" Regards, Henrik
list Henrik Størner
▸
In <user-b954bdf70b7d@xymon.invalid> =?iso-8859-1?Q?Johan_Sj=F6berg?= <user-74c177c1220d@xymon.invalid> writes:
Yes, exactly. It is a script from Xymonton that is invoked using SCRIPT. So=
I would like to know if any variable is passed to the script containing th=
e status "disabled"
OK, this turned out to be a slightly larger change than I had
anticipated. After testing things a bit, it dawned on me that
neither the mail-messages nor the script-based alerts would
be able to tell the difference between a genuine recovery
(going "green") and a recovery due to the status being disabled.
Which doesn't seem right.
The patch below should solve this. For mail/SMS alerts the
subject and message text has been changed from "recovered"
to "disabled". For scripts this can be seen from the value
of the RECOVERED variable - it will be "1" for a genuine
recovery (unchanged from before) and "2" for a recover-
by-disable.
The BBCOLORLEVEL setting remains unchanged, i.e. it will
NOT be blue. This is because BBCOLORLEVEL holds the value
of the color that triggered the alert - not the current
color of the status.
Note: When you apply this patch (against 4.3.0-RC1), please
run "make clean" and then "make" to build the package.
Without the "make clean", some of the library modules will
probably not get updated - causing weird results.
Regards,
Henrik
Index: lib/loadalerts.c
===================================================================
--- lib/loadalerts.c (revision 6631)
+++ lib/loadalerts.c (working copy)
@@ -958,7 +958,7 @@
return result;
}
- if (alert->state == A_RECOVERED) {
+ if ((alert->state == A_RECOVERED) || (alert->state == A_DISABLED)) {
/*
* Dont do the check until we are checking individual recipients (rulecrit is set).
* You dont need to have RECOVERED on the top-level rule, it's enough if a recipient
Index: lib/loadalerts.h
===================================================================
--- lib/loadalerts.h (revision 6631)
+++ lib/loadalerts.h (working copy)
@@ -18,7 +18,7 @@
#if defined(LOCALCLIENT) || !defined(CLIENTONLY)
#include <pcre.h>
-typedef enum { A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_NOTIFY, A_DEAD } astate_t;
+typedef enum { A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_DISABLED, A_NOTIFY, A_DEAD } astate_t;
typedef struct activealerts_t {
/* Identification of the alert */
Index: xymond/xymond_alert.c
===================================================================
--- xymond/xymond_alert.c (revision 6631)
+++ xymond/xymond_alert.c (working copy)
@@ -75,8 +75,8 @@
activealerts_t *ahead = NULL;
char *statename[] = {
- /* A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_NOTIFY, A_DEAD */
- "paging", "norecip", "acked", "recovered", "notify", "dead"
+ /* A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_DISABLED, A_NOTIFY, A_DEAD */
+ "paging", "norecip", "acked", "recovered", "disabled", "notify", "dead"
};
char *find_name(RbtHandle tree, char *name)
@@ -662,7 +662,7 @@
* Dont update the color here - we want recoveries to go out
* only if the alert color triggered an alert
*/
- awalk->state = A_RECOVERED;
+ awalk->state = (newcolor == COL_BLUE) ? A_DISABLED : A_RECOVERED;
}
if (oldalertstatus != newalertstatus) {
@@ -865,6 +865,7 @@
break;
case A_RECOVERED:
+ case A_DISABLED:
case A_NOTIFY:
anytogo++;
break;
@@ -895,6 +896,7 @@
break;
case A_RECOVERED:
+ case A_DISABLED:
case A_NOTIFY:
send_alert(awalk, notiflogfd);
break;
@@ -929,6 +931,7 @@
break;
case A_RECOVERED:
+ case A_DISABLED:
case A_NOTIFY:
awalk->state = A_DEAD;
/* Fall through */
Index: xymond/do_alert.c
===================================================================
--- xymond/do_alert.c (revision 6631)
+++ xymond/do_alert.c (working copy)
@@ -225,6 +225,12 @@
alert->hostname, alert->testname, recip->cfid);
break;
+ case A_DISABLED:
+ subjfmt = (include_configid ? "Xymon %s:%s disabled [cfid:%d]" : "Xymon %s:%s disabled");
+ snprintf(subj, sizeof(subj)-1, subjfmt,
+ alert->hostname, alert->testname, recip->cfid);
+ break;
• case A_NORECIP:
case A_DEAD:
/* Cannot happen */
@@ -310,6 +316,11 @@
alert->hostname, alert->testname);
break;
+ case A_DISABLED:
+ sprintf(info, "%s:%s DISABLED",
+ alert->hostname, alert->testname);
+ break;
• case A_NOTIFY:
sprintf(info, "%s:%s NOTICE",
alert->hostname, alert->testname);
@@ -365,7 +376,7 @@
int first = 1;
int alertcount = 0;
time_t now = getcurrenttime(NULL);
- char *alerttxt[A_DEAD+1] = { "Paging", "Acked", "Recovered", "Notify", "Dead" };
+ char *alerttxt[A_DEAD+1] = { "Paging", "Acked", "Recovered", "Disabled", "Notify", "Dead" };
dbgprintf("send_alert %s:%s state %d\n", alert->hostname, alert->testname, (int)alert->state);
traceprintf("send_alert %s:%s state %s\n",
@@ -380,7 +391,7 @@
continue;
}
- if (recip->noalerts && ((alert->state == A_PAGING) || (alert->state == A_RECOVERED))) {
+ if (recip->noalerts && ((alert->state == A_PAGING) || (alert->state == A_RECOVERED) || (alert->state == A_DISABLED))) {
traceprintf("Recipient '%s' dropped (NOALERT)\n", recip->recipient);
continue;
}
@@ -408,7 +419,7 @@
}
alertcount++;
}
- else if (alert->state == A_RECOVERED) {
+ else if ((alert->state == A_RECOVERED) || (alert->state == A_DISABLED)) {
/* RECOVERED messages require that we've sent out an alert before */
repeat_t *rpt = NULL;
@@ -463,7 +474,7 @@
timestamp, alert->hostname, alert->testname,
alert->ip, mailrecip, recip->cfid,
(long)now, servicecode(alert->testname));
- if (alert->state == A_RECOVERED) {
+ if ((alert->state == A_RECOVERED) || (alert->state == A_DISABLED)) {
fprintf(logfd, " %ld\n", (long)(now - alert->eventstart));
}
else {
@@ -561,7 +572,17 @@
putenv(bbcolorlevel);
recovered = (char *)malloc(strlen("RECOVERED=") + 2);
- sprintf(recovered, "RECOVERED=%d", ((alert->state == A_RECOVERED) ? 1 : 0));
+ switch (alert->state) {
+ case A_RECOVERED:
+ strcpy(recovered, "RECOVERED=1");
+ break;
+ case A_DISABLED:
+ strcpy(recovered, "RECOVERED=2");
+ break;
+ default:
+ strcpy(recovered, "RECOVERED=0");
+ break;
+ }
putenv(recovered);
downsecs = (char *)malloc(strlen("DOWNSECS=") + 20);
@@ -572,7 +593,7 @@
sprintf(eventtstamp, "EVENTSTART=%ld", (long)alert->eventstart);
putenv(eventtstamp);
- if (alert->state == A_RECOVERED) {
+ if ((alert->state == A_RECOVERED) || (alert->state == A_DISABLED)) {
downsecsmsg = (char *)malloc(strlen("DOWNSECSMSG=Event duration :") + 20);
sprintf(downsecsmsg, "DOWNSECSMSG=Event duration : %ld", (long)(getcurrenttime(NULL) - alert->eventstart));
}
@@ -628,7 +649,7 @@
timestamp, alert->hostname, alert->testname,
alert->ip, scriptrecip, (long)now,
servicecode(alert->testname));
- if (alert->state == A_RECOVERED) {
+ if ((alert->state == A_RECOVERED) || (alert->state == A_DISABLED)) {
fprintf(logfd, " %ld\n", (long)(now - alert->eventstart));
}
else {
list Daniel Nordquist
Can we apply this code to 4.2.3?
▸
-----Original Message-----
From: Henrik Størner [mailto:user-ce4a2c883f75@xymon.invalid]
Sent: Monday, February 14, 2011 7:40 AM
To: xymon at xymon.com
Subject: Re: [xymon] RE: Alerts variables
In <user-b954bdf70b7d@xymon.invalid> =?iso-8859-1?Q?Johan_Sj=F6berg?= <user-74c177c1220d@xymon.invalid> writes:
Yes, exactly. It is a script from Xymonton that is invoked using SCRIPT. So= I would like to know if any variable is passed to the script containing th= e status "disabled"
OK, this turned out to be a slightly larger change than I had
anticipated. After testing things a bit, it dawned on me that
neither the mail-messages nor the script-based alerts would
be able to tell the difference between a genuine recovery
(going "green") and a recovery due to the status being disabled.
Which doesn't seem right.
The patch below should solve this. For mail/SMS alerts the
subject and message text has been changed from "recovered"
to "disabled". For scripts this can be seen from the value
of the RECOVERED variable - it will be "1" for a genuine
recovery (unchanged from before) and "2" for a recover-
by-disable.
The BBCOLORLEVEL setting remains unchanged, i.e. it will
NOT be blue. This is because BBCOLORLEVEL holds the value
of the color that triggered the alert - not the current
color of the status.
Note: When you apply this patch (against 4.3.0-RC1), please
run "make clean" and then "make" to build the package.
Without the "make clean", some of the library modules will
probably not get updated - causing weird results.
Regards,
Henrik
Index: lib/loadalerts.c
===================================================================
--- lib/loadalerts.c (revision 6631)
+++ lib/loadalerts.c (working copy)
@@ -958,7 +958,7 @@
return result;
}
- if (alert->state == A_RECOVERED) {
+ if ((alert->state == A_RECOVERED) || (alert->state == A_DISABLED)) {
/*
* Dont do the check until we are checking individual recipients (rulecrit is set).
* You dont need to have RECOVERED on the top-level rule, it's enough if a recipient
Index: lib/loadalerts.h
===================================================================
--- lib/loadalerts.h (revision 6631)
+++ lib/loadalerts.h (working copy)
@@ -18,7 +18,7 @@
#if defined(LOCALCLIENT) || !defined(CLIENTONLY)
#include <pcre.h>
-typedef enum { A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_NOTIFY, A_DEAD } astate_t;
+typedef enum { A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_DISABLED, A_NOTIFY, A_DEAD } astate_t;
typedef struct activealerts_t {
/* Identification of the alert */
Index: xymond/xymond_alert.c
===================================================================
--- xymond/xymond_alert.c (revision 6631)
+++ xymond/xymond_alert.c (working copy)
@@ -75,8 +75,8 @@
activealerts_t *ahead = NULL;
char *statename[] = {
- /* A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_NOTIFY, A_DEAD */
- "paging", "norecip", "acked", "recovered", "notify", "dead"
+ /* A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_DISABLED, A_NOTIFY, A_DEAD */
+ "paging", "norecip", "acked", "recovered", "disabled", "notify", "dead"
};
char *find_name(RbtHandle tree, char *name)
@@ -662,7 +662,7 @@
* Dont update the color here - we want recoveries to go out
* only if the alert color triggered an alert
*/
- awalk->state = A_RECOVERED;
+ awalk->state = (newcolor == COL_BLUE) ? A_DISABLED : A_RECOVERED;
}
if (oldalertstatus != newalertstatus) {
@@ -865,6 +865,7 @@
break;
case A_RECOVERED:
+ case A_DISABLED:
case A_NOTIFY:
anytogo++;
break;
@@ -895,6 +896,7 @@
break;
case A_RECOVERED:
+ case A_DISABLED:
case A_NOTIFY:
send_alert(awalk, notiflogfd);
break;
@@ -929,6 +931,7 @@
break;
case A_RECOVERED:
+ case A_DISABLED:
case A_NOTIFY:
awalk->state = A_DEAD;
/* Fall through */
Index: xymond/do_alert.c
===================================================================
--- xymond/do_alert.c (revision 6631)
+++ xymond/do_alert.c (working copy)
@@ -225,6 +225,12 @@
alert->hostname, alert->testname, recip->cfid);
break;
+ case A_DISABLED:
+ subjfmt = (include_configid ? "Xymon %s:%s disabled [cfid:%d]" : "Xymon %s:%s disabled");
+ snprintf(subj, sizeof(subj)-1, subjfmt,
+ alert->hostname, alert->testname, recip->cfid);
+ break;
• case A_NORECIP:
case A_DEAD:
/* Cannot happen */
@@ -310,6 +316,11 @@
alert->hostname, alert->testname);
break;
+ case A_DISABLED:
+ sprintf(info, "%s:%s DISABLED",
+ alert->hostname, alert->testname);
+ break;
• case A_NOTIFY:
sprintf(info, "%s:%s NOTICE",
alert->hostname, alert->testname);
@@ -365,7 +376,7 @@
int first = 1;
int alertcount = 0;
time_t now = getcurrenttime(NULL);
- char *alerttxt[A_DEAD+1] = { "Paging", "Acked", "Recovered", "Notify", "Dead" };
+ char *alerttxt[A_DEAD+1] = { "Paging", "Acked", "Recovered", "Disabled", "Notify", "Dead" };
dbgprintf("send_alert %s:%s state %d\n", alert->hostname, alert->testname, (int)alert->state);
traceprintf("send_alert %s:%s state %s\n",
@@ -380,7 +391,7 @@
continue;
}
- if (recip->noalerts && ((alert->state == A_PAGING) || (alert->state == A_RECOVERED))) {
+ if (recip->noalerts && ((alert->state == A_PAGING) || (alert->state == A_RECOVERED) || (alert->state == A_DISABLED))) {
traceprintf("Recipient '%s' dropped (NOALERT)\n", recip->recipient);
continue;
}
@@ -408,7 +419,7 @@
}
alertcount++;
}
- else if (alert->state == A_RECOVERED) {
+ else if ((alert->state == A_RECOVERED) || (alert->state == A_DISABLED)) {
/* RECOVERED messages require that we've sent out an alert before */
repeat_t *rpt = NULL;
@@ -463,7 +474,7 @@
timestamp, alert->hostname, alert->testname,
alert->ip, mailrecip, recip->cfid,
(long)now, servicecode(alert->testname));
- if (alert->state == A_RECOVERED) {
+ if ((alert->state == A_RECOVERED) || (alert->state == A_DISABLED)) {
fprintf(logfd, " %ld\n", (long)(now - alert->eventstart));
}
else {
@@ -561,7 +572,17 @@
putenv(bbcolorlevel);
recovered = (char *)malloc(strlen("RECOVERED=") + 2);
- sprintf(recovered, "RECOVERED=%d", ((alert->state == A_RECOVERED) ? 1 : 0));
+ switch (alert->state) {
+ case A_RECOVERED:
+ strcpy(recovered, "RECOVERED=1");
+ break;
+ case A_DISABLED:
+ strcpy(recovered, "RECOVERED=2");
+ break;
+ default:
+ strcpy(recovered, "RECOVERED=0");
+ break;
+ }
putenv(recovered);
downsecs = (char *)malloc(strlen("DOWNSECS=") + 20);
@@ -572,7 +593,7 @@
sprintf(eventtstamp, "EVENTSTART=%ld", (long)alert->eventstart);
putenv(eventtstamp);
- if (alert->state == A_RECOVERED) {
+ if ((alert->state == A_RECOVERED) || (alert->state == A_DISABLED)) {
downsecsmsg = (char *)malloc(strlen("DOWNSECSMSG=Event duration :") + 20);
sprintf(downsecsmsg, "DOWNSECSMSG=Event duration : %ld", (long)(getcurrenttime(NULL) - alert->eventstart));
}
@@ -628,7 +649,7 @@
timestamp, alert->hostname, alert->testname,
alert->ip, scriptrecip, (long)now,
servicecode(alert->testname));
- if (alert->state == A_RECOVERED) {
+ if ((alert->state == A_RECOVERED) || (alert->state == A_DISABLED)) {
fprintf(logfd, " %ld\n", (long)(now - alert->eventstart));
}
else {
This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited.
This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: user-40803320aaf5@xymon.invalid .
If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health.
list Henrik Størner
In <user-bdd7400d1b9a@xymon.invalid> "Nordquist, Daniel" <user-b7c65cb59f49@xymon.invalid> writes:
Can we apply this code to 4.2.3?
Already done. Regards, Henrik
▸
-----Original Message----- From: Henrik St=C3=B8rner [mailto:user-ce4a2c883f75@xymon.invalid] Sent: Monday, February 14, 2011 7:40 AM To: xymon at xymon.com Subject: Re: [xymon] RE: Alerts variables
In <user-b954bdf70b7d@xymon.invalid>=
=3D?iso-8859-1?Q?Johan_Sj=3DF6berg?=3D <user-74c177c1220d@xymon.invalid> =
writes:Yes, exactly. It is a script from Xymonton that is invoked using SCRIPT. S= o=3D I would like to know if any variable is passed to the script containing t= h=3D
▸
e status "disabled"
OK, this turned out to be a slightly larger change than I had anticipated. After testing things a bit, it dawned on me that neither the mail-messages nor the script-based alerts would be able to tell the difference between a genuine recovery (going "green") and a recovery due to the status being disabled.
Which doesn't seem right.
The patch below should solve this. For mail/SMS alerts the subject and message text has been changed from "recovered" to "disabled". For scripts this can be seen from the value of the RECOVERED variable - it will be "1" for a genuine recovery (unchanged from before) and "2" for a recover- by-disable.
The BBCOLORLEVEL setting remains unchanged, i.e. it will NOT be blue. This is because BBCOLORLEVEL holds the value of the color that triggered the alert - not the current color of the status.
Note: When you apply this patch (against 4.3.0-RC1), please run "make clean" and then "make" to build the package. Without the "make clean", some of the library modules will probably not get updated - causing weird results.
Regards, Henrik
Index: lib/loadalerts.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- lib/loadalerts.c (revision 6631)
+++ lib/loadalerts.c (working copy)
@@ -958,7 +958,7 @@
return result;
}- if (alert->state =3D=3D A_RECOVERED) {
+ if ((alert->state =3D=3D A_RECOVERED) || (alert->state =3D=3D A_DIS=
ABLED)) {
/*
* Dont do the check until we are checking individual recip=
ients (rulecrit is set).
* You dont need to have RECOVERED on the top-level rule, i=
t's enough if a recipient
Index: lib/loadalerts.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
▸
--- lib/loadalerts.h (revision 6631)
+++ lib/loadalerts.h (working copy)
@@ -18,7 +18,7 @@
#if defined(LOCALCLIENT) || !defined(CLIENTONLY)
#include <pcre.h>-typedef enum { A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_NOTIFY, A_DEAD=
} astate_t;
+typedef enum { A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_DISABLED, A_NO=
TIFY, A_DEAD } astate_t;typedef struct activealerts_t {
/* Identification of the alert */
Index: xymond/xymond_alert.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- xymond/xymond_alert.c (revision 6631)
+++ xymond/xymond_alert.c (working copy)
@@ -75,8 +75,8 @@
activealerts_t *ahead =3D NULL;char *statename[] =3D {
▸
- /* A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_NOTIFY, A_DEAD */
- "paging", "norecip", "acked", "recovered", "notify", "dead"
+ /* A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_DISABLED, A_NOTIFY,=
A_DEAD */
+ "paging", "norecip", "acked", "recovered", "disabled", "notify", "d=
ead"
};char *find_name(RbtHandle tree, char *name)
@@ -662,7 +662,7 @@
* Dont update the color here - we want rec=
overies to go out
* only if the alert color triggered an ale=
rt
*/
- awalk->state =3D A_RECOVERED;
+ awalk->state =3D (newcolor =3D=3D COL_BLUE)=
? A_DISABLED : A_RECOVERED;
} if (oldalertstatus !=3D newalertstatus) {
▸
@@ -865,6 +865,7 @@
break; case A_RECOVERED:
+ case A_DISABLED:
case A_NOTIFY:
anytogo++;
break;
@@ -895,6 +896,7 @@
break; case A_RECOVERED:
+ case A_DISABLED:
case A_NOTIFY:
send_alert(awalk, notiflogf=
d);
break;
@@ -929,6 +931,7 @@
break; case A_RECOVERED:
+ case A_DISABLED:
case A_NOTIFY:
awalk->state =3D A_DEAD;
/* Fall through */
Index: xymond/do_alert.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
▸
--- xymond/do_alert.c (revision 6631)
+++ xymond/do_alert.c (working copy)
@@ -225,6 +225,12 @@
alert->hostname, alert->testname, recip->cfid);
break;+ case A_DISABLED:
+ subjfmt =3D (include_configid ? "Xymon %s:%s disabled [cfid=
:%d]" : "Xymon %s:%s disabled");
▸
+ snprintf(subj, sizeof(subj)-1, subjfmt,
+ alert->hostname, alert->testname, recip->cfid);
+ break;
• case A_NORECIP:
case A_DEAD:
/* Cannot happen */
@@ -310,6 +316,11 @@
alert->hostname, alert->testname);
break;+ case A_DISABLED:
+ sprintf(info, "%s:%s DISABLED",
+ alert->hostname, alert->testname);
+ break;
• case A_NOTIFY:
sprintf(info, "%s:%s NOTICE",
alert->hostname, alert->testname);
@@ -365,7 +376,7 @@
int first =3D 1;
int alertcount =3D 0;
time_t now =3D getcurrenttime(NULL);
- char *alerttxt[A_DEAD+1] =3D { "Paging", "Acked", "Recovered", "Not=
ify", "Dead" };
+ char *alerttxt[A_DEAD+1] =3D { "Paging", "Acked", "Recovered", "Dis=
abled", "Notify", "Dead" }; dbgprintf("send_alert %s:%s state %d\n", alert->hostname, alert->te=
stname, (int)alert->state);
traceprintf("send_alert %s:%s state %s\n",
@@ -380,7 +391,7 @@
continue;
}- if (recip->noalerts && ((alert->state =3D=3D A_PAGING) || (=
alert->state =3D=3D A_RECOVERED))) {
+ if (recip->noalerts && ((alert->state =3D=3D A_PAGING) || (=
alert->state =3D=3D A_RECOVERED) || (alert->state =3D=3D A_DISABLED))) {
traceprintf("Recipient '%s' dropped (NOALERT)\n", r=
ecip->recipient);
continue;
}
@@ -408,7 +419,7 @@
}
alertcount++;
}
- else if (alert->state =3D=3D A_RECOVERED) {
+ else if ((alert->state =3D=3D A_RECOVERED) || (alert->state=
=3D=3D A_DISABLED)) {
/* RECOVERED messages require that we've sent out a=
n alert before */
repeat_t *rpt =3D NULL;@@ -463,7 +474,7 @@
timestamp, alert->h=
ostname, alert->testname,
alert->ip, mailreci=
p, recip->cfid,
(long)now, servicec=
ode(alert->testname));
- if (alert->state =3D=3D A_R=
ECOVERED) {
+ if ((alert->state =3D=3D A_=
RECOVERED) || (alert->state =3D=3D A_DISABLED)) {
fprintf(logfd, " %l=
d\n", (long)(now - alert->eventstart));
}
else {
@@ -561,7 +572,17 @@
putenv(bbcolorlevel); recovered =3D (char *)malloc(strlen=
("RECOVERED=3D") + 2);
- sprintf(recovered, "RECOVERED=3D%d"=
, ((alert->state =3D=3D A_RECOVERED) ? 1 : 0));
+ switch (alert->state) {
+ case A_RECOVERED:
+ strcpy(recovered, "RECOVERE=
D=3D1");
+ break;
+ case A_DISABLED:
+ strcpy(recovered, "RECOVERE=
D=3D2");
+ break;
+ default:
+ strcpy(recovered, "RECOVERE=
D=3D0");
+ break;
+ }
putenv(recovered); downsecs =3D (char *)malloc(strlen(=
"DOWNSECS=3D") + 20);
@@ -572,7 +593,7 @@
sprintf(eventtstamp, "EVENTSTART=3D=
%ld", (long)alert->eventstart);
putenv(eventtstamp);- if (alert->state =3D=3D A_RECOVERED=
) {
+ if ((alert->state =3D=3D A_RECOVERE=
D) || (alert->state =3D=3D A_DISABLED)) {
downsecsmsg =3D (char *)mal=
loc(strlen("DOWNSECSMSG=3DEvent duration :") + 20);
sprintf(downsecsmsg, "DOWNS=
ECSMSG=3DEvent duration : %ld", (long)(getcurrenttime(NULL) - alert->events=
tart));
}
@@ -628,7 +649,7 @@
timestamp, alert->h=
ostname, alert->testname,
alert->ip, scriptre=
cip, (long)now,
servicecode(alert->=
testname));
- if (alert->state =3D=3D A_R=
ECOVERED) {
+ if ((alert->state =3D=3D A_=
RECOVERED) || (alert->state =3D=3D A_DISABLED)) {
fprintf(logfd, " %l=
d\n", (long)(now - alert->eventstart));
}
else {This e-mail message and any attached files are confidential and are intende= d solely for the use of the addressee(s) named above. If you are not the in= tended recipient, any review, use, or distribution of this e-mail message a= nd any attached files is strictly prohibited.
This communication may contain material protected by Federal privacy regula= tions, attorney-client work product, or other privileges. If you have recei= ved this confidential communication in error, please notify the sender imme= diately by reply e-mail message and permanently delete the original message= . To reply to our email administrator directly, send an email to: postmas= user-06e12ddf8aed@xymon.invalid .
If this e-mail message concerns a contract matter, be advised that no emplo= yee or agent is authorized to conclude any binding agreement on behalf of O= rlando Health by e-mail without express written confirmation by an officer = of the corporation. Any views or opinions presented in this e-mail are sole= ly those of the author and do not necessarily represent those of Orlando He= alth.
list Daniel Nordquist
I apologize for my confusion, but I don't understand what you mean by this. Is this code already in the 4.2.3 version I have installed, and I just need to use the proper scripting to look for the value of the recovery variable; ie - 1 or 2?
▸
-----Original Message-----
From: Henrik Størner [mailto:user-ce4a2c883f75@xymon.invalid]
Sent: Thursday, February 17, 2011 3:23 AM
To: xymon at xymon.com
Subject: Re: [xymon] RE: Alerts variables
In <user-bdd7400d1b9a@xymon.invalid> "Nordquist, Daniel" <user-b7c65cb59f49@xymon.invalid> writes:
Can we apply this code to 4.2.3?
Already done. Regards, Henrik
-----Original Message----- From: Henrik St=C3=B8rner [mailto:user-ce4a2c883f75@xymon.invalid] Sent: Monday, February 14, 2011 7:40 AM To: xymon at xymon.com Subject: Re: [xymon] RE: Alerts variables
In <user-b954bdf70b7d@xymon.invalid>= =3D?iso-8859-1?Q?Johan_Sj=3DF6berg?=3D <user-74c177c1220d@xymon.invalid> = writes:
Yes, exactly. It is a script from Xymonton that is invoked using SCRIPT. S= o=3D I would like to know if any variable is passed to the script containing t= h=3D e status "disabled"
OK, this turned out to be a slightly larger change than I had anticipated. After testing things a bit, it dawned on me that neither the mail-messages nor the script-based alerts would be able to tell the difference between a genuine recovery (going "green") and a recovery due to the status being disabled.
Which doesn't seem right.
The patch below should solve this. For mail/SMS alerts the subject and message text has been changed from "recovered" to "disabled". For scripts this can be seen from the value of the RECOVERED variable - it will be "1" for a genuine recovery (unchanged from before) and "2" for a recover- by-disable.
The BBCOLORLEVEL setting remains unchanged, i.e. it will NOT be blue. This is because BBCOLORLEVEL holds the value of the color that triggered the alert - not the current color of the status.
Note: When you apply this patch (against 4.3.0-RC1), please run "make clean" and then "make" to build the package. Without the "make clean", some of the library modules will probably not get updated - causing weird results.
Regards, Henrik
Index: lib/loadalerts.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- lib/loadalerts.c (revision 6631)
+++ lib/loadalerts.c (working copy)
@@ -958,7 +958,7 @@
return result;
}- if (alert->state =3D=3D A_RECOVERED) {
+ if ((alert->state =3D=3D A_RECOVERED) || (alert->state =3D=3D A_DIS=
ABLED)) {
/*
* Dont do the check until we are checking individual recip=
ients (rulecrit is set).
* You dont need to have RECOVERED on the top-level rule, i=
t's enough if a recipient
Index: lib/loadalerts.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- lib/loadalerts.h (revision 6631)
+++ lib/loadalerts.h (working copy)
@@ -18,7 +18,7 @@
#if defined(LOCALCLIENT) || !defined(CLIENTONLY)
#include <pcre.h>-typedef enum { A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_NOTIFY, A_DEAD=
} astate_t;
+typedef enum { A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_DISABLED, A_NO=
TIFY, A_DEAD } astate_t;typedef struct activealerts_t {
/* Identification of the alert */
Index: xymond/xymond_alert.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- xymond/xymond_alert.c (revision 6631)
+++ xymond/xymond_alert.c (working copy)
@@ -75,8 +75,8 @@
activealerts_t *ahead =3D NULL;char *statename[] =3D {
- /* A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_NOTIFY, A_DEAD */
- "paging", "norecip", "acked", "recovered", "notify", "dead"
+ /* A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_DISABLED, A_NOTIFY,=
A_DEAD */
+ "paging", "norecip", "acked", "recovered", "disabled", "notify", "d=
ead"
};char *find_name(RbtHandle tree, char *name)
@@ -662,7 +662,7 @@
* Dont update the color here - we want rec=
overies to go out
* only if the alert color triggered an ale=
rt
*/
- awalk->state =3D A_RECOVERED;
+ awalk->state =3D (newcolor =3D=3D COL_BLUE)=
? A_DISABLED : A_RECOVERED;
} if (oldalertstatus !=3D newalertstatus) {
@@ -865,6 +865,7 @@
break; case A_RECOVERED:
+ case A_DISABLED:
case A_NOTIFY:
anytogo++;
break;
@@ -895,6 +896,7 @@
break; case A_RECOVERED:
+ case A_DISABLED:
case A_NOTIFY:
send_alert(awalk, notiflogf=
d);
break;
@@ -929,6 +931,7 @@
break; case A_RECOVERED:
+ case A_DISABLED:
case A_NOTIFY:
awalk->state =3D A_DEAD;
/* Fall through */
Index: xymond/do_alert.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- xymond/do_alert.c (revision 6631)
+++ xymond/do_alert.c (working copy)
@@ -225,6 +225,12 @@
alert->hostname, alert->testname, recip->cfid);
break;+ case A_DISABLED:
+ subjfmt =3D (include_configid ? "Xymon %s:%s disabled [cfid=
:%d]" : "Xymon %s:%s disabled");
+ snprintf(subj, sizeof(subj)-1, subjfmt,
+ alert->hostname, alert->testname, recip->cfid);
+ break;
• case A_NORECIP:
case A_DEAD:
/* Cannot happen */
@@ -310,6 +316,11 @@
alert->hostname, alert->testname);
break;+ case A_DISABLED:
+ sprintf(info, "%s:%s DISABLED",
+ alert->hostname, alert->testname);
+ break;
• case A_NOTIFY:
sprintf(info, "%s:%s NOTICE",
alert->hostname, alert->testname);
@@ -365,7 +376,7 @@
int first =3D 1;
int alertcount =3D 0;
time_t now =3D getcurrenttime(NULL);
- char *alerttxt[A_DEAD+1] =3D { "Paging", "Acked", "Recovered", "Not=
ify", "Dead" };
+ char *alerttxt[A_DEAD+1] =3D { "Paging", "Acked", "Recovered", "Dis=
abled", "Notify", "Dead" }; dbgprintf("send_alert %s:%s state %d\n", alert->hostname, alert->te=
stname, (int)alert->state);
traceprintf("send_alert %s:%s state %s\n",
@@ -380,7 +391,7 @@
continue;
}- if (recip->noalerts && ((alert->state =3D=3D A_PAGING) || (=
alert->state =3D=3D A_RECOVERED))) {
+ if (recip->noalerts && ((alert->state =3D=3D A_PAGING) || (=
alert->state =3D=3D A_RECOVERED) || (alert->state =3D=3D A_DISABLED))) {
traceprintf("Recipient '%s' dropped (NOALERT)\n", r=
ecip->recipient);
continue;
}
@@ -408,7 +419,7 @@
}
alertcount++;
}
- else if (alert->state =3D=3D A_RECOVERED) {
+ else if ((alert->state =3D=3D A_RECOVERED) || (alert->state=
=3D=3D A_DISABLED)) {
/* RECOVERED messages require that we've sent out a=
n alert before */
repeat_t *rpt =3D NULL;@@ -463,7 +474,7 @@
timestamp, alert->h=
ostname, alert->testname,
alert->ip, mailreci=
p, recip->cfid,
(long)now, servicec=
ode(alert->testname));
- if (alert->state =3D=3D A_R=
ECOVERED) {
+ if ((alert->state =3D=3D A_=
RECOVERED) || (alert->state =3D=3D A_DISABLED)) {
fprintf(logfd, " %l=
d\n", (long)(now - alert->eventstart));
}
else {
@@ -561,7 +572,17 @@
putenv(bbcolorlevel); recovered =3D (char *)malloc(strlen=
("RECOVERED=3D") + 2);
- sprintf(recovered, "RECOVERED=3D%d"=
, ((alert->state =3D=3D A_RECOVERED) ? 1 : 0));
+ switch (alert->state) {
+ case A_RECOVERED:
+ strcpy(recovered, "RECOVERE=
D=3D1");
+ break;
+ case A_DISABLED:
+ strcpy(recovered, "RECOVERE=
D=3D2");
+ break;
+ default:
+ strcpy(recovered, "RECOVERE=
D=3D0");
+ break;
+ }
putenv(recovered); downsecs =3D (char *)malloc(strlen(=
"DOWNSECS=3D") + 20);
@@ -572,7 +593,7 @@
sprintf(eventtstamp, "EVENTSTART=3D=
%ld", (long)alert->eventstart);
putenv(eventtstamp);- if (alert->state =3D=3D A_RECOVERED=
) {
+ if ((alert->state =3D=3D A_RECOVERE=
D) || (alert->state =3D=3D A_DISABLED)) {
downsecsmsg =3D (char *)mal=
loc(strlen("DOWNSECSMSG=3DEvent duration :") + 20);
sprintf(downsecsmsg, "DOWNS=
ECSMSG=3DEvent duration : %ld", (long)(getcurrenttime(NULL) - alert->events=
tart));
}
@@ -628,7 +649,7 @@
timestamp, alert->h=
ostname, alert->testname,
alert->ip, scriptre=
cip, (long)now,
servicecode(alert->=
testname));
- if (alert->state =3D=3D A_R=
ECOVERED) {
+ if ((alert->state =3D=3D A_=
RECOVERED) || (alert->state =3D=3D A_DISABLED)) {
fprintf(logfd, " %l=
d\n", (long)(now - alert->eventstart));
}
else {This e-mail message and any attached files are confidential and are intende= d solely for the use of the addressee(s) named above. If you are not the in= tended recipient, any review, use, or distribution of this e-mail message a= nd any attached files is strictly prohibited.
This communication may contain material protected by Federal privacy regula= tions, attorney-client work product, or other privileges. If you have recei= ved this confidential communication in error, please notify the sender imme= diately by reply e-mail message and permanently delete the original message= . To reply to our email administrator directly, send an email to: postmas= user-06e12ddf8aed@xymon.invalid .
If this e-mail message concerns a contract matter, be advised that no emplo= yee or agent is authorized to conclude any binding agreement on behalf of O= rlando Health by e-mail without express written confirmation by an officer = of the corporation. Any views or opinions presented in this e-mail are sole= ly those of the author and do not necessarily represent those of Orlando He= alth.
This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited. This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: user-40803320aaf5@xymon.invalid . If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health.
list Daniel Nordquist
I apologize for my confusion, but I don't understand what you mean by this. -----Original Message----- From: Henrik Størner [mailto:user-ce4a2c883f75@xymon.invalid] Sent: Thursday, February 17, 2011 3:23 AM To: xymon at xymon.com Subject: Re: [xymon] RE: Alerts variables In <user-bdd7400d1b9a@xymon.invalid> "Nordquist, Daniel" <user-b7c65cb59f49@xymon.invalid> writes:
Can we apply this code to 4.2.3?
Already done. Regards, Henrik
-----Original Message----- From: Henrik St=C3=B8rner [mailto:user-ce4a2c883f75@xymon.invalid] Sent: Monday, February 14, 2011 7:40 AM To: xymon at xymon.com Subject: Re: [xymon] RE: Alerts variables
In <user-b954bdf70b7d@xymon.invalid>= =3D?iso-8859-1?Q?Johan_Sj=3DF6berg?=3D <user-74c177c1220d@xymon.invalid> = writes:
Yes, exactly. It is a script from Xymonton that is invoked using SCRIPT. S= o=3D I would like to know if any variable is passed to the script containing t= h=3D e status "disabled"
OK, this turned out to be a slightly larger change than I had anticipated. After testing things a bit, it dawned on me that neither the mail-messages nor the script-based alerts would be able to tell the difference between a genuine recovery (going "green") and a recovery due to the status being disabled.
Which doesn't seem right.
The patch below should solve this. For mail/SMS alerts the subject and message text has been changed from "recovered" to "disabled". For scripts this can be seen from the value of the RECOVERED variable - it will be "1" for a genuine recovery (unchanged from before) and "2" for a recover- by-disable.
The BBCOLORLEVEL setting remains unchanged, i.e. it will NOT be blue. This is because BBCOLORLEVEL holds the value of the color that triggered the alert - not the current color of the status.
Note: When you apply this patch (against 4.3.0-RC1), please run "make clean" and then "make" to build the package. Without the "make clean", some of the library modules will probably not get updated - causing weird results.
Regards, Henrik
Index: lib/loadalerts.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- lib/loadalerts.c (revision 6631)
+++ lib/loadalerts.c (working copy)
@@ -958,7 +958,7 @@
return result;
}- if (alert->state =3D=3D A_RECOVERED) {
+ if ((alert->state =3D=3D A_RECOVERED) || (alert->state =3D=3D A_DIS=
ABLED)) {
/*
* Dont do the check until we are checking individual recip=
ients (rulecrit is set).
* You dont need to have RECOVERED on the top-level rule, i=
t's enough if a recipient
Index: lib/loadalerts.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- lib/loadalerts.h (revision 6631)
+++ lib/loadalerts.h (working copy)
@@ -18,7 +18,7 @@
#if defined(LOCALCLIENT) || !defined(CLIENTONLY)
#include <pcre.h>-typedef enum { A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_NOTIFY, A_DEAD=
} astate_t;
+typedef enum { A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_DISABLED, A_NO=
TIFY, A_DEAD } astate_t;typedef struct activealerts_t {
/* Identification of the alert */
Index: xymond/xymond_alert.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- xymond/xymond_alert.c (revision 6631)
+++ xymond/xymond_alert.c (working copy)
@@ -75,8 +75,8 @@
activealerts_t *ahead =3D NULL;char *statename[] =3D {
- /* A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_NOTIFY, A_DEAD */
- "paging", "norecip", "acked", "recovered", "notify", "dead"
+ /* A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_DISABLED, A_NOTIFY,=
A_DEAD */
+ "paging", "norecip", "acked", "recovered", "disabled", "notify", "d=
ead"
};char *find_name(RbtHandle tree, char *name)
@@ -662,7 +662,7 @@
* Dont update the color here - we want rec=
overies to go out
* only if the alert color triggered an ale=
rt
*/
- awalk->state =3D A_RECOVERED;
+ awalk->state =3D (newcolor =3D=3D COL_BLUE)=
? A_DISABLED : A_RECOVERED;
} if (oldalertstatus !=3D newalertstatus) {
@@ -865,6 +865,7 @@
break; case A_RECOVERED:
+ case A_DISABLED:
case A_NOTIFY:
anytogo++;
break;
@@ -895,6 +896,7 @@
break; case A_RECOVERED:
+ case A_DISABLED:
case A_NOTIFY:
send_alert(awalk, notiflogf=
d);
break;
@@ -929,6 +931,7 @@
break; case A_RECOVERED:
+ case A_DISABLED:
case A_NOTIFY:
awalk->state =3D A_DEAD;
/* Fall through */
Index: xymond/do_alert.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- xymond/do_alert.c (revision 6631)
+++ xymond/do_alert.c (working copy)
@@ -225,6 +225,12 @@
alert->hostname, alert->testname, recip->cfid);
break;+ case A_DISABLED:
+ subjfmt =3D (include_configid ? "Xymon %s:%s disabled [cfid=
:%d]" : "Xymon %s:%s disabled");
+ snprintf(subj, sizeof(subj)-1, subjfmt,
+ alert->hostname, alert->testname, recip->cfid);
+ break;
• case A_NORECIP:
case A_DEAD:
/* Cannot happen */
@@ -310,6 +316,11 @@
alert->hostname, alert->testname);
break;+ case A_DISABLED:
+ sprintf(info, "%s:%s DISABLED",
+ alert->hostname, alert->testname);
+ break;
• case A_NOTIFY:
sprintf(info, "%s:%s NOTICE",
alert->hostname, alert->testname);
@@ -365,7 +376,7 @@
int first =3D 1;
int alertcount =3D 0;
time_t now =3D getcurrenttime(NULL);
- char *alerttxt[A_DEAD+1] =3D { "Paging", "Acked", "Recovered", "Not=
ify", "Dead" };
+ char *alerttxt[A_DEAD+1] =3D { "Paging", "Acked", "Recovered", "Dis=
abled", "Notify", "Dead" }; dbgprintf("send_alert %s:%s state %d\n", alert->hostname, alert->te=
stname, (int)alert->state);
traceprintf("send_alert %s:%s state %s\n",
@@ -380,7 +391,7 @@
continue;
}- if (recip->noalerts && ((alert->state =3D=3D A_PAGING) || (=
alert->state =3D=3D A_RECOVERED))) {
+ if (recip->noalerts && ((alert->state =3D=3D A_PAGING) || (=
alert->state =3D=3D A_RECOVERED) || (alert->state =3D=3D A_DISABLED))) {
traceprintf("Recipient '%s' dropped (NOALERT)\n", r=
ecip->recipient);
continue;
}
@@ -408,7 +419,7 @@
}
alertcount++;
}
- else if (alert->state =3D=3D A_RECOVERED) {
+ else if ((alert->state =3D=3D A_RECOVERED) || (alert->state=
=3D=3D A_DISABLED)) {
/* RECOVERED messages require that we've sent out a=
n alert before */
repeat_t *rpt =3D NULL;@@ -463,7 +474,7 @@
timestamp, alert->h=
ostname, alert->testname,
alert->ip, mailreci=
p, recip->cfid,
(long)now, servicec=
ode(alert->testname));
- if (alert->state =3D=3D A_R=
ECOVERED) {
+ if ((alert->state =3D=3D A_=
RECOVERED) || (alert->state =3D=3D A_DISABLED)) {
fprintf(logfd, " %l=
d\n", (long)(now - alert->eventstart));
}
else {
@@ -561,7 +572,17 @@
putenv(bbcolorlevel); recovered =3D (char *)malloc(strlen=
("RECOVERED=3D") + 2);
- sprintf(recovered, "RECOVERED=3D%d"=
, ((alert->state =3D=3D A_RECOVERED) ? 1 : 0));
+ switch (alert->state) {
+ case A_RECOVERED:
+ strcpy(recovered, "RECOVERE=
D=3D1");
+ break;
+ case A_DISABLED:
+ strcpy(recovered, "RECOVERE=
D=3D2");
+ break;
+ default:
+ strcpy(recovered, "RECOVERE=
D=3D0");
+ break;
+ }
putenv(recovered); downsecs =3D (char *)malloc(strlen(=
"DOWNSECS=3D") + 20);
@@ -572,7 +593,7 @@
sprintf(eventtstamp, "EVENTSTART=3D=
%ld", (long)alert->eventstart);
putenv(eventtstamp);- if (alert->state =3D=3D A_RECOVERED=
) {
+ if ((alert->state =3D=3D A_RECOVERE=
D) || (alert->state =3D=3D A_DISABLED)) {
downsecsmsg =3D (char *)mal=
loc(strlen("DOWNSECSMSG=3DEvent duration :") + 20);
sprintf(downsecsmsg, "DOWNS=
ECSMSG=3DEvent duration : %ld", (long)(getcurrenttime(NULL) - alert->events=
tart));
}
@@ -628,7 +649,7 @@
timestamp, alert->h=
ostname, alert->testname,
alert->ip, scriptre=
cip, (long)now,
servicecode(alert->=
testname));
- if (alert->state =3D=3D A_R=
ECOVERED) {
+ if ((alert->state =3D=3D A_=
RECOVERED) || (alert->state =3D=3D A_DISABLED)) {
fprintf(logfd, " %l=
d\n", (long)(now - alert->eventstart));
}
else {This e-mail message and any attached files are confidential and are intende= d solely for the use of the addressee(s) named above. If you are not the in= tended recipient, any review, use, or distribution of this e-mail message a= nd any attached files is strictly prohibited.
This communication may contain material protected by Federal privacy regula= tions, attorney-client work product, or other privileges. If you have recei= ved this confidential communication in error, please notify the sender imme= diately by reply e-mail message and permanently delete the original message= . To reply to our email administrator directly, send an email to: postmas= user-06e12ddf8aed@xymon.invalid .
If this e-mail message concerns a contract matter, be advised that no emplo= yee or agent is authorized to conclude any binding agreement on behalf of O= rlando Health by e-mail without express written confirmation by an officer = of the corporation. Any views or opinions presented in this e-mail are sole= ly those of the author and do not necessarily represent those of Orlando He= alth.
This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited. This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: user-40803320aaf5@xymon.invalid . If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health. This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited. This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: user-40803320aaf5@xymon.invalid . If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health.
list Henrik Størner
Hi Daniel,
▸
Den 21-02-2011 13:37, Nordquist, Daniel skrev:I apologize for my confusion, but I don't understand what you mean by this. In<user-bdd7400d1b9a@xymon.invalid> "Nordquist, Daniel"<user-b7c65cb59f49@xymon.invalid> writes:Can we apply this code to 4.2.3?Already done.
sorry - my mistake. I meant "it is already in 4.3.0", but your question was for the older 4.2.3 release. It won't fit into 4.2.3 without some changes. So you'll have to wait a few more days for a release of this. Regards, Henrik
list Daniel Nordquist
Henrik, I hope you're feeling better and recovering nicely from your surgery. I was wondering if you have in the works a new release with this code for the recovery alert variable? And, the code that patched the problem for the rbtree bug where the ack cookies are located by scanning the memory instead of the rbtree? Sounds like you discovered that the "delete node" code is buggy from that message thread. Please let me know if there will be a new release with these code changes or if I should pursue upgrading to 4.3.2 and then applying the patches. Thanks, Dan
▸
-----Original Message-----
From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of Henrik Størner
Sent: Monday, February 21, 2011 9:22 AM
To: xymon at xymon.com
Subject: Re: [Xymon] [xymon] RE: Alerts variables
Hi Daniel,
Den 21-02-2011 13:37, Nordquist, Daniel skrev:I apologize for my confusion, but I don't understand what you mean by this. In<user-bdd7400d1b9a@xymon.invalid> "Nordquist, Daniel"<user-b7c65cb59f49@xymon.invalid> writes:Can we apply this code to 4.2.3?Already done.
sorry - my mistake. I meant "it is already in 4.3.0", but your question was for the older 4.2.3 release. It won't fit into 4.2.3 without some changes. So you'll have to wait a few more days for a release of this. Regards, Henrik This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited. This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: user-40803320aaf5@xymon.invalid . If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health.
list Daniel Nordquist
Sorry if I'm being a pest and/or if I'm just not seeing something obvious. I do not see these two changes listed or documented anywhere in the 4.3.3 release (concerning the alert variable allowing a "blue" status, and the rbtree bug). Please respond.
▸
Thanks,
Dan
-----Original Message-----
From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of Nordquist, Daniel
Sent: Monday, May 16, 2011 1:43 PM
To: xymon at xymon.com
Subject: Re: [Xymon] [xymon] RE: Alerts variables
Henrik, I hope you're feeling better and recovering nicely from your surgery.
I was wondering if you have in the works a new release with this code for the recovery alert variable?
And, the code that patched the problem for the rbtree bug where the ack cookies are located by scanning the memory instead of the rbtree? Sounds like you discovered that the "delete node" code is buggy from that message thread.
Please let me know if there will be a new release with these code changes or if I should pursue upgrading to 4.3.2 and then applying the patches.
Thanks,
Dan
-----Original Message-----
From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of Henrik Størner
Sent: Monday, February 21, 2011 9:22 AM
To: xymon at xymon.com
Subject: Re: [Xymon] [xymon] RE: Alerts variables
Hi Daniel,
Den 21-02-2011 13:37, Nordquist, Daniel skrev:I apologize for my confusion, but I don't understand what you mean by this. In<user-bdd7400d1b9a@xymon.invalid> "Nordquist, Daniel"<user-b7c65cb59f49@xymon.invalid> writes:Can we apply this code to 4.2.3?Already done.
sorry - my mistake. I meant "it is already in 4.3.0", but your question was for the older 4.2.3 release. It won't fit into 4.2.3 without some changes. So you'll have to wait a few more days for a release of this. Regards, Henrik This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited. This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: user-40803320aaf5@xymon.invalid . If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health. This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited. This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: user-40803320aaf5@xymon.invalid . If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health.
list Johan Sjöberg
Hi. This change is in the 4.3.3 release (and also in 4.3.2, I think). I am using it myself. The $RECOVERED variable can be either 1 or 2. I don't know about the "rbtree bug". /Johan
▸
-----Original Message----- From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of Nordquist, Daniel
Sent: den 19 maj 2011 17:54
▸
To: xymon at xymon.com Subject: Re: [Xymon] [xymon] RE: Alerts variables Sorry if I'm being a pest and/or if I'm just not seeing something obvious. I do not see these two changes listed or documented anywhere in the 4.3.3 release (concerning the alert variable allowing a "blue" status, and the rbtree bug). Please respond. Thanks, Dan -----Original Message----- From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of Nordquist, Daniel Sent: Monday, May 16, 2011 1:43 PM To: xymon at xymon.com Subject: Re: [Xymon] [xymon] RE: Alerts variables Henrik, I hope you're feeling better and recovering nicely from your surgery. I was wondering if you have in the works a new release with this code for the recovery alert variable? And, the code that patched the problem for the rbtree bug where the ack cookies are located by scanning the memory instead of the rbtree? Sounds like you discovered that the "delete node" code is buggy from that message thread. Please let me know if there will be a new release with these code changes or if I should pursue upgrading to 4.3.2 and then applying the patches. Thanks, Dan -----Original Message----- From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of Henrik Størner Sent: Monday, February 21, 2011 9:22 AM To: xymon at xymon.com Subject: Re: [Xymon] [xymon] RE: Alerts variables Hi Daniel, Den 21-02-2011 13:37, Nordquist, Daniel skrev:I apologize for my confusion, but I don't understand what you mean by this. In<user-bdd7400d1b9a@xymon.invalid>"Nordquist, Daniel"<user-b7c65cb59f49@xymon.invalid> writes:Can we apply this code to 4.2.3?Already done.sorry - my mistake. I meant "it is already in 4.3.0", but your question was for the older 4.2.3 release. It won't fit into 4.2.3 without some changes. So you'll have to wait a few more days for a release of this. Regards, Henrik This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited. This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: user-40803320aaf5@xymon.invalid . If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health. This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited. This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: user-40803320aaf5@xymon.invalid . If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health.
list Henrik Størner
▸
Sorry if I'm being a pest and/or if I'm just not seeing something obvious. I do not see these two changes listed or documented anywhere in the 4.3.3 release (concerning the alert variable allowing a "blue" status, and the rbtree bug).
The code for the blue status was added for the 4.3.0 release, and is present in all 4.3.x releases. I won't update 4.2.x versions. The ack cookie workaround hasn't been merged yet. I might add this as an interim solution for 4.3.4, but the real solution is probably going to involve replacing the rbtree code currently in Xymon with the libredblack library from the GNU project. That is a bit more drastic, so will need some more time to implement. Regards, Henrik
list Daniel Nordquist
Thanks! -----Original Message----- From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of Henrik Størner Sent: Thursday, May 19, 2011 12:02 PM To: xymon at xymon.com Subject: Re: [Xymon] [xymon] RE: Alerts variables
Sorry if I'm being a pest and/or if I'm just not seeing something obvious. I do not see these two changes listed or documented anywhere in the 4.3.3 release (concerning the alert variable allowing a "blue" status, and the rbtree bug).
The code for the blue status was added for the 4.3.0 release, and is present in all 4.3.x releases. I won't update 4.2.x versions. The ack cookie workaround hasn't been merged yet. I might add this as an interim solution for 4.3.4, but the real solution is probably going to involve replacing the rbtree code currently in Xymon with the libredblack library from the GNU project. That is a bit more drastic, so will need some more time to implement. Regards, Henrik This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited. This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: user-40803320aaf5@xymon.invalid . If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health.