<HTML><BODY><div><div>Hi</div><div><br>The "segfault" event itself is already a sign that something is not working correctly. And this is the reason to open bugreport</div><div>I want to understand the mechanism of how opensips processes this kind of accident</div><div>For example in the logs I see messages:</div><div>Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[5577]: CRITICAL:core:sig_usr: segfault in process pid: 5577, id: 13<br>Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[5564]: NOTICE:event_jsonrpc:destroy: destroy module ...<br>Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[18595]: NOTICE:core:main: version: opensips 2.4.5 (x86_64/linux)<br>Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[18595]: WARNING:core:init_reactor_size: shrinking reactor size from 262144 (autodetected via rlimit) to 52428 (limited by memory of 10% from 16Mb)<br>Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[18595]: WARNING:core:init_reactor_size: use 'open_files_limit' to enforce other limit or increase pkg memory<br>Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[18595]: NOTICE:signaling:mod_init: initializing module ...<br>Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[18595]: NOTICE:event_jsonrpc:mod_init: initializing module ...</div><div>I noticed from this accident that opensips seemed to be "rebooted" and In this case, opensips continued to process traffic.<br>But what really happened? I see a new uptime after it. Am I understand correctly that in this particular case only the module jsonrpc was overloaded? <br>Or the whole service was restarted? </div><div> </div><div>And another case at the another server:</div><div><br>Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30343]: CRITICAL:core:sig_usr: segfault in process pid: 168640114, id: 5<br>Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30343]: DBG:core:restore_segv_handler: restoring SIGSEGV handler...<br>Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30343]: DBG:core:restore_segv_handler: successfully restored system SIGSEGV handler<br>Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30348]: CRITICAL:core:sig_usr: segfault in process pid: 0, id: 10<br>Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30345]: CRITICAL:core:sig_usr: segfault in process pid: 0, id: 7<br>Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30344]: CRITICAL:core:sig_usr: segfault in process pid: 0, id: 6<br>Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30349]: ERROR:core:parse_msg: message=<309132295C7FA6B57F8DE8DC3D4C0#015#012Content-Type:application/ISUP;base=itu-t92+;version=itu-t92+#015#012Content-Disposition:signal;handling=required#015#012Content-Transfer-Encoding:binary#015#012#015#012#001#020 #001#012><br>Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30349]: ERROR:core:receive_msg: Unable to parse msg received from [10.48.101.171:60105]<br>Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30350]: CRITICAL:core:sig_usr: segfault in process pid: 0, id: 12<br>Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30349]: CRITICAL:core:sig_usr: segfault in process pid: 0, id: 11<br>Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30351]: CRITICAL:core:sig_usr: segfault in process pid: 23032000, id: 13</div><div><br>After all these messages, opensips just “fell asleep”. It didn't handle any traffic until I reloaded it. </div><div> </div><div>id 10,11,12,13 — receiver SCTP</div><div>id 7,6 — receiver UDP</div><div><br>How opensips handles segfault? And what needs to be done so that he does not die just like in the latter case?</div></div><div> </div><div>--<br>Oleg Podguyko</div></BODY></HTML>