[OpenSIPS-Users] opensips shutdown leaves some processes

[Bogdan-Andrei Iancu]

Hi Jeff,

the LO interface issue is really strange - I cannot imagine a relation
between the LO interface and the shutdown interface....attaching with
gdb to a running process is as simple as accessing a core file "gdb
bin_file pid"

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 11/14/2013 04:36 PM, Jeff Pyle wrote:
> Hi Bogdan,
>
> I had not, that's a new concept for me.  I'll see what I can do.
>  Changing from localhost to LAN IPs did solve the problem of processes
> not shutting down properly, however.  Just the already freed memory
> crash <https://github.com/OpenSIPS/opensips/issues/126> remains.
>
>
> - Jeff
>
>
>
> On Thu, Nov 14, 2013 at 5:29 AM, Bogdan-Andrei Iancu
> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>
>     Hi Jeff,
>
>     Have you tried to attach with gdb to the remaining process and to
>     get a backtrace ?
>
>     Regards,
>
>     Bogdan-Andrei Iancu
>     OpenSIPS Founder and Developer
>     http://www.opensips-solutions.com
>
>
>     On 11/12/2013 06:03 AM, Jeff Pyle 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
>>     <http://127.0.0.1:5002> 
>>     Process::  ID=5 PID=26288 Type=SIP receiver udp:127.0.0.1:5002
>>     <http://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
>>
>>
>>
>>
>>     _______________________________________________
>>     Users mailing list
>>     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20131118/9404c563/attachment.htm>