Hello Razvan, An update to the above problem: I re-installed opensips without prefix based installation and the exec_avp for t_uac_cancel worked fine as expected. No permission errors anywhere !! I used to install opensips directly using the following: make prefix=/usr/local/myOpensips include_modules="db_mysql cachedb_redis json rest_client" make prefix=/usr/local/myOpensips include_modules="db_mysql cachedb_redis json rest_client" install.
Is the above method no longer supported or somethig?? Thanks, --- Jayesh On Wed, Sep 10, 2014 at 1:55 PM, Jayesh Nambiar <[email protected]> wrote: > Hello, > Just an update, when I ran exec_msg function with modparam("exec", > "async", 0), the behaviour was same as exec_avp function. Basically, > opensips logs stay at forked_pid and nothing else works after that. No SIP > request is processed. > > --- Jayesh > > On Tue, Sep 9, 2014 at 8:41 PM, Jayesh Nambiar <[email protected]> > 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' '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> >> 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%23012>< >> 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%23012>> <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%23012><< 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:[email protected]>;tag=NPD-XIL90Z6yNzrktn-IZWpOgnzcJ6EZ#015#012>, >> TO=<To: <sip:[email protected]>#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 <[email protected]> >> wrote: >> >>> Hi, Jayesh! >>> >>> Do you see any cores generated? Is there anything logged by your MI >>> command? >>> >>> Best regards, >>> >>> Răzvan Crainea >>> OpenSIPS Solutionswww.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 <[email protected]> >>> wrote: >>> >>>> Can you please update your sources? Bogdan made a fix on 24th of August >>>> that might be related to this. >>>> >>>> Best regards, >>>> >>>> Răzvan Crainea >>>> OpenSIPS Solutionswww.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 <[email protected]> >>>> 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 Solutionswww.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 <[email protected]> >>>>> wrote: >>>>> >>>>>> Yes, running opensips with user root. Still the same problem. >>>>>> >>>>>> --- Jayesh >>>>>> >>>>>> On Tue, Sep 9, 2014 at 6:22 PM, Răzvan Crainea <[email protected]> >>>>>> 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 Solutionswww.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 >>>>>>> [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 >>>>> [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 >>>> [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 >>> [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
