[Xymon] Bogus hosts filling up alert.log

[Japheth Cleaver]

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