[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