Hi
The "segfault" event itself is already a sign that something is not working
correctly. And this is the reason to open bugreport
I want to understand the mechanism of how opensips processes this kind of
accident
For example in the logs I see messages:
Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[5577]: CRITICAL:core:sig_usr:
segfault in process pid: 5577, id: 13
Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[5564]:
NOTICE:event_jsonrpc:destroy: destroy module ...
Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[18595]: NOTICE:core:main: version:
opensips 2.4.5 (x86_64/linux)
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)
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
Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[18595]: NOTICE:signaling:mod_init:
initializing module ...
Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[18595]:
NOTICE:event_jsonrpc:mod_init: initializing module ...
I noticed from this accident that opensips seemed to be "rebooted" and In this
case, opensips continued to process traffic.
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?
Or the whole service was restarted?
And another case at the another server:
Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30343]: CRITICAL:core:sig_usr:
segfault in process pid: 168640114, id: 5
Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30343]:
DBG:core:restore_segv_handler: restoring SIGSEGV handler...
Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30343]:
DBG:core:restore_segv_handler: successfully restored system SIGSEGV handler
Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30348]: CRITICAL:core:sig_usr:
segfault in process pid: 0, id: 10
Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30345]: CRITICAL:core:sig_usr:
segfault in process pid: 0, id: 7
Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30344]: CRITICAL:core:sig_usr:
segfault in process pid: 0, id: 6
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>
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]
Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30350]: CRITICAL:core:sig_usr:
segfault in process pid: 0, id: 12
Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30349]: CRITICAL:core:sig_usr:
segfault in process pid: 0, id: 11
Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30351]: CRITICAL:core:sig_usr:
segfault in process pid: 23032000, id: 13
After all these messages, opensips just “fell asleep”. It didn't handle any
traffic until I reloaded it.
id 10,11,12,13 — receiver SCTP
id 7,6 — receiver UDP
How opensips handles segfault? And what needs to be done so that he does not
die just like in the latter case?
--
Oleg Podguyko
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
