[Xymon] odd "failure" for file exists

Galen Johnson solitaryr at gmail.com
Tue Oct 16 03:51:35 CEST 2018


I might have figured it out...if it stays red tonight on both servers, I'll
know for sure :-).  The server IP address was incorrect in xymonserver.cfg
on the secondary machine.  It was using 127.0.0.1 instead of the real
address.  I suspect (but can't prove) that even though the server ip was
correct in the xymonfetch in tasks.cfg, the server was misrepresenting
itself otherwise,  Hence "flapping" because the clients didn't recognize it
and treated it as a standalone instance.

=G=

On Mon, Oct 15, 2018 at 9:11 PM Galen Johnson <solitaryr at gmail.com> wrote:

> I do have 2 servers but I'm not having this problem with any other test
> (even the other files test).  I rechecked to verify that they both had a
> unique "id" and they do so unless xymon is ignoring that for this test (for
> some reason) I am clueless.  It's also strange that it's only this
> pattern,  I had a different process core on different machine and it worked
> as expected.  I'm stymied.
>
> =G=
>
> On Mon, Oct 15, 2018 at 4:11 PM Root, Paul T <Paul.Root at centurylink.com>
> wrote:
>
>> Do you just have one xymon server?   Flapping implies to me that you are
>> getting 2 different sources telling you something is happening.
>>
>>
>>
>> Or is there 2 clients running and one didn’t get an update from the
>> server (or running in client mode) that doesn’t have the lookup for the
>> core file.
>>
>>
>>
>> Or does the path to get there not allow the xymon user?
>>
>>
>>
>> *From:* Galen Johnson <solitaryr at gmail.com>
>> *Sent:* Monday, October 15, 2018 3:05 PM
>> *To:* Root, Paul T <Paul.Root at CenturyLink.com>
>> *Cc:* xymon >> xymon at xymon.com <xymon at xymon.com>
>> *Subject:* Re: [Xymon] odd "failure" for file exists
>>
>>
>>
>> Actually, I have to correct myself...it's flapping and now I need to
>> figure out why since that is a different problem.  To your point, Paul,
>> that is essentially exactly what I have (obviously with different paths).
>> I suspect now it has to do with 'fetch'.
>>
>>
>>
>> For example, in client-local.cfg:
>>
>> file:`find /var/lib/systemd/coredump/ -maxdepth 1 -type f`
>>
>>
>>
>> and analysis.cfg
>>
>> FILE %/var/lib/systemd/coredump/core.* red NOEXIST
>>
>>
>>
>> I may eventually change that to yellow but I just added a new app to the
>> systems and it was supposed to behave :-).
>>
>>
>>
>> =G=
>>
>>
>>
>>
>>
>> On Mon, Oct 15, 2018 at 3:47 PM Root, Paul T <Paul.Root at centurylink.com>
>> wrote:
>>
>> I do this, but just go yellow, because that’s what we need.
>>
>>
>>
>> client-local.cfg:file:`ls /core.*`
>>
>> analysis.cfg:        FILE         %^/core.* YELLOW NOEXIST
>>
>>
>>
>>
>>
>> *From:* Xymon <xymon-bounces at xymon.com> *On Behalf Of *Galen Johnson
>> *Sent:* Monday, October 15, 2018 2:34 PM
>> *To:* xymon >> xymon at xymon.com <xymon at xymon.com>
>> *Subject:* [Xymon] odd "failure" for file exists
>>
>>
>>
>> Ok...this is weird.  I have Xymon triggering when a file (coredump)
>> exists but it only turns red when a new file shows up...it should remain
>> red until the files are cleaned up.  After the next update cycle it goes
>> green yet the page shows that it sees the files.  Any thoughts on this
>> behavior?  I have another "file exists" test that is behaving as expected
>> (at least I think it is).
>>
>>
>>
>> thanks
>>
>>
>>
>> =G=
>>
>> 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.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20181015/f6a54163/attachment.html>


More information about the Xymon mailing list