Procs not reporting 🔗 link

On Mon, Oct 3, 2011 at 4:00 PM, Jewel Makda <user-f94a3a1b7030@xymon.invalid <mailto:user-f94a3a1b7030@xymon.invalid>> wrote:

    I had a redhat client and have xymon running on it but it's not
    reporting what I have in the localclient.cfg file.  It's only
    reporting (conn, http, info, smtp and trends) which is what the
    server has been configured to look at.  I have the following in my
    file:


    HOST="lists.domain"
       UP 1h
       PROC httpd 1 5
       PROC postfix  1 15


    Bothing is showing up under PROCS on my server.  I know I am
    editing the right file and that the service is running.  Both
    configs have the same host name - what am I doing wrong. I am
    running the latest version of xymon.  I also have both machines on
    the same network and they can see each other so I know it's not a
    port blocking issue.

On 10/3/2011 4:41 PM, Ralph Mitchell wrote:

If your server is only showing  conn, http, info, smtp and trends,
then the client is not reporting anything.  So either:
  1) xymon is not running on the client;

The process is running.

  2) the client is reporting a different name to what the server
expects;

I would like for it to report only under the first part of the name
(i.e. name.domain.com and use name instead) When I put both of these
in the config files it doesn't work but if I use the fqdn it starts
reporting.  I did this and now I have a "Clear" status for files,
ports, and procs.  I have spent hours trying different configs in my
localclient.cfg on the server I wanted monitored but nothing is
working.  I did check to see if the server was in ghosts clients and
it is not here. So it is communicating with the xymon server since I
am able to see all of my processes listed under the procs colums but
what I have in my localclient.cfg files seems to be getting ignored. 
Here is what I have:
HOST=xxx.xxxxx.xx
  UP 1h
  LOAD 5.0 10.0
  DISK * 90 95
  MEMPHYS 100 101
  MEMSWAP 50 80
  PROC httpd 1 20 red
  PROC qrunner 1 50 red
Here is what it looks like now on my server:

  3) the client is sending reports to some ip that is not the xymon
server 
Do you see anything in the "Ghost Clients" list on the "Reports"
 tab
in the web page??  If the client name is being reported wrong,
that's
where it should show up.
Ralph Mitchell
On Mon, Oct 3, 2011 at 4:00 PM, Jewel Makda <
user-f94a3a1b7030@xymon.invalid > wrote:

I had a redhat client and have xymon running on it but it's not
reporting what I have in the localclient.cfg file.  It's only
reporting (conn, http, info, smtp and trends) which is what the
server
has been configured to look at.  I have the following in my file:
HOST="lists.domain"
   UP 1h
   PROC httpd 1 5
   PROC postfix  1 15
Bothing is showing up under PROCS on my server.  I know I am
editing
the right file and that the service is running.  Both configs have
the
same host name - what am I doing wrong. I am running the latest
version of xymon.  I also have both machines on the same network
and
they can see each other so I know it's not a port blocking issue.

On 10/4/2011 4:28 PM, user-f00ed6e065e8@xymon.invalid wrote:

Maybe I missed something in the email chain, but you shouldn't have to 
touch localclient.cfg file on a client.

The analysis.cfg file on the Xymon server should have the PROC entries 
in it.  Unless the client and server

are the same, then you need to start xymonclient.sh with a '--local' 
switch, but even then, let the server handle it.

Again if I missed something, then my apologies

Greg Shea


    On 10/3/2011 4:41 PM, Ralph Mitchell wrote:

        If your server is only showing  conn, http, info, smtp and
        trends, then the client is not reporting anything.  So either:

          1) xymon is not running on the client;

    The process is running.

          2) the client is reporting a different name to what the
        server expects;

    I would like for it to report only under the first part of the
    name (i.e. name.domain.com and use name instead) When I put both
    of these in the config files it doesn't work but if I use the fqdn
    it starts reporting.  I did this and now I have a "Clear" status
    for files, ports, and procs.  I have spent hours trying different
    configs in my localclient.cfg on the server I wanted monitored but
    nothing is working.  I did check to see if the server was in
    ghosts clients and it is not here. So it is communicating with the
    xymon server since I am able to see all of my processes listed
    under the procs colums but what I have in my localclient.cfg files
    seems to be getting ignored.  Here is what I have:
    HOST=xxx.xxxxx.xx
      UP 1h
      LOAD 5.0 10.0
      DISK * 90 95
      MEMPHYS 100 101
      MEMSWAP 50 80
      PROC httpd 1 20 red
      PROC qrunner 1 50 red

    Here is what it looks like now on my server:


          3) the client is sending reports to some ip that is not the
        xymon server

        Do you see anything in the "Ghost Clients" list on the
        "Reports"  tab in the web page??  If the client name is being
        reported wrong, that's where it should show up.

        Ralph Mitchell


        On Mon, Oct 3, 2011 at 4:00 PM, Jewel Makda
        <user-f94a3a1b7030@xymon.invalid
        <mailto:user-f94a3a1b7030@xymon.invalid>> wrote:

            I had a redhat client and have xymon running on it but
            it's not reporting what I have in the localclient.cfg
            file.  It's only reporting (conn, http, info, smtp and
            trends) which is what the server has been configured to
            look at.  I have the following in my file:


            HOST="lists.domain"
               UP 1h
               PROC httpd 1 5
               PROC postfix  1 15


            Bothing is showing up under PROCS on my server.  I know I
            am editing the right file and that the service is running.
             Both configs have the same host name - what am I doing
            wrong. I am running the latest version of xymon.  I also
            have both machines on the same network and they can see
            each other so I know it's not a port blocking issue.