Notification Issues
list KC Kuhns
Good morning, We're using Xymon 4.3.25 and are running into a strange issue. We use Armor to monitor servers and various things at all of our clients. Our host file is setup something like this: Page User1 User One Subpage Client1 Client One 8.8.8.8 DC.Google # NOCONN Page User2 User Two Subpage Client2 Client Two 75.75.75.75 DC.Comcast # NOCONN Each technician that we have has a page, and each client has its own subpage under the related technician. We often move clients around to different technicians so in the above example, we may decide to move Client2 to User1. When we do that, it seems that User2 still receives email alerts for DC.Comcast even though it has been moved under User1. When looking at the info tab for DC2, it would show only User1 and nothing tied to User2. There's also nothing relating to that client in the alerts file. Is there some type of cache that we need to clear when we move clients around to different technicians to prevent this? Appreciate the help.
list Paul Root
You can use xymond_alert to test the alert system to see where it is sending. xymond_alert --test DC.Comcast procs --duration=500 |grep -v Failed
▸
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of KC Kuhns
Sent: Wednesday, October 11, 2017 9:27 AM
To: xymon at xymon.com
Subject: [Xymon] Notification Issues
Good morning,
We're using Xymon 4.3.25 and are running into a strange issue. We use Armor to monitor servers and various things at all of our clients. Our host file is setup something like this:
Page User1 User One
Subpage Client1 Client One
8.8.8.8 DC.Google # NOCONN
Page User2 User Two
Subpage Client2 Client Two
75.75.75.75 DC.Comcast # NOCONN
Each technician that we have has a page, and each client has its own subpage under the related technician. We often move clients around to different technicians so in the above example, we may decide to move Client2 to User1. When we do that, it seems that User2 still receives email alerts for DC.Comcast even though it has been moved under User1. When looking at the info tab for DC2, it would show only User1 and nothing tied to User2. There's also nothing relating to that client in the alerts file.
Is there some type of cache that we need to clear when we move clients around to different technicians to prevent this? Appreciate the help.
This communication is the property of CenturyLink 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 John Tullis
I've worked with KC on this issue for some time now and still have had no success.
This is the result we're getting when we test with xymond_alert.
$ xymond_alert --test DC.Comcast disk --duration=500
00007222 2017-10-11 11:46:08 Matching host:service:dgroup:page ''DC.Comcast:disk:NONE: User2/Client2' against rule line 1
00007222 2017-10-11 11:46:08 Failed 'PAGE=%.*User1/' (pagename not in include list)
00007222 2017-10-11 11:46:08 Matching host:service:dgroup:page 'DC.Comcast:disk:NONE:User2/Client2' against rule line 3
00007222 2017-10-11 11:46:08 *** Match with 'PAGE=%.*User2/' ***
00007222 2017-10-11 11:46:08 Matching host:service:dgroup:page 'DC.Comcast:disk:NONE: User2/Client2' against rule line 4
00007222 2017-10-11 11:46:08 *** Match with 'SCRIPT=/etc/xymon/custom/alert.sh user-6109888833b7@xymon.invalid COLOR=red,yellow RECOVERED REPEAT=720 DURATION>10' ***
00007222 2017-10-11 11:46:08 Script alert with command '/etc/xymon/custom/alert.sh' and recipient user-6109888833b7@xymon.invalid
This is a sample of alerts.cfg:
PAGE=%.*User1/
SCRIPT=/etc/xymon/alerts/alert.sh user-e2c0c4f8a224@xymon.invalid COLOR=red,yellow RECOVERED REPEAT=720 DURATION>10
PAGE=%.*User2/
SCRIPT=/etc/xymon/custom-alerts/alert.sh user-6109888833b7@xymon.invalid COLOR=red,yellow RECOVERED REPEAT=720 DURATION>10
User2 matches correctly but the email is still going to User1 even though we get a failed message for User1. We've tried deleting the User1 folder in the www folder. Restarting Xymon and the entire server and it doesn't ever really seem to go away. I can see that the emails were sent in the logs. I also added the matching line number to the alert email using $CFID and the matching line points to line 1 for User1.
Any more help would be appreciated.
Thanks, John.
▸
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Root, Paul T
Sent: Wednesday, October 11, 2017 10:22 AM
To: KC Kuhns <user-bbc3ee989f1c@xymon.invalid>; xymon at xymon.com
Subject: Re: [Xymon] Notification Issues
You can use xymond_alert to test the alert system to see where it is sending.
xymond_alert --test DC.Comcast procs --duration=500 |grep -v Failed
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of KC Kuhns
Sent: Wednesday, October 11, 2017 9:27 AM
To: xymon at xymon.com<mailto:xymon at xymon.com>
Subject: [Xymon] Notification Issues
Good morning,
We're using Xymon 4.3.25 and are running into a strange issue. We use Armor to monitor servers and various things at all of our clients. Our host file is setup something like this:
Page User1 User One
Subpage Client1 Client One
8.8.8.8 DC.Google # NOCONN
Page User2 User Two
Subpage Client2 Client Two
75.75.75.75 DC.Comcast # NOCONN
Each technician that we have has a page, and each client has its own subpage under the related technician. We often move clients around to different technicians so in the above example, we may decide to move Client2 to User1. When we do that, it seems that User2 still receives email alerts for DC.Comcast even though it has been moved under User1. When looking at the info tab for DC2, it would show only User1 and nothing tied to User2. There's also nothing relating to that client in the alerts file.
Is there some type of cache that we need to clear when we move clients around to different technicians to prevent this? Appreciate the help.
This communication is the property of CenturyLink 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 Paul Root
And notifications.log says that it is running /etc/xymon/custom/alert.sh user-6109888833b7@xymon.invalid? I'd look in /etc/xymon/custom/alert.sh then.
▸
From: John Tullis [mailto:user-a6bbfd057f07@xymon.invalid]
Sent: Wednesday, October 11, 2017 1:52 PM
To: Root, Paul T; KC Kuhns; xymon at xymon.com
Subject: RE: Notification Issues
I've worked with KC on this issue for some time now and still have had no success.
This is the result we're getting when we test with xymond_alert.
$ xymond_alert --test DC.Comcast disk --duration=500
00007222 2017-10-11 11:46:08 Matching host:service:dgroup:page ''DC.Comcast:disk:NONE: User2/Client2' against rule line 1
00007222 2017-10-11 11:46:08 Failed 'PAGE=%.*User1/' (pagename not in include list)
00007222 2017-10-11 11:46:08 Matching host:service:dgroup:page 'DC.Comcast:disk:NONE:User2/Client2' against rule line 3
00007222 2017-10-11 11:46:08 *** Match with 'PAGE=%.*User2/' ***
00007222 2017-10-11 11:46:08 Matching host:service:dgroup:page 'DC.Comcast:disk:NONE: User2/Client2' against rule line 4
00007222 2017-10-11 11:46:08 *** Match with 'SCRIPT=/etc/xymon/custom/alert.sh user-6109888833b7@xymon.invalid<mailto:user-6109888833b7@xymon.invalid> COLOR=red,yellow RECOVERED REPEAT=720 DURATION>10' ***
00007222 2017-10-11 11:46:08 Script alert with command '/etc/xymon/custom/alert.sh' and recipient user-6109888833b7@xymon.invalid<mailto:user-6109888833b7@xymon.invalid>
This is a sample of alerts.cfg:
PAGE=%.*User1/
SCRIPT=/etc/xymon/alerts/alert.sh user-e2c0c4f8a224@xymon.invalid<mailto:user-e2c0c4f8a224@xymon.invalid> COLOR=red,yellow RECOVERED REPEAT=720 DURATION>10
PAGE=%.*User2/
SCRIPT=/etc/xymon/custom-alerts/alert.sh user-6109888833b7@xymon.invalid<mailto:user-6109888833b7@xymon.invalid> COLOR=red,yellow RECOVERED REPEAT=720 DURATION>10
▸
User2 matches correctly but the email is still going to User1 even though we get a failed message for User1. We've tried deleting the User1 folder in the www folder. Restarting Xymon and the entire server and it doesn't ever really seem to go away. I can see that the emails were sent in the logs. I also added the matching line number to the alert email using $CFID and the matching line points to line 1 for User1.
Any more help would be appreciated.
Thanks, John.
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Root, Paul T
Sent: Wednesday, October 11, 2017 10:22 AM
To: KC Kuhns <user-bbc3ee989f1c@xymon.invalid<mailto:user-bbc3ee989f1c@xymon.invalid>>; xymon at xymon.com<mailto:xymon at xymon.com>
Subject: Re: [Xymon] Notification Issues
You can use xymond_alert to test the alert system to see where it is sending.
xymond_alert --test DC.Comcast procs --duration=500 |grep -v Failed
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of KC Kuhns
Sent: Wednesday, October 11, 2017 9:27 AM
To: xymon at xymon.com<mailto:xymon at xymon.com>
Subject: [Xymon] Notification Issues
Good morning,
We're using Xymon 4.3.25 and are running into a strange issue. We use Armor to monitor servers and various things at all of our clients. Our host file is setup something like this:
Page User1 User One
Subpage Client1 Client One
8.8.8.8 DC.Google # NOCONN
Page User2 User Two
Subpage Client2 Client Two
75.75.75.75 DC.Comcast # NOCONN
Each technician that we have has a page, and each client has its own subpage under the related technician. We often move clients around to different technicians so in the above example, we may decide to move Client2 to User1. When we do that, it seems that User2 still receives email alerts for DC.Comcast even though it has been moved under User1. When looking at the info tab for DC2, it would show only User1 and nothing tied to User2. There's also nothing relating to that client in the alerts file.
Is there some type of cache that we need to clear when we move clients around to different technicians to prevent this? Appreciate the help.
This communication is the property of CenturyLink 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.
This communication is the property of CenturyLink 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 John Tullis
This is the content of alert.sh. There isn't anything in here that will act on its own. It will only run when called and that's what we can't figure out, what is calling it?
$ cat alert.sh
#!/bin/sh
n=$RECOVERED
if test $n -eq 0
then
<br />
Here are the details of your problem:
<br />
<pre>
$BBALPHAMSG
</pre>
<br />
<font color="white">$CFID</font>
<br />
Please log onto $BBHOSTNAME and check the $BBSVCNAME." | mail -a "Content-type: text/html;" -s "ALERT: $BBHOSTSVC is $BBCOLORLEVEL" --append=FROM:"Xymon Monitor <user-5b6031c6dfca@xymon.invalid>" $RCPT
else
<br />
$BBSVCNAME on $BBHOSTNAME has recovered.
<br />
<pre>
$BBALPHAMSG
</pre>
<br />
<font color="white">$CFID</font>
<br />
$BBSVCNAME on $BBHOSTNAME has recovered." | mail -a "Content-type: text/html;" -s "NOTE:$BBSVCNAME on $BBHOSTNAME recovered" --append=FROM:"Xymon Monitor <user-5b6031c6dfca@xymon.invalid>" $RCPT
fi
John Tullis
From: Root, Paul T [mailto:user-76fdb6883669@xymon.invalid]
Sent: Wednesday, October 11, 2017 12:57 PM
To: John Tullis <user-a6bbfd057f07@xymon.invalid>; KC Kuhns <user-bbc3ee989f1c@xymon.invalid>; xymon at xymon.com
Subject: RE: Notification Issues
And notifications.log says that it is running /etc/xymon/custom/alert.sh user-6109888833b7@xymon.invalid<mailto:user-6109888833b7@xymon.invalid>?
▸
I'd look in /etc/xymon/custom/alert.sh then.
From: John Tullis [mailto:user-a6bbfd057f07@xymon.invalid]
Sent: Wednesday, October 11, 2017 1:52 PM
To: Root, Paul T; KC Kuhns; xymon at xymon.com<mailto:xymon at xymon.com>
Subject: RE: Notification Issues
I've worked with KC on this issue for some time now and still have had no success.
This is the result we're getting when we test with xymond_alert.
$ xymond_alert --test DC.Comcast disk --duration=500
00007222 2017-10-11 11:46:08 Matching host:service:dgroup:page ''DC.Comcast:disk:NONE: User2/Client2' against rule line 1
00007222 2017-10-11 11:46:08 Failed 'PAGE=%.*User1/' (pagename not in include list)
00007222 2017-10-11 11:46:08 Matching host:service:dgroup:page 'DC.Comcast:disk:NONE:User2/Client2' against rule line 3
00007222 2017-10-11 11:46:08 *** Match with 'PAGE=%.*User2/' ***
00007222 2017-10-11 11:46:08 Matching host:service:dgroup:page 'DC.Comcast:disk:NONE: User2/Client2' against rule line 4
00007222 2017-10-11 11:46:08 *** Match with 'SCRIPT=/etc/xymon/custom/alert.sh user-6109888833b7@xymon.invalid<mailto:user-6109888833b7@xymon.invalid> COLOR=red,yellow RECOVERED REPEAT=720 DURATION>10' ***
00007222 2017-10-11 11:46:08 Script alert with command '/etc/xymon/custom/alert.sh' and recipient user-6109888833b7@xymon.invalid<mailto:user-6109888833b7@xymon.invalid>
This is a sample of alerts.cfg:
PAGE=%.*User1/
SCRIPT=/etc/xymon/alerts/alert.sh user-e2c0c4f8a224@xymon.invalid<mailto:user-e2c0c4f8a224@xymon.invalid> COLOR=red,yellow RECOVERED REPEAT=720 DURATION>10
PAGE=%.*User2/
SCRIPT=/etc/xymon/custom-alerts/alert.sh user-6109888833b7@xymon.invalid<mailto:user-6109888833b7@xymon.invalid> COLOR=red,yellow RECOVERED REPEAT=720 DURATION>10
User2 matches correctly but the email is still going to User1 even though we get a failed message for User1. We've tried deleting the User1 folder in the www folder. Restarting Xymon and the entire server and it doesn't ever really seem to go away. I can see that the emails were sent in the logs. I also added the matching line number to the alert email using $CFID and the matching line points to line 1 for User1.
Any more help would be appreciated.
Thanks, John.
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Root, Paul T
Sent: Wednesday, October 11, 2017 10:22 AM
To: KC Kuhns <user-bbc3ee989f1c@xymon.invalid<mailto:user-bbc3ee989f1c@xymon.invalid>>; xymon at xymon.com<mailto:xymon at xymon.com>
Subject: Re: [Xymon] Notification Issues
You can use xymond_alert to test the alert system to see where it is sending.
xymond_alert --test DC.Comcast procs --duration=500 |grep -v Failed
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of KC Kuhns
Sent: Wednesday, October 11, 2017 9:27 AM
To: xymon at xymon.com<mailto:xymon at xymon.com>
Subject: [Xymon] Notification Issues
Good morning,
We're using Xymon 4.3.25 and are running into a strange issue. We use Armor to monitor servers and various things at all of our clients. Our host file is setup something like this:
Page User1 User One
Subpage Client1 Client One
8.8.8.8 DC.Google # NOCONN
Page User2 User Two
Subpage Client2 Client Two
75.75.75.75 DC.Comcast # NOCONN
Each technician that we have has a page, and each client has its own subpage under the related technician. We often move clients around to different technicians so in the above example, we may decide to move Client2 to User1. When we do that, it seems that User2 still receives email alerts for DC.Comcast even though it has been moved under User1. When looking at the info tab for DC2, it would show only User1 and nothing tied to User2. There's also nothing relating to that client in the alerts file.
Is there some type of cache that we need to clear when we move clients around to different technicians to prevent this? Appreciate the help.
This communication is the property of CenturyLink 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.
This communication is the property of CenturyLink 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 Paul Root
Have you verified that $RCPT is correct? Have you checked mail.log to see who it's sending too. I'd add a line to echo into a log file the pertinent data.
▸
From: John Tullis [mailto:user-a6bbfd057f07@xymon.invalid]
Sent: Wednesday, October 11, 2017 5:32 PM
To: Root, Paul T; KC Kuhns; xymon at xymon.com
Subject: RE: Notification Issues
This is the content of alert.sh. There isn't anything in here that will act on its own. It will only run when called and that's what we can't figure out, what is calling it?
$ cat alert.sh
#!/bin/sh
n=$RECOVERED
if test $n -eq 0
then
<br />
Here are the details of your problem:
<br />
<pre>
$BBALPHAMSG
</pre>
<br />
<font color="white">$CFID</font>
<br />
Please log onto $BBHOSTNAME and check the $BBSVCNAME." | mail -a "Content-type: text/html;" -s "ALERT: $BBHOSTSVC is $BBCOLORLEVEL" --append=FROM:"Xymon Monitor <user-5b6031c6dfca@xymon.invalid<mailto:user-5b6031c6dfca@xymon.invalid>>" $RCPT
▸
else
<br />
$BBSVCNAME on $BBHOSTNAME has recovered.
<br />
<pre>
$BBALPHAMSG
</pre>
<br />
<font color="white">$CFID</font>
<br />
$BBSVCNAME on $BBHOSTNAME has recovered." | mail -a "Content-type: text/html;" -s "NOTE:$BBSVCNAME on $BBHOSTNAME recovered" --append=FROM:"Xymon Monitor <user-5b6031c6dfca@xymon.invalid<mailto:user-5b6031c6dfca@xymon.invalid>>" $RCPT
▸
fi
John Tullis
From: Root, Paul T [mailto:user-76fdb6883669@xymon.invalid]
Sent: Wednesday, October 11, 2017 12:57 PM
To: John Tullis <user-a6bbfd057f07@xymon.invalid<mailto:user-a6bbfd057f07@xymon.invalid>>; KC Kuhns <user-bbc3ee989f1c@xymon.invalid<mailto:user-bbc3ee989f1c@xymon.invalid>>; xymon at xymon.com<mailto:xymon at xymon.com>
Subject: RE: Notification Issues
And notifications.log says that it is running /etc/xymon/custom/alert.sh user-6109888833b7@xymon.invalid<mailto:user-6109888833b7@xymon.invalid>?
I'd look in /etc/xymon/custom/alert.sh then.
From: John Tullis [mailto:user-a6bbfd057f07@xymon.invalid]
Sent: Wednesday, October 11, 2017 1:52 PM
To: Root, Paul T; KC Kuhns; xymon at xymon.com<mailto:xymon at xymon.com>
Subject: RE: Notification Issues
I've worked with KC on this issue for some time now and still have had no success.
This is the result we're getting when we test with xymond_alert.
$ xymond_alert --test DC.Comcast disk --duration=500
00007222 2017-10-11 11:46:08 Matching host:service:dgroup:page ''DC.Comcast:disk:NONE: User2/Client2' against rule line 1
00007222 2017-10-11 11:46:08 Failed 'PAGE=%.*User1/' (pagename not in include list)
00007222 2017-10-11 11:46:08 Matching host:service:dgroup:page 'DC.Comcast:disk:NONE:User2/Client2' against rule line 3
00007222 2017-10-11 11:46:08 *** Match with 'PAGE=%.*User2/' ***
00007222 2017-10-11 11:46:08 Matching host:service:dgroup:page 'DC.Comcast:disk:NONE: User2/Client2' against rule line 4
00007222 2017-10-11 11:46:08 *** Match with 'SCRIPT=/etc/xymon/custom/alert.sh user-6109888833b7@xymon.invalid<mailto:user-6109888833b7@xymon.invalid> COLOR=red,yellow RECOVERED REPEAT=720 DURATION>10' ***
00007222 2017-10-11 11:46:08 Script alert with command '/etc/xymon/custom/alert.sh' and recipient user-6109888833b7@xymon.invalid<mailto:user-6109888833b7@xymon.invalid>
This is a sample of alerts.cfg:
PAGE=%.*User1/
SCRIPT=/etc/xymon/alerts/alert.sh user-e2c0c4f8a224@xymon.invalid<mailto:user-e2c0c4f8a224@xymon.invalid> COLOR=red,yellow RECOVERED REPEAT=720 DURATION>10
PAGE=%.*User2/
SCRIPT=/etc/xymon/custom-alerts/alert.sh user-6109888833b7@xymon.invalid<mailto:user-6109888833b7@xymon.invalid> COLOR=red,yellow RECOVERED REPEAT=720 DURATION>10
User2 matches correctly but the email is still going to User1 even though we get a failed message for User1. We've tried deleting the User1 folder in the www folder. Restarting Xymon and the entire server and it doesn't ever really seem to go away. I can see that the emails were sent in the logs. I also added the matching line number to the alert email using $CFID and the matching line points to line 1 for User1.
Any more help would be appreciated.
Thanks, John.
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Root, Paul T
Sent: Wednesday, October 11, 2017 10:22 AM
To: KC Kuhns <user-bbc3ee989f1c@xymon.invalid<mailto:user-bbc3ee989f1c@xymon.invalid>>; xymon at xymon.com<mailto:xymon at xymon.com>
Subject: Re: [Xymon] Notification Issues
You can use xymond_alert to test the alert system to see where it is sending.
xymond_alert --test DC.Comcast procs --duration=500 |grep -v Failed
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of KC Kuhns
Sent: Wednesday, October 11, 2017 9:27 AM
To: xymon at xymon.com<mailto:xymon at xymon.com>
Subject: [Xymon] Notification Issues
Good morning,
We're using Xymon 4.3.25 and are running into a strange issue. We use Armor to monitor servers and various things at all of our clients. Our host file is setup something like this:
Page User1 User One
Subpage Client1 Client One
8.8.8.8 DC.Google # NOCONN
Page User2 User Two
Subpage Client2 Client Two
75.75.75.75 DC.Comcast # NOCONN
Each technician that we have has a page, and each client has its own subpage under the related technician. We often move clients around to different technicians so in the above example, we may decide to move Client2 to User1. When we do that, it seems that User2 still receives email alerts for DC.Comcast even though it has been moved under User1. When looking at the info tab for DC2, it would show only User1 and nothing tied to User2. There's also nothing relating to that client in the alerts file.
Is there some type of cache that we need to clear when we move clients around to different technicians to prevent this? Appreciate the help.
This communication is the property of CenturyLink 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.
This communication is the property of CenturyLink 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.
This communication is the property of CenturyLink 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 John Tullis
I changed the rule to be the default rule and see if it made a difference and the alerts are still coming but now shows the out of the box email message instead of the custom message.
PAGE=%.*User1/
MAIL user-e2c0c4f8a224@xymon.invalid COLOR=red,yellow RECOVERED REPEAT=720 DURATION>10
I'm fairly convinced that it's a bug. It only happens when we move the assignment from one user to another. There is no indication the the alert is still configured to go to the first user but something tells it to. Is there extended logging we can turn on or extra tracing that would give us a more in depth look?
The strange thing for me is that it's happened for a long time and has even persisted through an upgrade and server migration.
-----Original Message-----
From: Root, Paul T [user-76fdb6883669@xymon.invalid]
Received: Wednesday, 11 Oct 2017, 8:17PM
▸
To: John Tullis [user-a6bbfd057f07@xymon.invalid]; KC Kuhns [user-bbc3ee989f1c@xymon.invalid]; xymon at xymon.com [xymon at xymon.com]
Subject: RE: Notification Issues
Have you verified that $RCPT is correct?
Have you checked mail.log to see who it’s sending too.
I’d add a line to echo into a log file the pertinent data.
From: John Tullis [mailto:user-a6bbfd057f07@xymon.invalid]
Sent: Wednesday, October 11, 2017 5:32 PM
To: Root, Paul T; KC Kuhns; xymon at xymon.com
Subject: RE: Notification Issues
This is the content of alert.sh. There isn’t anything in here that will act on its own. It will only run when called and that’s what we can’t figure out, what is calling it?
$ cat alert.sh
#!/bin/sh
n=$RECOVERED
if test $n -eq 0
then
<br />
Here are the details of your problem:
<br />
<pre>
$BBALPHAMSG
</pre>
<br />
<font color="white">$CFID</font>
<br />
Please log onto $BBHOSTNAME and check the $BBSVCNAME." | mail -a "Content-type: text/html;" -s "ALERT: $BBHOSTSVC is $BBCOLORLEVEL" --append=FROM:"Xymon Monitor <user-5b6031c6dfca@xymon.invalid<mailto:user-5b6031c6dfca@xymon.invalid>>" $RCPT
else
<br />
$BBSVCNAME on $BBHOSTNAME has recovered.
<br />
<pre>
$BBALPHAMSG
</pre>
<br />
<font color="white">$CFID</font>
<br />
$BBSVCNAME on $BBHOSTNAME has recovered." | mail -a "Content-type: text/html;" -s "NOTE:$BBSVCNAME on $BBHOSTNAME recovered" --append=FROM:"Xymon Monitor <user-5b6031c6dfca@xymon.invalid<mailto:user-5b6031c6dfca@xymon.invalid>>" $RCPT
fi
John Tullis
From: Root, Paul T [mailto:user-76fdb6883669@xymon.invalid]
Sent: Wednesday, October 11, 2017 12:57 PM
To: John Tullis <user-a6bbfd057f07@xymon.invalid<mailto:user-a6bbfd057f07@xymon.invalid>>; KC Kuhns <user-bbc3ee989f1c@xymon.invalid<mailto:user-bbc3ee989f1c@xymon.invalid>>; xymon at xymon.com<mailto:xymon at xymon.com>
Subject: RE: Notification Issues
And notifications.log says that it is running /etc/xymon/custom/alert.sh user-6109888833b7@xymon.invalid<mailto:user-6109888833b7@xymon.invalid>?
I’d look in /etc/xymon/custom/alert.sh then.
From: John Tullis [mailto:user-a6bbfd057f07@xymon.invalid]
Sent: Wednesday, October 11, 2017 1:52 PM
To: Root, Paul T; KC Kuhns; xymon at xymon.com<mailto:xymon at xymon.com>
Subject: RE: Notification Issues
I’ve worked with KC on this issue for some time now and still have had no success.
This is the result we’re getting when we test with xymond_alert.
$ xymond_alert --test DC.Comcast disk --duration=500
00007222 2017-10-11 11:46:08 Matching host:service:dgroup:page ''DC.Comcast:disk:NONE: User2/Client2' against rule line 1
00007222 2017-10-11 11:46:08 Failed 'PAGE=%.*User1/' (pagename not in include list)
00007222 2017-10-11 11:46:08 Matching host:service:dgroup:page 'DC.Comcast:disk:NONE:User2/Client2' against rule line 3
00007222 2017-10-11 11:46:08 *** Match with 'PAGE=%.*User2/' ***
00007222 2017-10-11 11:46:08 Matching host:service:dgroup:page 'DC.Comcast:disk:NONE: User2/Client2' against rule line 4
00007222 2017-10-11 11:46:08 *** Match with 'SCRIPT=/etc/xymon/custom/alert.sh user-6109888833b7@xymon.invalid<mailto:user-6109888833b7@xymon.invalid> COLOR=red,yellow RECOVERED REPEAT=720 DURATION>10' ***
00007222 2017-10-11 11:46:08 Script alert with command '/etc/xymon/custom/alert.sh' and recipient user-6109888833b7@xymon.invalid<mailto:user-6109888833b7@xymon.invalid>
This is a sample of alerts.cfg:
PAGE=%.*User1/
SCRIPT=/etc/xymon/alerts/alert.sh user-e2c0c4f8a224@xymon.invalid<mailto:user-e2c0c4f8a224@xymon.invalid> COLOR=red,yellow RECOVERED REPEAT=720 DURATION>10
PAGE=%.*User2/
SCRIPT=/etc/xymon/custom-alerts/alert.sh user-6109888833b7@xymon.invalid<mailto:user-6109888833b7@xymon.invalid> COLOR=red,yellow RECOVERED REPEAT=720 DURATION>10
User2 matches correctly but the email is still going to User1 even though we get a failed message for User1. We’ve tried deleting the User1 folder in the www folder. Restarting Xymon and the entire server and it doesn’t ever really seem to go away. I can see that the emails were sent in the logs. I also added the matching line number to the alert email using $CFID and the matching line points to line 1 for User1.
Any more help would be appreciated.
Thanks, John.
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Root, Paul T
Sent: Wednesday, October 11, 2017 10:22 AM
To: KC Kuhns <user-bbc3ee989f1c@xymon.invalid<mailto:user-bbc3ee989f1c@xymon.invalid>>; xymon at xymon.com<mailto:xymon at xymon.com>
Subject: Re: [Xymon] Notification Issues
You can use xymond_alert to test the alert system to see where it is sending.
xymond_alert --test DC.Comcast procs --duration=500 |grep -v Failed
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of KC Kuhns
Sent: Wednesday, October 11, 2017 9:27 AM
To: xymon at xymon.com<mailto:xymon at xymon.com>
Subject: [Xymon] Notification Issues
Good morning,
We’re using Xymon 4.3.25 and are running into a strange issue. We use Armor to monitor servers and various things at all of our clients. Our host file is setup something like this:
Page User1 User One
Subpage Client1 Client One
8.8.8.8 DC.Google # NOCONN
Page User2 User Two
Subpage Client2 Client Two
75.75.75.75 DC.Comcast # NOCONN
Each technician that we have has a page, and each client has its own subpage under the related technician. We often move clients around to different technicians so in the above example, we may decide to move Client2 to User1. When we do that, it seems that User2 still receives email alerts for DC.Comcast even though it has been moved under User1. When looking at the info tab for DC2, it would show only User1 and nothing tied to User2. There’s also nothing relating to that client in the alerts file.
Is there some type of cache that we need to clear when we move clients around to different technicians to prevent this? Appreciate the help.
This communication is the property of CenturyLink 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.
This communication is the property of CenturyLink 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.
This communication is the property of CenturyLink 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 John Tullis
Any help on this would be greatly appreciated. I'm getting more reports that this is an issue. -----Original Message----- From: John Tullis [user-a6bbfd057f07@xymon.invalid] Received: Saturday, 14 Oct 2017, 7:01PM To: xymon at xymon.com [xymon at xymon.com]; user-76fdb6883669@xymon.invalid [user-76fdb6883669@xymon.invalid]; KC Kuhns [user-bbc3ee989f1c@xymon.invalid] Subject: RE: Notification Issues
▸
I changed the rule to be the default rule and see if it made a difference and the alerts are still coming but now shows the out of the box email message instead of the custom message.
PAGE=%.*User1/
MAIL user-e2c0c4f8a224@xymon.invalid COLOR=red,yellow RECOVERED REPEAT=720 DURATION>10
I'm fairly convinced that it's a bug. It only happens when we move the assignment from one user to another. There is no indication the the alert is still configured to go to the first user but something tells it to. Is there extended logging we can turn on or extra tracing that would give us a more in depth look?
The strange thing for me is that it's happened for a long time and has even persisted through an upgrade and server migration.
-----Original Message-----
From: Root, Paul T [user-76fdb6883669@xymon.invalid]
Received: Wednesday, 11 Oct 2017, 8:17PM
To: John Tullis [user-a6bbfd057f07@xymon.invalid]; KC Kuhns [user-bbc3ee989f1c@xymon.invalid]; xymon at xymon.com [xymon at xymon.com]
Subject: RE: Notification Issues
Have you verified that $RCPT is correct?
Have you checked mail.log to see who it’s sending too.
I’d add a line to echo into a log file the pertinent data.
From: John Tullis [mailto:user-a6bbfd057f07@xymon.invalid]
Sent: Wednesday, October 11, 2017 5:32 PM
To: Root, Paul T; KC Kuhns; xymon at xymon.com
Subject: RE: Notification Issues
This is the content of alert.sh. There isn’t anything in here that will act on its own. It will only run when called and that’s what we can’t figure out, what is calling it?
$ cat alert.sh
#!/bin/sh
n=$RECOVERED
if test $n -eq 0
then
<br />
Here are the details of your problem:
<br />
<pre>
$BBALPHAMSG
</pre>
<br />
<font color="white">$CFID</font>
<br />
Please log onto $BBHOSTNAME and check the $BBSVCNAME." | mail -a "Content-type: text/html;" -s "ALERT: $BBHOSTSVC is $BBCOLORLEVEL" --append=FROM:"Xymon Monitor <user-5b6031c6dfca@xymon.invalid<mailto:user-5b6031c6dfca@xymon.invalid>>" $RCPT
else
<br />
$BBSVCNAME on $BBHOSTNAME has recovered.
<br />
<pre>
$BBALPHAMSG
</pre>
<br />
<font color="white">$CFID</font>
<br />
$BBSVCNAME on $BBHOSTNAME has recovered." | mail -a "Content-type: text/html;" -s "NOTE:$BBSVCNAME on $BBHOSTNAME recovered" --append=FROM:"Xymon Monitor <user-5b6031c6dfca@xymon.invalid<mailto:user-5b6031c6dfca@xymon.invalid>>" $RCPT
fi
John Tullis
From: Root, Paul T [mailto:user-76fdb6883669@xymon.invalid]
Sent: Wednesday, October 11, 2017 12:57 PM
To: John Tullis <user-a6bbfd057f07@xymon.invalid<mailto:user-a6bbfd057f07@xymon.invalid>>; KC Kuhns <user-bbc3ee989f1c@xymon.invalid<mailto:user-bbc3ee989f1c@xymon.invalid>>; xymon at xymon.com<mailto:xymon at xymon.com>
Subject: RE: Notification Issues
And notifications.log says that it is running /etc/xymon/custom/alert.sh user-6109888833b7@xymon.invalid<mailto:user-6109888833b7@xymon.invalid>?
I’d look in /etc/xymon/custom/alert.sh then.
From: John Tullis [mailto:user-a6bbfd057f07@xymon.invalid]
Sent: Wednesday, October 11, 2017 1:52 PM
To: Root, Paul T; KC Kuhns; xymon at xymon.com<mailto:xymon at xymon.com>
Subject: RE: Notification Issues
I’ve worked with KC on this issue for some time now and still have had no success.
This is the result we’re getting when we test with xymond_alert.
$ xymond_alert --test DC.Comcast disk --duration=500
00007222 2017-10-11 11:46:08 Matching host:service:dgroup:page ''DC.Comcast:disk:NONE: User2/Client2' against rule line 1
00007222 2017-10-11 11:46:08 Failed 'PAGE=%.*User1/' (pagename not in include list)
00007222 2017-10-11 11:46:08 Matching host:service:dgroup:page 'DC.Comcast:disk:NONE:User2/Client2' against rule line 3
00007222 2017-10-11 11:46:08 *** Match with 'PAGE=%.*User2/' ***
00007222 2017-10-11 11:46:08 Matching host:service:dgroup:page 'DC.Comcast:disk:NONE: User2/Client2' against rule line 4
00007222 2017-10-11 11:46:08 *** Match with 'SCRIPT=/etc/xymon/custom/alert.sh user-6109888833b7@xymon.invalid<mailto:user-6109888833b7@xymon.invalid> COLOR=red,yellow RECOVERED REPEAT=720 DURATION>10' ***
00007222 2017-10-11 11:46:08 Script alert with command '/etc/xymon/custom/alert.sh' and recipient user-6109888833b7@xymon.invalid<mailto:user-6109888833b7@xymon.invalid>
This is a sample of alerts.cfg:
PAGE=%.*User1/
SCRIPT=/etc/xymon/alerts/alert.sh user-e2c0c4f8a224@xymon.invalid<mailto:user-e2c0c4f8a224@xymon.invalid> COLOR=red,yellow RECOVERED REPEAT=720 DURATION>10
PAGE=%.*User2/
SCRIPT=/etc/xymon/custom-alerts/alert.sh user-6109888833b7@xymon.invalid<mailto:user-6109888833b7@xymon.invalid> COLOR=red,yellow RECOVERED REPEAT=720 DURATION>10
User2 matches correctly but the email is still going to User1 even though we get a failed message for User1. We’ve tried deleting the User1 folder in the www folder. Restarting Xymon and the entire server and it doesn’t ever really seem to go away. I can see that the emails were sent in the logs. I also added the matching line number to the alert email using $CFID and the matching line points to line 1 for User1.
Any more help would be appreciated.
Thanks, John.
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Root, Paul T
Sent: Wednesday, October 11, 2017 10:22 AM
To: KC Kuhns <user-bbc3ee989f1c@xymon.invalid<mailto:user-bbc3ee989f1c@xymon.invalid>>; xymon at xymon.com<mailto:xymon at xymon.com>
Subject: Re: [Xymon] Notification Issues
You can use xymond_alert to test the alert system to see where it is sending.
xymond_alert --test DC.Comcast procs --duration=500 |grep -v Failed
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of KC Kuhns
Sent: Wednesday, October 11, 2017 9:27 AM
To: xymon at xymon.com<mailto:xymon at xymon.com>
Subject: [Xymon] Notification Issues
Good morning,
We’re using Xymon 4.3.25 and are running into a strange issue. We use Armor to monitor servers and various things at all of our clients. Our host file is setup something like this:
Page User1 User One
Subpage Client1 Client One
8.8.8.8 DC.Google # NOCONN
Page User2 User Two
Subpage Client2 Client Two
75.75.75.75 DC.Comcast # NOCONN
Each technician that we have has a page, and each client has its own subpage under the related technician. We often move clients around to different technicians so in the above example, we may decide to move Client2 to User1. When we do that, it seems that User2 still receives email alerts for DC.Comcast even though it has been moved under User1. When looking at the info tab for DC2, it would show only User1 and nothing tied to User2. There’s also nothing relating to that client in the alerts file.
Is there some type of cache that we need to clear when we move clients around to different technicians to prevent this? Appreciate the help.
This communication is the property of CenturyLink 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.
This communication is the property of CenturyLink 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.
This communication is the property of CenturyLink 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.