Xymon Mailing List Archive search

[bug] proc monitor flag red an existing process

list Stéphane Angot
Wed, 20 Jun 2007 12:07:45 +0200
Message-Id: <user-b107291e2f80@xymon.invalid>

Charles Goyard wrote:
Hi,

Stéphane ANGOT wrote :
  
I monitor the process tor with this line in hobbit-client.cfg :

PROC    "%^tor" TEXT=tor

It works well except when the memory allocated for the process exceed 99999 : the monitor flag the process red...

Perhaps it's due to a wrong regular expression or perhaps it's the shift in the PS output :


28894 28893 _ntp      Mon05PM S      4  0.0   0:03.60  0.1   900  1344 ntpd: ntp engine (ntpd)
36112     1 tor       Mon06PM S     20  0.0 233:44.10  9.6 98692 101272 tor
42051     1 fetchmail Fri06PM Ss     4  0.0   0:19.02  0.2  1760  3952 fetchmail -f /usr/local/etc/fetchmailrc -d 300

Any clue?
    
This is what you say, and I just got bitten by this at 3 in the morning.

The bug lies in hobbitd_client.c, unix_proc_report :

	/* 	 * Find where the command is located. We look for the header for
	 * the command, and calculate the offset from the beginning of the line.
	 • A temporary workaround is to change "%^tor" into "%^\s*tor" (works for me).

Since the number of fields ps outputs is not fixed (the TIME may have
hold spaces), the fix is not an easy one. The last field with a
guaranteed width is %MEM in my case. Maybe going back to that field and
skipping over the next few spaces will yield the real offset of the
command (well, I just found an old AIX box this even %MEM blasted off).


Regards,

  
Hello,

This workaround does not work for me because the shift may be for more than 1 character.

Here is what I've done :

I changed "%^tor" into "%tor$"

of course, every process ending by tor may be matched by this rule. In my case, I've only one in this case.

Regards,