JC --
Brilliant! That solved my problem perfectly. Thanks to John again for lending a hand!
;-)
~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~
David Mills
Systems Administrator
Northrop Grumman
(XXX) XXX-XXXX (mobile)
-----Original Message-----
From: Japheth Cleaver [mailto:user-87556346d4af@xymon.invalid]
Sent: Tuesday, October 31, 2017 6:06 PM
To: Mills,David (HHSC Contractor) <user-7037272ac73f@xymon.invalid>; John Thurston <user-ce4d79d99bab@xymon.invalid>; xymon at xymon.com
Subject: Re: [Xymon] Bogus hosts filling up alert.log
On 10/31/2017 2:49 PM, Mills,David (HHSC Contractor) wrote:
Amendment: Eventually, Xymon did see the bogus entry for
0FS_96_192_168_22_1__export_ and it did stop appearing in the
alert.cfg
It's another data point, but this is kind of expected behavior and now I have just this bogus artifact hanging around.
'Any ideas where the alerts daemon gets its list of host names to check against?
;-)
If there had been a previous alert for the virtual/fake host, it would have been stored in memory, and frozen out into the alerts.chk file (probably in /var/lib/xymon/tmp/ during restarts).
The general reason for the alert is that xymond(_alert) is getting a report about something it doesn't (yet) know about. Usually, this clears a few minutes later as soon as xymond next checks hosts.cfg for changes, since typically that's the action pending to be taken.
Similarly, when a host is removed from hosts.cfg (or a drop command), that message is passed to xymond_alert to clear its record of the alert as well.
Adding the host to hosts.cfg and then dropping it should work for clearing out the errant alert. Alternatively, you can stop xymon (or at least xymond_alert, by adding DISABLED into tasks.cfg), grep out the line for the alert in alerts.chk manually (it's just a normal single-line-record text file, and then bring it back up.
HTH,
-jc