Hi David,
Cool, so my guess was right :) . Thanks for the update.
Regards,
Bogdan
David Cunningham wrote:
> Hi Bogdan,
>
> Just to let you know, we traced the problem to the Perl code. Thank
> you for your help!
>
>
> On Mon, May 3, 2010 at 8:48 AM, Bogdan-Andrei Iancu
> wrote:
>
>> Hi David
Hi Bogdan,
Just to let you know, we traced the problem to the Perl code. Thank
you for your help!
On Mon, May 3, 2010 at 8:48 AM, Bogdan-Andrei Iancu
wrote:
> Hi David,
>
> Based on the "ps" output, it seams that the zombies processes were
> forked by opensips worker processes - this does not h
Hi David,
Based on the "ps" output, it seams that the zombies processes were
forked by opensips worker processes - this does not happen only when
using the exec module (which you do not have) - the only alternative is
that the perl scripts you are using are doing the fork (maybe some perl
func
Hello,
Certainly, here they are from opensips.cfg and I've included the
modparam in case they help:
loadmodule "db_mysql.so"
loadmodule "sl.so"
loadmodule "tm.so"
loadmodule "usrloc.so"
loadmodule "auth.so"
loadmodule "auth_db.so"
loadmodule "maxfwd.so"
loadmodule "mi_fifo.so"
loadmodule "nathelp
Hi David,
by chance, using the "exec" module ?
Or, can you list the modules you are using ?
Regards,
Bogdan
David Cunningham wrote:
> Hello,
>
> Thank you for the reply. I checked the parent of the zombie processes,
> and they seem to be "SIP receiver" processes as per the following "ps
> -ef"
Hello,
Thank you for the reply. I checked the parent of the zombie processes,
and they seem to be "SIP receiver" processes as per the following "ps
-ef" extract and "opensipsctl fifo ps" information.
We're not running the "respawn" patch.
Any more advice very welcome, thanks again!
user 5830
Hi David,
Let's try and see what's the parent process of the zombie procs -> check
with ps and correlate (for the name) with "opensipsctl fifo ps"
I guess the parent of the zombies should be the "attendant proc" . BTW,
are you running with the "respawn" patch ?
Regards,
Bogdan
David Cunningh
Hello,
Thanks again for your assistance!
We're not using the mi_xmlrpc module.
Were you suggesting using gdb on the zombi process? I tried and got
the following:
user 31183 12140 0 10:31 ?00:00:00 [opensips]
[r...@sip01 ~]# gdb /sbin/opensips 31183
GNU gdb Fedora (6.8-37.el5)
Copyrigh
Hi David,
David Cunningham wrote:
> Hello,
>
> Thank you for the reply!
>
> The log doesn't say anything useful, just "Listening on" and then the
> UDP and TCP IP address and port, and "Aliases" also with UDP and TCP
> addresses and ports. I did set "debug = 9" in
> /etc/opensips/opensips.cfg but
Hello,
Thank you for the reply!
The log doesn't say anything useful, just "Listening on" and then the
UDP and TCP IP address and port, and "Aliases" also with UDP and TCP
addresses and ports. I did set "debug = 9" in
/etc/opensips/opensips.cfg but this caused all phones registered with
OpenSIPS t
Hi David,
the defunct procs seams to be the children of a still running opensips
proc - this may be the attendant process which, for whatever reasons is
not stopping (after killing the children procs).
Checks what this process is doing (see top, try attaching with gdb).
Also, does the log say
Hello,
We have a server which is creating a lot of defunct OpenSIPS
processes. An example process tree is below (from ps -ef --forest).
I have no idea where to start looking for the cause of this. Any
suggestions very welcome!
user 7811 1 0 03:19 ?00:00:00 /sbin/opensips -m 256 -P
12 matches
Mail list logo
