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"
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.
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.
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.
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.
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.
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.
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.
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);
}