Enable core dumps on the machine and get a backtrace: http://www.opensips.org/Documentation/TroubleShooting-Crash
Regards, Ovidiu Sas On Tue, Nov 12, 2013 at 7:07 PM, Jeff Pyle <jp...@fidelityvoice.com> wrote: > 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 <jp...@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 >> >> >> > > > _______________________________________________ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- VoIP Embedded, Inc. http://www.voipembedded.com _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users