[OpenSIPS-Users] opensips shutdown leaves some processes

Jeff Pyle jpyle at fidelityvoice.com
Wed Nov 13 01:07:32 CET 2013


 I think I've made some progress.  It has something to do with using
127.0.0.1 as an interface.  This instance talked only to other OS instances
on the same machine, so localhost seemed like a natural and portable
choice.  Unfortunately it causes some problems possibly with the
check_ip_address function, or maybe the find_si function it calls.  More
testing showed it would crash/stop on its own.

Nov 12 15:59:52 [11098] DBG:core:check_ip_address: params 127.0.0.1,
127.0.0.1, 0
Nov 12 15:59:52 [11094] DBG:core:handle_sigs: status = 11
Nov 12 15:59:52 [11094] INFO:core:handle_sigs: child process 11098 exited
by a signal 11
Nov 12 15:59:52 [11094] INFO:core:handle_sigs: core was not generated
Nov 12 15:59:52 [11094] INFO:core:handle_sigs: terminating due to SIGCHLD
Nov 12 15:59:52 [11096] INFO:core:sig_usr: signal 15 received
Nov 12 15:59:52 [11101] INFO:core:sig_usr: signal 15 received
Nov 12 15:59:52 [11100] INFO:core:sig_usr: signal 15 received
Nov 12 15:59:52 [11097] INFO:core:sig_usr: signal 15 received
Nov 12 15:59:52 [11099] INFO:core:sig_usr: signal 15 received
Nov 12 15:59:52 [11095] INFO:core:sig_usr: signal 15 received
Nov 12 15:59:52 [11094] INFO:core:cleanup: cleanup

At debug=6 I noticed the same check_ip_address message just before it
stopped each time.

Anyway, using different ports on a real LAN IP solves both the crash and
shutdown problems.


- Jeff



On Mon, Nov 11, 2013 at 11:03 PM, Jeff Pyle <jpyle at fidelityvoice.com> wrote:

> Hello,
>
> In one particular configuration on 1.10 a standard Opensips shutdown isn't
> ending all the processes...if calls have passed through the system.  If no
> calls have passed, everything shuts down fine.
>
> At one particular moment in time with everything running I have:
>
> Process::  ID=0 PID=26283 Type=attendant
> Process::  ID=1 PID=26284 Type=MI XMLRPC
> Process::  ID=2 PID=26285 Type=MI FIFO
> Process::  ID=3 PID=26286 Type=RTPP timeout receiver
> Process::  ID=4 PID=26287 Type=SIP receiver udp:127.0.0.1:5002
> Process::  ID=5 PID=26288 Type=SIP receiver udp:127.0.0.1:5002
> Process::  ID=6 PID=26289 Type=time_keeper
> Process::  ID=7 PID=26290 Type=timer
>
> But after /etc/init.d/opensips stop, it's always the attendant (26283) and
> the second SIP receiver (26288) hanging around.  It requires a kill -9 to
> get them to go away.
>
> A full debug isn't showing anything obvious:
>
> Nov 11 22:51:29 [26283] DBG:core:handle_sigs: SIGTERM received, program
> terminates
> Nov 11 22:51:29 [26289] INFO:core:sig_usr: signal 15 received
> Nov 11 22:51:29 [26288] INFO:core:sig_usr: signal 15 received
> Nov 11 22:51:29 [26290] INFO:core:sig_usr: signal 15 received
> Nov 11 22:51:29 [26287] INFO:core:sig_usr: signal 15 received
> Nov 11 22:51:29 [26286] INFO:core:sig_usr: signal 15 received
> Nov 11 22:51:29 [26285] INFO:core:sig_usr: signal 15 received
> Nov 11 22:51:29 [26284] INFO:core:sig_usr: signal 15 received
>
> But not everything has terminated:
>
> # ps ax | grep opensips
> 26283 ?        S<     0:00 /usr/sbin/opensips -f
> /etc/opensips/opensips.cfg -P /var/run/opensips/opensips.pid -m 8 -M 1 -u
> opensips -g opensips
> 26288 ?        R<     0:21 /usr/sbin/opensips -f
> /etc/opensips/opensips.cfg -P /var/run/opensips/opensips.pid -m 8 -M 1 -u
> opensips -g opensips
>
> Any suggestions on where to continue investigating?
>
>
> - Jeff
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20131112/ac147fc6/attachment.htm>


More information about the Users mailing list