Re: [OpenSIPS-Users] Fwd: opensips is restarting after call is finished

Mon, 11 Dec 2023 08:33:05 -0800 

Thanks to Liviu, we now have a fix for this :
https://github.com/OpenSIPS/opensips/commit/42f1eb7ae7dfa702602ca8aa232e9b9016b2d146

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
  https://www.siphub.com

On 11.12.2023 16:46, Bogdan-Andrei Iancu wrote:

Hi Simon,
Right, this explains it. Still, we need to do a fix here, to prevent such cases, where a backend is required for CDRs, but not configured. 

Regards,
Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com
On 11.12.2023 12:53, Simon Gajski wrote:


Dear Bogdan

We use only accounting.
But there was left a line do_accounting("aaa"); in cfg script that I somehow  missed. 

After removal, it works as expected.

Thank you for all help and my apologies not for detecting this earlier.

BR
Simon

Bogdan-Andrei Iancu je 11.12.2023 ob 10:49 napisal:

Hi Simon,
As per the trace posted by Neven, the crash is related to the AAA support (for ACC), not the DB one. So, are you using RADIUS or DIAMETER for the CDRs? 

Regards,
Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com
On 11.12.2023 10:00, Simon Gajski wrote:


Dear Bogdan,

yes, we do use CDR via AAA.
Here are used modparams:

#### ACCounting module
loadmodule "acc.so"
modparam("acc", "early_media", 0)
modparam("acc", "report_cancels", 0)
modparam("acc", "detect_direction", 1)
modparam("acc", "db_url", "mysql://opensips:opensipsrw@localhost/opensips") 
#modparam("acc", "db_table_missed_calls", "acc")
modparam("acc", "service_type", 15)
modparam("acc", "leg_fields", "db: CALLER->Anum;CALLEE->Bnum;TYPE->leg_type;SRCIP->srcIP;DESTIP->destIP;DIRECTION->direction") 

and we do  receive CDR in mysql acc table

gdb returns
Core was generated by `/usr/sbin/opensips -P /run/opensips/opensips.pid -f /etc/opensips/opensips.cfg'. 
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000000000000 in ?? ()
(gdb) f 1
#1  0x00007f334e06aad5 in acc_aaa_cdrs (dlg=<optimized out>, msg=<optimized out>, ctx=0x7f334fcc52c8) at /build/opensips-3.4.2/modules/acc/acc.c:965 965     /build/opensips-3.4.2/modules/acc/acc.c: No such file or directory. 
(gdb) p proto
$1 = {init_prot = 0x0, create_aaa_message = 0x0, destroy_aaa_message = 0x0, send_aaa_request = 0x0, dictionary_find = 0x0, avp_add = 0x0, avp_get = 0x0} 


BR
Simon

Bogdan-Andrei Iancu je 08.12.2023 ob 16:38 napisal:

It looks you are using (or trying to) the CDR support via AAA.
Could you share the full modparam's for the acc module and the radius/diameter support? 

Also, in using GDB, just do:
  f 1
  p proto

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
https://www.opensips-solutions.com
https://www.siphub.com

On 08.12.2023 16:30, Neven Grzancic wrote:

Hi Bogdan,

good hit on the apport service - thanks!

here's the trace we get from one such crash:

[New LWP 1130]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `/usr/sbin/opensips -P /run/opensips/opensips.pid -f /etc/opensips/opensips.cfg'. 
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000000000000 in ?? ()
(gdb) bt full
#0  0x0000000000000000 in ?? ()
No symbol table info available.
#1  0x00007f334e06aad5 in acc_aaa_cdrs (dlg=<optimized out>, msg=<optimized out>, ctx=0x7f334fcc52c8) 
    at /build/opensips-3.4.2/modules/acc/acc.c:965
        i = <optimized out>
        j = <optimized out>
        ret = 6
        res = -1
        nr_leg_vals = <optimized out>
        start_time = {tv_sec = 1702044564, tv_usec = 417047}
        core_s = {s = 0x7f33705e9878 "\006", len = 101}
        leg_s = {s = 0x0, len = <optimized out>}
        extra_s = {s = 0x0, len = <optimized out>}
        send = 0x0
        offset = <optimized out>
        av_type = 32563
        r_stat = <optimized out>
        locked = 0
        duration = 1338791072
        ms_duration = 0
        extra = <optimized out>
        error = <optimized out>
        __FUNCTION__ = "acc_aaa_cdrs"
#2  0x00007f334e078ade in acc_cdr_cb (t=0x0, type=5, ps=0x7ffdb12e09e0) 
    at /build/opensips-3.4.2/modules/acc/acc_logic.c:986
        ctx = 0x7f334fcc52c8
        dlg = 0x7f334fcc54e0
        __FUNCTION__ = "acc_cdr_cb"
[...]


On 08.12.23 15:16, Bogdan-Andrei Iancu wrote:
Simon, I do not need the corefile, usually it is huge - as per web instructions (see the prev link), extract the backtrace (using gdb) and share it with me. 

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
https://www.opensips-solutions.com
https://www.siphub.com

On 08.12.2023 16:13, Simon Gajski wrote:

Hi Bogdan

you were right
we have the core file now

Please let me know where to send it (gzipped is approx 2MB)


BR
Simon

Bogdan-Andrei Iancu je 08.12.2023 ob 14:17 napisal:

Hi Simon,
Maybe you have some apport service running on the machine, moving the core file. 

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
https://www.opensips-solutions.com
https://www.siphub.com

On 08.12.2023 13:35, Neven Grzancic wrote:

Dear Bogdan,
we tried following https://opensips.org/Documentation/TroubleShooting-Crash and trying different things, and even though the syslog shows that the core file was dumped:
Dec  8 12:25:13 sbc2 /usr/sbin/opensips[4363]: CRITICAL:core:sig_usr: segfault in process pid: 4363, id: 7 Dec  8 12:25:13 sbc2 kernel: [ 3394.269733] opensips[4363]: segfault at 0 ip 0000000000000000 sp 00007ffdc458f6a8 error 14 in opensips[55816fbd0000+1f000] Dec  8 12:25:18 sbc2 mariadbd[922]: 2023-12-08 12:25:18 400 [Warning] Aborted connection 400 to db: 'opensips' user: 'opensips' host: 'localhost' (Got an error reading communication packets) Dec  8 12:25:18 sbc2 /usr/sbin/opensips[4356]: INFO:core:handle_sigs: child process 4363 exited by a signal 11 Dec  8 12:25:18 sbc2 /usr/sbin/opensips[4356]: INFO:core:handle_sigs: core was generated Dec  8 12:25:18 sbc2 /usr/sbin/opensips[4356]: INFO:core:handle_sigs: terminating due to SIGCHLD Dec  8 12:25:18 sbc2 /usr/sbin/opensips[4359]: INFO:core:sig_usr: signal 15 received Dec  8 12:25:18 sbc2 /usr/sbin/opensips[4360]: INFO:core:sig_usr: signal 15 received
the core does not get generated, or at least not in the directory provided via options at runtime (-w /tmp). The issue is always repeatable (the daemon crashes after every finished call), if there are more active calls at the moment of the crash, whose calls remain active and proceed normally until termination (which again causes a crash). We also tried enabling debug mode, but in that case the process does not start successfully and runs into a timeout. In any case, any additional help or suggestion on how to successfully generate the core dump would be much appreciated, as we seem to have ran into a wall here... 

On 08.12.23 12:26, Simon Gajski wrote:




-------- Posredovano sporočilo --------
Zadeva:     Re: [OpenSIPS-Users] opensips is restarting after call is finished 
Datum:     Thu, 7 Dec 2023 17:52:37 +0200
Od:     Bogdan-Andrei Iancu <[email protected]>
Za:     Simon Gajski <[email protected]>, OpenSIPS users mailling list <[email protected]> 



Hi Simon,

Well, the log is very self explanatory:
Dec 7 15:59:47 sbc2 /usr/sbin/opensips[28488]: INFO:core:handle_sigs: child process 28495 exited by a signal 11 Dec  7 15:59:47 sbc2 /usr/sbin/opensips[28488]: INFO:core:handle_sigs: core was generated Dec  7 15:59:47 sbc2 /usr/sbin/opensips[28488]: INFO:core:handle_sigs: terminating due to SIGCHLD
Or shortly, you opensips just crashed :). So see https://opensips.org/Documentation/TroubleShooting-Crash for how to report further. 

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
https://www.opensips-solutions.com
https://www.siphub.com

On 07.12.2023 17:17, Simon Gajski via Users wrote:


Hi

we are running opensips 3.4.2
on Ubuntu 22.04.3 LTS
and also use RTPengine Version: 10.5.0.0+0~mr10.5.0.0 git-master-74075f63 

Opensips acts as SBC with RTP engine enabled.
Calls are working fine, however after each call is finished, bellow action happens.
We had same problem with opensips 3.2 and Ubuntu 20. So we did upgrade to latest stable release, and it is the same.
Is this opensips script configuration issue or a bug? And how could I fix it? 

[....]

Thanks for all tips.

BR
Simon


_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

















_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to