[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [hobbit][bug] proc monitor flag red an existing process
- To: hobbit (at) hswn.dk
- Subject: Re: [hobbit][bug] proc monitor flag red an existing process
- From: Charles Goyard <charles.goyard (at) orange-ftgroup.com>
- Date: Mon, 18 Jun 2007 10:25:00 +0200
- References: <466FEA66.4070808 (at) hydre.org>
- User-agent: Mutt/1.5.13 (2006-08-11)
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,
--
Charles Goyard - charles.goyard (at) orange-ftgroup.com - (+33) 1 45 38 01 31
Orange Business Services - online multimedia // ingénierie