[OpenSIPS-Users] Fwd: opensips is restarting after call is finished
Bogdan-Andrei Iancu
bogdan at opensips.org
Mon Dec 11 14:46:06 UTC 2023
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 <bogdan at opensips.org>
>>>>>>>>>> Za: Simon Gajski <simon at softnet.si>, OpenSIPS users
>>>>>>>>>> mailling list <users at lists.opensips.org>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>> 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/20231211/affd38ba/attachment-0001.html>
More information about the Users
mailing list