[hobbit][bug] proc monitor flag red an existing process

Stéphane ANGOT sa at hydre.org
Wed Jun 20 12:07:45 CEST 2007


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,




More information about the Xymon mailing list