[OpenSIPS-Users] calling t_uac_cancel from opensips script
Răzvan Crainea
razvan at opensips.org
Tue Sep 9 17:32:28 CEST 2014
Hi, Jayesh!
How did you get from opensipsctl to uac_cancel.sh? Where do you see this
(23430) output? Are you sure it is not used just for debugging? I think
it just prints the PID of the process.
Best regards,
Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com
On 09/09/2014 06:11 PM, Jayesh Nambiar wrote:
> When I use exec_avp opensips hangs. There's no core generated, and
> following are the logs immediately after the command is executed:
> Sep 9 10:17:48 v38 /usr/local/myOpensips/sbin/opensips[24843]:
> DBG:exec:w_exec_avp: executing
> [/usr/local/myOpensips/etc/opensips/uac_cancel.sh
> '.56sqM.YAwbUId0odDVrte3d6PZqa.de
> <http://56sqM.YAwbUId0odDVrte3d6PZqa.de>' '14654']
> Sep 9 10:17:48 v38 /usr/local/myOpensips/sbin/opensips[24843]:
> DBG:exec:exec_avp: Forked pid 24879
> Sep 9 10:18:00 v38 /usr/local/myOpensips/sbin/opensips[24835]:
> DBG:mi_fifo:mi_parse_tree: adding node <> ; val
> <.56sqM.YAwbUId0odDVrte3d6PZqa.de
> <http://56sqM.YAwbUId0odDVrte3d6PZqa.de>>
> Sep 9 10:18:00 v38 /usr/local/myOpensips/sbin/opensips[24835]:
> DBG:mi_fifo:mi_parse_tree: adding node <> ; val <14654>
> Sep 9 10:18:00 v38 /usr/local/myOpensips/sbin/opensips[24835]:
> DBG:mi_fifo:mi_parse_node: end of input tree
> Sep 9 10:18:00 v38 /usr/local/myOpensips/sbin/opensips[24835]:
> DBG:mi_fifo:mi_fifo_server: done parsing the mi tree
> Sep 9 10:18:00 v38 /usr/local/myOpensips/sbin/opensips[24835]:
> DBG:tm:t_lookup_callid: created comparable call_id header field:
> >Call-ID: .56sqM.YAwbUId0odDVrte3d6PZqa.de#015#012
> <http://56sqM.YAwbUId0odDVrte3d6PZqa.de#015#012><
> Sep 9 10:18:00 v38 /usr/local/myOpensips/sbin/opensips[24835]:
> DBG:tm:t_lookup_callid: created comparable cseq header field: >CSeq:
> 14654 INVITE<
> Sep 9 10:18:00 v38 /usr/local/myOpensips/sbin/opensips[24835]:
> DBG:tm:t_lookup_callid: <Call-ID:
> .56sqM.YAwbUId0odDVrte3d6PZqa.de#015#012
> <http://56sqM.YAwbUId0odDVrte3d6PZqa.de#015#012>> <CSeq: 14654>
> Sep 9 10:18:00 v38 /usr/local/myOpensips/sbin/opensips[24835]:
> DBG:tm:t_lookup_callid: we have a match: callid=>>Call-ID:
> .56sqM.YAwbUId0odDVrte3d6PZqa.de#015#012
> <http://56sqM.YAwbUId0odDVrte3d6PZqa.de#015#012><< cseq=>>CSeq: 14654<<
> Sep 9 10:18:00 v38 /usr/local/myOpensips/sbin/opensips[24835]:
> DBG:tm:t_lookup_callid: REF_UNSAFE:[0x7f449a0cbb00] after is 1
> Sep 9 10:18:00 v38 /usr/local/myOpensips/sbin/opensips[24835]:
> DBG:tm:t_lookup_callid: transaction found.
> Sep 9 10:18:00 v38 /usr/local/myOpensips/sbin/opensips[24835]:
> DBG:tm:mi_tm_cancel: cancelling transaction 0x7f449a0cbb00
> Sep 9 10:18:00 v38 /usr/local/myOpensips/sbin/opensips[24835]:
> DBG:tm:build_local: using FROM=<From: "Jayesh Nambiar"
> <sip:1003040 at 198.24.63.38
> <mailto:sip%3A1003040 at 198.24.63.38>>;tag=NPD-XIL90Z6yNzrktn-IZWpOgnzcJ6EZ#015#012>,
> TO=<To: <sip:1003030 at 198.24.63.38
> <mailto:sip%3A1003030 at 198.24.63.38>>#015#012>, CSEQ_N=<CSeq: 14654>
> Sep 9 10:18:00 v38 /usr/local/myOpensips/sbin/opensips[24835]:
> DBG:tm:cancel_branch: sending cancel...
> Sep 9 10:18:00 v38 /usr/local/myOpensips/sbin/opensips[24835]:
> DBG:tm:set_timer: relative timeout is 500000
> Sep 9 10:18:00 v38 /usr/local/myOpensips/sbin/opensips[24835]:
> DBG:tm:insert_timer_unsafe: [4]: 0x7f449a0cbde8 (173300000)
> Sep 9 10:18:00 v38 /usr/local/myOpensips/sbin/opensips[24835]:
> DBG:tm:insert_timer_unsafe: [0]: 0x7f449a0cbe18 (212)
> Sep 9 10:18:00 v38 /usr/local/myOpensips/sbin/opensips[24835]:
> DBG:tm:mi_tm_cancel: UNREF_UNSAFE: [0x7f449a0cbb00] after is 0
>
> Also when I use exec_msg, the opensips doesn't hang and looks like it
> works as expected. Although while using exec_msg function, it adds an
> additional parameter when executing the command at the end in a
> parentheses. For eg: my function is:
> exec_msg("/usr/local/myOpensips/sbin/opensipsctl fifo t_uac_cancel
> $avp(caller_cid) $avp(caller_cseq)");
>
> In the debug it shows command executed as:
> /usr/local/myOpensips/etc/opensips/uac_cancel.sh
> btf4RC2Z8tBlpG6eAG-hZK4cZxENCEud 8222 (23430)
>
> I'm not sure what (23430) is in the above command because of which
> most likely the t_uac_cancel fails. Because If I run this command
> directly it gives me syntax error:
> -bash: syntax error near unexpected token `('
>
> I dont even have an option to single quote that parameter as it comes
> automatically when the function is executed.
>
> --- Jayesh
>
>
> On Tue, Sep 9, 2014 at 8:22 PM, Răzvan Crainea <razvan at opensips.org
> <mailto:razvan at opensips.org>> wrote:
>
> Hi, Jayesh!
>
> Do you see any cores generated? Is there anything logged by your
> MI command?
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Solutions
> www.opensips-solutions.com <http://www.opensips-solutions.com>
>
> On 09/09/2014 05:27 PM, Jayesh Nambiar wrote:
>> Hello Razvan,
>> I extracted the source opensips-1.11.2-4c08b62_src.tar.gz created
>> on Sept 7th and tried again. This time, as soon as the exec_avp
>> command is fired, the opensips stops processing anything after
>> that. The service doesn't even stop when tried to stop cleanly.
>> It just hangs. After a minute or so, it shuts down with the
>> following in the logs:
>> Sep 9 10:23:17 v38 /usr/local/myOpensips/sbin/opensips[24832]:
>> DBG:core:pool_remove: connection still kept in the pool
>> Sep 9 10:23:17 v38 /usr/local/myOpensips/sbin/opensips[24832]:
>> DBG:core:pool_remove: removing connection from the pool
>>
>> Sep 9 10:23:17 v38 /usr/local/myOpensips/sbin/opensips[24832]:
>> DBG:core:pool_remove: removing connection from the pool
>> Sep 9 10:24:17 v38 /usr/local/myOpensips/sbin/opensips[24832]:
>> CRITICAL:core:sig_alarm_abort: BUG - shutdown timeout triggered,
>> dying...
>> Sep 9 10:24:17 v38 kernel: [24880095.291228] device eth0 left
>> promiscuous mode
>>
>> Should I try with an older stable version instead?? I think there
>> is something wrong with the way this is going. Let me know if I
>> can be of any help to troubleshoot this further.
>>
>> Thanks,
>>
>> --- Jayesh
>>
>> On Tue, Sep 9, 2014 at 7:19 PM, Răzvan Crainea
>> <razvan at opensips.org <mailto:razvan at opensips.org>> wrote:
>>
>> Can you please update your sources? Bogdan made a fixon 24th
>> of August that might be related to this.
>>
>> Best regards,
>>
>> Răzvan Crainea
>> OpenSIPS Solutions
>> www.opensips-solutions.com <http://www.opensips-solutions.com>
>>
>> On 09/09/2014 04:42 PM, Jayesh Nambiar wrote:
>>> Hello Razvan,
>>> I am running 1.11.2 extracted from the following source file:
>>> opensips-1.11.2-4fda9a1_src.tar.gz
>>>
>>> A little more background on the problem:
>>> The caller is connected on TCP and relayed over UDP. The
>>> transaction that I am trying to cancel is an UDP
>>> transaction. I dont believe this should have any concern
>>> with the problem I'm facing but still mentioning. Basically
>>> I want to cancel this transaction, get the caller into the
>>> failure route and relay it to a different destination !!
>>>
>>> Thanks for the prompt replies.
>>>
>>> --- Jayesh
>>>
>>> On Tue, Sep 9, 2014 at 7:07 PM, Răzvan Crainea
>>> <razvan at opensips.org <mailto:razvan at opensips.org>> wrote:
>>>
>>> Hi, Jayesh!
>>>
>>> No, it should not be present. It is created by
>>> opensipsctl when a command is issued. What version of
>>> OpenSIPS are you running?
>>>
>>> Best regards,
>>>
>>> Răzvan Crainea
>>> OpenSIPS Solutions
>>> www.opensips-solutions.com <http://www.opensips-solutions.com>
>>>
>>> On 09/09/2014 04:30 PM, Jayesh Nambiar wrote:
>>>> Hi,
>>>> Just as an update, I only see opensips_fifo in the
>>>> /tmp/ directory. Is the opensips_receiver supposed to
>>>> be present??
>>>>
>>>> --- Jayesh
>>>>
>>>> On Tue, Sep 9, 2014 at 6:49 PM, Jayesh Nambiar
>>>> <jayesh1017 at gmail.com <mailto:jayesh1017 at gmail.com>> wrote:
>>>>
>>>> Yes, running opensips with user root. Still the
>>>> same problem.
>>>>
>>>> --- Jayesh
>>>>
>>>> On Tue, Sep 9, 2014 at 6:22 PM, Răzvan Crainea
>>>> <razvan at opensips.org <mailto:razvan at opensips.org>>
>>>> wrote:
>>>>
>>>> Hi, Jayesh!
>>>>
>>>> I think there is a permissions issue here. What
>>>> is the user you are running opensips with? Is
>>>> it the same as the one you are trying to
>>>> execute the shell script?
>>>>
>>>> Best regards,
>>>>
>>>> Răzvan Crainea
>>>> OpenSIPS Solutions
>>>> www.opensips-solutions.com <http://www.opensips-solutions.com>
>>>>
>>>> On 09/09/2014 03:44 PM, Jayesh Nambiar wrote:
>>>>> Hello,
>>>>> I try to cancel a running transaction in
>>>>> opensips based on certain conditions. When I
>>>>> try this from the script:
>>>>> exec_avp("/usr/local/myOpensips/sbin/opensipsctl
>>>>> fifo t_uac_cancel $avp(caller_cid)
>>>>> $avp(caller_cseq)", "$avp(result)");
>>>>> The callid and cseq is properly substituted in
>>>>> the appropriate AVPs.
>>>>> I get, ** ERROR: error opening read fifo
>>>>> /tmp/opensips_receiver_24405 in the resulting
>>>>> AVP. Whereas when I run this command directly
>>>>> from my shell it runs fine and cancels the
>>>>> transaction as expected.
>>>>> Tried to google around the problem and
>>>>> couldn't find much. I read about some selinux
>>>>> thing that might block opensips from executing
>>>>> the MI command, but I'm pretty sure selinux is
>>>>> disabled on my machine. Where else do I look
>>>>> for a fix such that my script is able to
>>>>> execute this !!
>>>>>
>>>>> Thanks in advance for any pointers.
>>>>>
>>>>> --- Jayesh
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> <mailto:Users at lists.opensips.org>
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
> _______________________________________________
> 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/20140909/24cdf5cd/attachment-0001.htm>
More information about the Users
mailing list