[Xymon] odd "failure" for file exists

[Galen Johnson]

Well...that theory is shot to hell...

=G=

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

> 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/d76cc4dc/attachment.html>