odd "failure" for file exists
list Galen Johnson
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=
list Paul Root
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.
list Galen Johnson
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 <user-76fdb6883669@xymon.invalid>
▸
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.
list Paul Root
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 <user-fc632e705d24@xymon.invalid>
Sent: Monday, October 15, 2018 3:05 PM
To: Root, Paul T <user-76fdb6883669@xymon.invalid>
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 <user-76fdb6883669@xymon.invalid<mailto:user-76fdb6883669@xymon.invalid>> 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<mailto:xymon-bounces at xymon.com>> On Behalf Of Galen Johnson
Sent: Monday, October 15, 2018 2:34 PM
To: xymon >> xymon at xymon.com<mailto:xymon at xymon.com> <xymon at xymon.com<mailto: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.
list Galen Johnson
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 <user-76fdb6883669@xymon.invalid>
▸
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 <user-fc632e705d24@xymon.invalid> *Sent:* Monday, October 15, 2018 3:05 PM *To:* Root, Paul T <user-76fdb6883669@xymon.invalid> *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 <user-76fdb6883669@xymon.invalid> 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.
list Galen Johnson
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 <user-fc632e705d24@xymon.invalid> 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 <user-76fdb6883669@xymon.invalid> 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 <user-fc632e705d24@xymon.invalid> *Sent:* Monday, October 15, 2018 3:05 PM *To:* Root, Paul T <user-76fdb6883669@xymon.invalid> *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 <user-76fdb6883669@xymon.invalid> 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.
list Galen Johnson
Well...that theory is shot to hell...
▸
=G=
On Mon, Oct 15, 2018 at 9:51 PM Galen Johnson <user-fc632e705d24@xymon.invalid> 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 <user-fc632e705d24@xymon.invalid> 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 <user-76fdb6883669@xymon.invalid> 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 <user-fc632e705d24@xymon.invalid> *Sent:* Monday, October 15, 2018 3:05 PM *To:* Root, Paul T <user-76fdb6883669@xymon.invalid> *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 <user-76fdb6883669@xymon.invalid> 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.