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.

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.

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.