sr-dev March 2014

sr-dev@lists.kamailio.org

29 participants
299 discussions

git:4.1: kamctl: delete former fifo files if they exist
by Daniel-Constantin Mierla 03 Mar '14

03 Mar '14

Module: sip-router Branch: 4.1 Commit: 92aaaab324b37d75358b21825850ade8a3481cd5 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=92aaaab… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Mon Mar 3 14:39:25 2014 +0100 kamctl: delete former fifo files if they exist - reported by Morten Tryfoss, FS#399 (cherry picked from commit ec9e735955f58ef21bac21ba57eafd07db675e4d) --- utils/kamctl/kamctl.fifo | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/utils/kamctl/kamctl.fifo b/utils/kamctl/kamctl.fifo index 50c8e92..e57c7df 100644 --- a/utils/kamctl/kamctl.fifo +++ b/utils/kamctl/kamctl.fifo @@ -57,6 +57,10 @@ fifo_cmd() fi name=kamailio_receiver_$$ path=$CHROOT_DIR/tmp/$name + # delete existing fifo file with same name + if test -p $path; then + rm -f $path + fi if [ ! -w $FIFOPATH ]; then merr "Error opening Kamailio's FIFO $FIFOPATH" merr "Make sure you have the line 'modparam(\"mi_fifo\", \"fifo_name\", \"$FIFOPATH\")' in your config" @@ -106,6 +110,10 @@ CTLCMD=fifo_cmd fifo_kamailio_monitor() { name=kamailio_receiver_$$ path=$CHROOT_DIR/tmp/$name + # delete existing fifo file with same name + if test -p $path; then + rm -f $path + fi if [ ! -w $FIFOPATH ]; then merr "Error opening Kamailio's FIFO $FIFOPATH" merr "Make sure you have the line 'modparam(\"mi_fifo\", \"fifo_name\", \"$FIFOPATH\")' in your config"

1 0

git:master: kamctl: delete former fifo files if they exist
by Daniel-Constantin Mierla 03 Mar '14

03 Mar '14

Module: sip-router Branch: master Commit: ec9e735955f58ef21bac21ba57eafd07db675e4d URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=ec9e735… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Mon Mar 3 14:39:25 2014 +0100 kamctl: delete former fifo files if they exist - reported by Morten Tryfoss, FS#399 --- utils/kamctl/kamctl.fifo | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/utils/kamctl/kamctl.fifo b/utils/kamctl/kamctl.fifo index 50c8e92..e57c7df 100644 --- a/utils/kamctl/kamctl.fifo +++ b/utils/kamctl/kamctl.fifo @@ -57,6 +57,10 @@ fifo_cmd() fi name=kamailio_receiver_$$ path=$CHROOT_DIR/tmp/$name + # delete existing fifo file with same name + if test -p $path; then + rm -f $path + fi if [ ! -w $FIFOPATH ]; then merr "Error opening Kamailio's FIFO $FIFOPATH" merr "Make sure you have the line 'modparam(\"mi_fifo\", \"fifo_name\", \"$FIFOPATH\")' in your config" @@ -106,6 +110,10 @@ CTLCMD=fifo_cmd fifo_kamailio_monitor() { name=kamailio_receiver_$$ path=$CHROOT_DIR/tmp/$name + # delete existing fifo file with same name + if test -p $path; then + rm -f $path + fi if [ ! -w $FIFOPATH ]; then merr "Error opening Kamailio's FIFO $FIFOPATH" merr "Make sure you have the line 'modparam(\"mi_fifo\", \"fifo_name\", \"$FIFOPATH\")' in your config"

1 0

[tracker] Task changed: Potential issue with kamctl
by sip-router 03 Mar '14

03 Mar '14

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has been changed. The changes are listed below. For full information about what has changed, visit the URL and click the History tab. FS#399 - Potential issue with kamctl User who did this: Daniel-Constantin Mierla (miconda) Task details edited: ------- There seems to be a potential issue with kamctl.fifo if a script crashes for some reason. The file /tmp/kamailio_receiver_<pid> might be left again after script finish, and this causes kamctl to fail next time it runs with that pid: Feb 24 07:04:45 bnsip1ha /usr/sbin/kamailio[16767]: ERROR: mi_fifo [fifo_fnc.c:224]: mi_open_reply_pipe(): open error (/tmp/kamailio_receiver_16613): Permission denied Feb 24 07:04:45 bnsip1ha /usr/sbin/kamailio[16767]: ERROR: mi_fifo [fifo_fnc.c:488]: mi_fifo_server(): cannot open reply pipe /tmp/kamailio_receiver_16613 Feb 24 07:04:48 bnsip1ha kamailio(kamailio)[16605]: WARNING: Kamailio is not up according to kamctl monitor! This is not critical at all, but we use "kamctl monitor" from heartbeat for health checking. Would it be safe to add this to the start of kamctl.fifo, to clean up files that are not deleted? <code>name=kamailio_receiver_$$ path=$CHROOT_DIR/tmp/$name if test -p $path; then rm $path fi</code> ------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=399 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

1 0

[tracker] Comment added: Kamailio doesn't to handle any SIP message at all after several dialogs... (CPU high usage)
by sip-router 03 Mar '14

03 Mar '14

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#397 - Kamailio doesn't to handle any SIP message at all after several dialogs... (CPU high usage) User who did this - Daniel-Constantin Mierla (miconda) ---------- A recent similar situation ended up in discovering that the Makefile config options were given incorrect. On option to try is to compile with system mutex locks instead of the internal fast locks. See the Makefile.defs for options to set. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=397#comment1325 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

1 0

[tracker] Comment added: Coredump on using jsonrpc_request
by sip-router 03 Mar '14

03 Mar '14

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#404 - Coredump on using jsonrpc_request User who did this - davy van de moere (davyvdm) ---------- Ack, I'll test it on Wednesday. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=404#comment1324 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

1 0

[tracker] Comment added: Improvement for db_cluster (Attachment added)
by sip-router 03 Mar '14

03 Mar '14

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#405 - Improvement for db_cluster User who did this - Morten Tryfoss (mtryfoss) ---------- Here is the new patch. ---------- One or more files have been attached. More information can be found at the following URL: https://sip-router.org/tracker/index.php?do=details&task_id=405#comment1323 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

1 0

[tracker] Comment added: Improvement for db_cluster
by sip-router 03 Mar '14

03 Mar '14

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#405 - Improvement for db_cluster User who did this - Daniel-Constantin Mierla (miconda) ---------- Thanks for the contribution. The updates to the readme have to be done xml docbook files located in modules/db_cluster/doc/. Generating the readme is via: <code>make modules-readme modules=modules/db_cluster</code> If you don't have the tools installed, we can generate the readme. But the patch has to be with the changes to the docbook files. Can you redo the patch accordingly? ---------- More information can be found at the following URL: https://sip-router.org/tracker/index.php?do=details&task_id=405#comment1322 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

1 0

[tracker] Task opened: Improvement for db_cluster (Attachment added)
by sip-router 03 Mar '14

03 Mar '14

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Morten Tryfoss (mtryfoss) Attached to Project - sip-router Summary - Improvement for db_cluster Task Type - Improvement Category - Module Status - Unconfirmed Assigned To - Operating System - All Severity - Medium Priority - Normal Reported Version - 4.1 Due in Version - Undecided Due Date - Undecided Details - I've been testing db_cluster for a while. The goal is to always be sure that kamailio got a responsive db backend. We run db_cluster with parallell write and serial read for mainly auth and registrar functionality. This works well in normal situations, but the error handler is not very good. For example, a primary key insert that fails will disable the connection from the pool for "inactive_interval" of time. Of course the best would be to ignore specific error codes, but that is a pretty large job. This patch tries to address this problem by introducing a new parameter: max_query_length It will not change the timout of the query, but only disable the connection from the pool if a failed query has been running for more than "max_query_length" seconds. In my opinion we don't need to disable a connection if it is responsive. Please have a look and give feedback. One or more files have been attached. More information can be found at the following URL: https://sip-router.org/tracker/index.php?do=details&task_id=405 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

1 0

[tracker] Comment added: Kamailio doesn't to handle any SIP message at all after several dialogs... (CPU high usage)
by sip-router 03 Mar '14

03 Mar '14

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#397 - Kamailio doesn't to handle any SIP message at all after several dialogs... (CPU high usage) User who did this - Jack Wang (GoGoJack) ---------- I found it's similar to the following issue: http://lists.kamailio.org/pipermail/sr-dev/2010-March/006629.html but it appears that there's no solution with the problem... Btw, it also happens in debug mode finally - after I take more time to run my work. have any idea?? ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=397#comment1321 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

1 0

git:master: tm: t_continue() polishing
by Daniel-Constantin Mierla 02 Mar '14

02 Mar '14

Module: sip-router Branch: master Commit: 47f6cfd76a9d801a83ca14b55926d389f6c3c2da URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=47f6cfd… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Sun Mar 2 15:40:17 2014 +0100 tm: t_continue() polishing - variables declared at beginning of function to work on old C standard compilers - log messages compacted - function name and log level are prefixed automatically - stay under 80 chars per line to fit in text terminals --- modules/tm/t_suspend.c | 50 +++++++++++++++++++++++++---------------------- 1 files changed, 27 insertions(+), 23 deletions(-) diff --git a/modules/tm/t_suspend.c b/modules/tm/t_suspend.c index 29a94d7..119b98a 100644 --- a/modules/tm/t_suspend.c +++ b/modules/tm/t_suspend.c @@ -163,9 +163,14 @@ int t_continue(unsigned int hash_index, unsigned int label, struct ua_client *uac =NULL; int ret; int cb_type; + int msg_status; + int last_uac_status; + int reply_status; + int do_put_on_wait; + struct hdr_field *hdr, *prev = 0, *tmp = 0; if (t_lookup_ident(&t, hash_index, label) < 0) { - LOG(L_ERR, "ERROR: t_continue: transaction not found\n"); + LM_ERR("transaction not found\n"); return -1; } @@ -231,7 +236,7 @@ int t_continue(unsigned int hash_index, unsigned int label, /* fake the request and the environment, like in failure_route */ if (!fake_req(&faked_req, t->uas.request, 0 /* extra flags */, uac)) { - LOG(L_ERR, "ERROR: t_continue: fake_req failed\n"); + LM_ERR("building fake_req failed\n"); ret = -1; goto kill_trans; } @@ -240,7 +245,7 @@ int t_continue(unsigned int hash_index, unsigned int label, /* execute the pre/post -script callbacks based on original route block */ if (exec_pre_script_cb(&faked_req, cb_type)>0) { if (run_top_route(route, &faked_req, 0)<0) - LOG(L_ERR, "ERROR: t_continue: Error in run_top_route\n"); + LM_ERR("failure inside run_top_route\n"); exec_post_script_cb(&faked_req, cb_type); } @@ -273,39 +278,37 @@ int t_continue(unsigned int hash_index, unsigned int label, } } - }else{ + } else { branch = t->async_backup.backup_branch; init_cancel_info(&cancel_data); - LOG(L_DBG,"DEBUG: t_continue_reply: This a continue from a reply suspend\n"); - /* this is a continue from a reply suspend */ + LM_DBG("continuing from a suspended reply" + " - resetting the suspend branch flag\n"); - LOG(L_DBG,"DEBUG: t_continue_reply: Disabling suspend branch"); t->uac[branch].reply->msg_flags &= ~FL_RPL_SUSPENDED; if (t->uas.request) t->uas.request->msg_flags&= ~FL_RPL_SUSPENDED; faked_env( t, t->uac[branch].reply, 1); - LOG(L_DBG,"DEBUG: Running pre script\n"); if (exec_pre_script_cb(t->uac[branch].reply, cb_type)>0) { if (run_top_route(route, t->uac[branch].reply, 0)<0){ LOG(L_ERR, "ERROR: t_continue_reply: Error in run_top_route\n"); } - LOG(L_DBG,"DEBUG: t_continue_reply: Running exec post script\n"); exec_post_script_cb(t->uac[branch].reply, cb_type); } - LOG(L_DBG,"DEBUG: t_continue_reply: Restoring previous environment"); + LM_DBG("restoring previous environment"); faked_env( t, 0, 1); - int reply_status; - /*lock transaction replies - will be unlocked when reply is relayed*/ LOCK_REPLIES( t ); if ( is_local(t) ) { - LOG(L_DBG,"DEBUG: t_continue_reply: t is local sending local reply with status code: [%d]\n", t->uac[branch].reply->first_line.u.reply.statuscode); - reply_status = local_reply( t, t->uac[branch].reply, branch, t->uac[branch].reply->first_line.u.reply.statuscode, &cancel_data ); + LM_DBG("t is local - sending reply with status code: [%d]\n", + t->uac[branch].reply->first_line.u.reply.statuscode); + reply_status = local_reply( t, t->uac[branch].reply, branch, + t->uac[branch].reply->first_line.u.reply.statuscode, + &cancel_data ); if (reply_status == RPS_COMPLETED) { /* no more UAC FR/RETR (if I received a 2xx, there may * be still pending branches ... @@ -322,12 +325,15 @@ int t_continue(unsigned int hash_index, unsigned int label, } } else { - LOG(L_DBG,"DEBUG: t_continue_reply: t is NOT local sending relaying reply with status code: [%d]\n", t->uac[branch].reply->first_line.u.reply.statuscode); - int do_put_on_wait = 0; + LM_DBG("t is not local - relaying reply with status code: [%d]\n", + t->uac[branch].reply->first_line.u.reply.statuscode); + do_put_on_wait = 0; if(t->uac[branch].reply->first_line.u.reply.statuscode>=200){ do_put_on_wait = 1; } - reply_status=relay_reply( t, t->uac[branch].reply, branch, t->uac[branch].reply->first_line.u.reply.statuscode, &cancel_data, do_put_on_wait ); + reply_status=relay_reply( t, t->uac[branch].reply, branch, + t->uac[branch].reply->first_line.u.reply.statuscode, + &cancel_data, do_put_on_wait ); if (reply_status == RPS_COMPLETED) { /* no more UAC FR/RETR (if I received a 2xx, there may be still pending branches ... @@ -356,8 +362,8 @@ int t_continue(unsigned int hash_index, unsigned int label, /* update FR/RETR timers on provisional replies */ - int msg_status=t->uac[branch].reply->REPLY_STATUS; - int last_uac_status=t->uac[branch].last_received; + msg_status=t->uac[branch].reply->REPLY_STATUS; + last_uac_status=t->uac[branch].last_received; if (is_invite(t) && msg_status<200 && ( cfg_get(tm, tm_cfg, restart_fr_on_each_reply) || @@ -376,9 +382,7 @@ done: if(t->async_backup.backup_route != TM_ONREPLY_ROUTE){ /* unref the transaction */ t_unref(t->uas.request); - }else{ - struct hdr_field *hdr, *prev = 0, *tmp = 0; - + } else { tm_ctx_set_branch_index(T_BR_UNDEFINED); /* unref the transaction */ t_unref(t->uac[branch].reply); @@ -441,7 +445,7 @@ kill_trans: if(t->async_backup.backup_route != TM_ONREPLY_ROUTE){ t_unref(t->uas.request); - }else{ + } else { /* unref the transaction */ t_unref(t->uac[branch].reply); }

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev March 2014