sr-dev November 2009

sr-dev@lists.kamailio.org

30 participants
177 discussions

inadequate error messages
by jh＠tutpro.com 14 Nov '09

14 Nov '09

while testing some new stuff, i tried to start sr and got the following: Nov 14 06:14:12 localhost /usr/sbin/sip-proxy[17677]: ERROR: <core> [pvapi.c:430]: bad parameters Nov 14 06:14:12 localhost /usr/sbin/sip-proxy[17677]: ERROR: avpops [avpops.c:936]: unable to get pseudo-variable in param that does not tell anything about where in config the error occurred. it is impossible to get a config line number or some more info printed? -- juha

1 0

SHM memory usage Kamailio 1.4.4
by Robin Vleij 12 Nov '09

12 Nov '09

Hi guys, Since 1.3.0 (now running 1.4.4) I'm seeing a very slow uptake of SHM memory on our low traffic setup (less than 5 cps per machine). I'm looking for some basis to go further on in my research to the cause. :) I compiled Kamailio 1.4.4-notls with #define SHM_MEM_SIZE 4*32 in config.h in production. For my testing setup I'm running on the standard 32 there. After about 3 weeks uptime I start top, sort on memory size and find the kamailio processes (I'm running with 16 children) to all have about 40mb in the SHR column. My understanding is that this should also go down, but it only goes up, slowly. More CPS (for example a benchmark using sipp) makes this go up faster, but it never seems to go down this figure. I think this is wrong, but I could be wrong myself. :) On a seperate machine with no traffic I compiled the memory debugging according to the "memory troubleshooting" page on the wiki. LOTS of info in the logs. Also ran with valgrind, didn't find anything interesting (but I'm no dev myself really). My plan now is to take away our acc module (compiled with radius support) and see if it's maybe that module that's causing this. My test on this traffic-less machine is as follows: start, run 20cps for a while (we do no registers, just routing and auth) and note the SHR data from top. Then according to my understanding this figure should drop down after a period of 20 minutes with no traffic. Is this a right assumption? On the test setup the top data looks like this after about 10 calls: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 15975 root 18 0 69240 1536 568 S 0.0 0.6 0:00.00 kamailio 15972 root 18 0 69240 1568 588 S 0.0 0.6 0:00.00 kamailio 15970 root 18 0 69240 1568 588 S 0.0 0.6 0:00.00 kamailio 15969 root 19 0 69244 1488 568 S 0.0 0.6 0:00.00 kamailio 15968 root 15 0 69240 1860 936 S 0.0 0.7 0:00.00 kamailio 15967 root 15 0 71436 3376 2268 S 0.0 1.3 0:00.00 kamailio 15966 root 15 0 71436 3396 2288 S 0.0 1.3 0:00.00 kamailio 15965 root 23 0 69240 5552 4640 S 0.0 2.1 0:00.02 kamailio As far as I know, it never goes down, the SHR entries. When running with very little SHM i config.h, the process goes out of shm memory and complains, as expected. Are my assumptions about all of this correct? -- Robin Vleij robin(a)swip.net

2 6

git:sr_3.0: sctp rpc: core.sctp_options debugging version
by Andrei Pelinescu-Onciul 12 Nov '09

12 Nov '09

Module: sip-router Branch: sr_3.0 Commit: 44226358e60f5b69a4c383c892003ad2226c9089 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=4422635… Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Date: Thu Nov 12 16:29:40 2009 +0100 sctp rpc: core.sctp_options debugging version core.sctp_options can now have 1 optional parameter. If the parameter is missing it works as before: displays ser's idea of all the sctp config options. If the parameter is present it should have one of the following values: "default" (default send socket), "first" (first sctp socket) or addr[:port]. In this case the kernel sctp options for that particular socket will be displayed, with 0 used for the options that are userspace only. E.g.: sercmd core.sctp_options 127.0.0.1 --- core_cmd.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--- 1 files changed, 54 insertions(+), 3 deletions(-) diff --git a/core_cmd.c b/core_cmd.c index bc2bd13..42bfd58 100644 --- a/core_cmd.c +++ b/core_cmd.c @@ -647,7 +647,13 @@ static void core_tcp_options(rpc_t* rpc, void* c) static const char* core_sctp_options_doc[] = { - "Returns active sctp options.", /* Documentation string */ + "Returns active sctp options. With one parameter" + " it returns the sctp options set in the kernel for a specific socket" + "(debugging), with 0 filled in for non-kernel related options." + " The parameter can be: \"default\" | \"first\" | address[:port] ." + " With no parameters it returns ser's idea of the current sctp options" + " (intended non-debugging use).", + /* Documentation string */ 0 /* Method signature(s) */ }; @@ -656,9 +662,54 @@ static void core_sctp_options(rpc_t* rpc, void* c) #ifdef USE_SCTP void *handle; struct cfg_group_sctp t; - + char* param; + struct socket_info* si; + char* host; + str hs; + int hlen; + int port; + int proto; + + param=0; if (!sctp_disable){ - sctp_options_get(&t); + /* look for optional socket parameter */ + if (rpc->scan(c, "*s", &param)>0){ + si=0; + if (strcasecmp(param, "default")==0){ + si=sendipv4_sctp?sendipv4_sctp:sendipv6_sctp; + }else if (strcasecmp(param, "first")==0){ + si=sctp_listen; + }else{ + if (parse_phostport(param, &host, &hlen, &port, &proto)!=0){ + rpc->fault(c, 500, "bad param (use address, address:port," + " default or first)"); + return; + } + if (proto && proto!=PROTO_SCTP){ + rpc->fault(c, 500, "bad protocol in param (only SCTP" + " allowed)"); + return; + } + hs.s=host; + hs.len=hlen; + si=grep_sock_info(&hs, port, PROTO_SCTP); + if (si==0){ + rpc->fault(c, 500, "not listening on sctp %s", param); + return; + } + } + if (si==0 || si->socket==-1){ + rpc->fault(c, 500, "could not find a sctp socket"); + return; + } + memset(&t, 0, sizeof(t)); + if (sctp_get_cfg_from_sock(si->socket, &t)!=0){ + rpc->fault(c, 500, "failed to get socket options"); + return; + } + }else{ + sctp_options_get(&t); + } rpc->add(c, "{", &handle); rpc->struct_add(handle, "ddddddddddddddddddd", "sctp_socket_rcvbuf", t.so_rcvbuf,

1 0

git:sr_3.0: core rpc: core.shmmem can take an optional size parameter
by Andrei Pelinescu-Onciul 12 Nov '09

12 Nov '09

Module: sip-router Branch: sr_3.0 Commit: 02eec212e4eaf999de4162287232c172760ca9d4 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=02eec21… Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Date: Thu Nov 12 17:24:27 2009 +0100 core rpc: core.shmmem can take an optional size parameter core.shmmem can take now an optional size parameter, which can have one of the following values: b - bytes, k or kb - kilobytes, m or mb - megabytes, g or gb - gigabytes. By default (no parameter) the values displayed are in bytes. Note that when using something different from bytes the value are truncated (no floating point). The new parameter can be used as workaround on 64 bits systems when sr is started with more then 2Gb of memory (due to the RPC interface limitation to int32 in this case the values displayed would be negative or 0). E.g: sercmd> core.shmmem k --- core_cmd.c | 47 ++++++++++++++++++++++++++++++++++++++++------- 1 files changed, 40 insertions(+), 7 deletions(-) diff --git a/core_cmd.c b/core_cmd.c index 42bfd58..8533802 100644 --- a/core_cmd.c +++ b/core_cmd.c @@ -435,21 +435,54 @@ static void core_shmmem(rpc_t* rpc, void* c) { struct mem_info mi; void *handle; - + char* param; + long rs; + + rs=0; + /* look for optional size/divisor parameter */ + if (rpc->scan(c, "*s", &param)>0){ + switch(*param){ + case 'b': + case 'B': + rs=0; + break; + case 'k': + case 'K': + rs=10; /* K -> 1024 */ + break; + case 'm': + case 'M': + rs=20; /* M -> 1048576 */ + break; + case 'g': + case 'G': + rs=30; /* G -> 1024M */ + break; + default: + rpc->fault(c, 500, "bad param, (use b|k|m|g)"); + return; + } + if (param[1] && ((param[1]!='b' && param[1]!='B') || param[2])){ + rpc->fault(c, 500, "bad param, (use b|k|m|g)"); + return; + } + } shm_info(&mi); rpc->add(c, "{", &handle); rpc->struct_add(handle, "dddddd", - "total", (unsigned int)mi.total_size, - "free", (unsigned int)mi.free, - "used", (unsigned int)mi.used, - "real_used",(unsigned int)mi.real_used, - "max_used", (unsigned int)mi.max_used, + "total", (unsigned int)(mi.total_size>>rs), + "free", (unsigned int)(mi.free>>rs), + "used", (unsigned int)(mi.used>>rs), + "real_used",(unsigned int)(mi.real_used>>rs), + "max_used", (unsigned int)(mi.max_used>>rs), "fragments", (unsigned int)mi.total_frags ); } static const char* core_shmmem_doc[] = { - "Returns shared memory info.", /* Documentation string */ + "Returns shared memory info. It has an optional parameter that specifies" + " the measuring unit: b - bytes (default), k or kb, m or mb, g or gb. " + "Note: when using something different from bytes, the value is truncated.", 0 /* Method signature(s) */ };

1 0

git:sr_3.0: sctp: workaround SCTP_DELAYED_SACK lksctp typo
by Andrei Pelinescu-Onciul 12 Nov '09

12 Nov '09

Module: sip-router Branch: sr_3.0 Commit: cc16495666e948f2c18dc0bacebecfac85ff59a5 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=cc16495… Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Date: Thu Nov 12 16:24:08 2009 +0100 sctp: workaround SCTP_DELAYED_SACK lksctp typo - workaround typo in linux libsctp api: SCTP_DELAYED_ACK is used/defined instead of SCTP_DELAYED_SACK. - to support older kernels (< 2.6.27), if setting/getting the socket options with SCTP_DELAYED_SACK fails, fallback to SCTP_DELAYED_ACK_TIME for sctp sack_delay and report an error if the user tries to set sack_freq (not supported on older kernels). - split sctp_get_os_default() into sctp_get_os_default() and sctp_get_cfg_from_sock() for debugging purposes. --- sctp_options.c | 48 ++++++++++++----- sctp_options.h | 1 + sctp_server.c | 156 +++++++++++++++++++++++++++++++++++++------------------ sctp_sockopts.h | 44 +++++++++++++++ 4 files changed, 185 insertions(+), 64 deletions(-) Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=cc1…

1 0

do_action error
by Juha Heinanen 12 Nov '09

12 Nov '09

just when i mentioned in previous email that i don't currently have any known problems with sr_3.0, a new one hit me. script calls next_gw(), which results in errors: Nov 12 07:35:24 localhost /usr/sbin/sip-proxy[5495]: INFO: lcr [lcr_mod.c:2062]: appending branch <sip:110415036078@192.98.101.1:5060> Nov 12 07:35:24 localhost /usr/sbin/sip-proxy[5495]: : <core> [action.c:344]: BUG: do_action: bad append_branch_t 1 Nov 12 07:35:24 localhost /usr/sbin/sip-proxy[5495]: ERROR: <core> [action.c:1251]: run action error at: :0 Nov 12 07:35:24 localhost /usr/sbin/sip-proxy[5495]: ERROR: lcr [lcr_mod.c:2065]: do_action failed with return value <-5> the piece of code where the errors comes is this: uri_str.s = r_uri; uri_str.len = r_uri_len; memset(&act, '\0', sizeof(act)); act.type = APPEND_BRANCH_T; act.val[0].type = STRING_ST; act.val[0].u.str = uri_str; act.val[1].type = NUMBER_ST; act.val[1].u.number = 0; init_run_actions_ctx(&ra_ctx); LM_INFO("appending branch <%.*s>\n", uri_str.len, uri_str.s); rval = do_action(&ra_ctx, &act, _m); if (rval != 1) { LM_ERR("do_action failed with return value <%d>\n", rval); return -1; } } i added the LM_INFO in order to verify validity of the uri and it looks ok to me. is this some new bug or what? i haven't seen it earlier although i have been running the same tests. -- juha

3 5

SCTP warnings
by jh＠tutpro.com 12 Nov '09

12 Nov '09

when i start sr, i get to syslog Nov 12 07:20:55 localhost kernel: [ 1472.803444] SCTP: Use of struct sctp_assoc_value in delayed_ack socket option deprecated Nov 12 07:20:55 localhost kernel: [ 1472.803460] SCTP: Use struct sctp_sack_info instead any idea what to do in order to get rid of them? -- juha ps. i don't currently have any bigger problems with sr_3.0.

3 2

git:sr_3.0: modules/lcr: use append_branch instead of do_action for appending branch
by Juha Heinanen 12 Nov '09

12 Nov '09

Module: sip-router Branch: sr_3.0 Commit: e3a8a650f6b3c7a63d200c443f82c1494f6f4e07 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=e3a8a65… Author: Juha Heinanen <jh(a)tutpro.com> Committer: Juha Heinanen <jh(a)tutpro.com> Date: Thu Nov 12 08:11:57 2009 +0200 modules/lcr: use append_branch instead of do_action for appending branch For some reason appending branch using do_action had stopped working. Instead of trying to find out why, replaced do_action() call with append_branch() call. --- modules/lcr/lcr_mod.c | 13 +++---------- 1 files changed, 3 insertions(+), 10 deletions(-) diff --git a/modules/lcr/lcr_mod.c b/modules/lcr/lcr_mod.c index 2b6c719..7eb3747 100644 --- a/modules/lcr/lcr_mod.c +++ b/modules/lcr/lcr_mod.c @@ -2052,16 +2052,9 @@ static int next_gw(struct sip_msg* _m, char* _s1, char* _s2) * failure route block => append new branch. */ uri_str.s = r_uri; uri_str.len = r_uri_len; - memset(&act, '\0', sizeof(act)); - act.type = APPEND_BRANCH_T; - act.val[0].type = STRING_ST; - act.val[0].u.str = uri_str; - act.val[1].type = NUMBER_ST; - act.val[1].u.number = 0; - init_run_actions_ctx(&ra_ctx); - rval = do_action(&ra_ctx, &act, _m); - if (rval != 1) { - LM_ERR("do_action failed with return value <%d>\n", rval); + LM_DBG("appending branch <%.*s>\n", uri_str.len, uri_str.s); + if (append_branch(_m, &uri_str, 0, 0, Q_UNSPECIFIED, 0, 0) == -1) { + LM_ERR("when appending branch <%.*s>\n", rval); return -1; } }

1 0

debian problem with todays sr_3.0 branch
by Klaus Darilion 11 Nov '09

11 Nov '09

# install /etc/default/ser file mkdir -p /home/darilion/software/sip-router-git-repo/debian/ser/etc/default cp -f debian/ser.default /home/darilion/software/sip-router-git-repo/debian/ser/etc/default/ser # install the *.sql files for ser_mysql.sh script cp -f scripts/mysql/*.sql /home/darilion/software/sip-router-git-repo/debian/ser/usr/lib/ser/ # and fix path to the *.sql files in ser_mysql.sh script sed -i 's#DEFAULT_SCRIPT_DIR=.*#DEFAULT_SCRIPT_DIR="/usr/lib/ser/"#' \ /home/darilion/software/sip-router-git-repo/debian/ser/usr/sbin/ser_mysql.sh sed: can't read /home/darilion/software/sip-router-git-repo/debian/ser/usr/sbin/ser_mysql.sh: No such file or directory make[1]: *** [install] Error 2 make[1]: Leaving directory `/home/darilion/software/sip-router-git-repo' dpkg-buildpackage: failure: fakeroot debian/rules binary gave error exit status 2 cheers klaus

2 2

git:sr_3.0: deb: fix mysql scripts install path problem
by Andrei Pelinescu-Onciul 11 Nov '09

11 Nov '09

Module: sip-router Branch: sr_3.0 Commit: cc88ded53d3ba8e8140390f33f3759a127ad9dbd URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=cc88ded… Author: Klaus Darilion <klaus.mailinglists(a)pernau.at> Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Date: Wed Nov 11 19:52:55 2009 +0100 deb: fix mysql scripts install path problem Signed-off-by: Andrei Pelinescu-Onciul <andrei(a)iptel.org> --- pkg/debian/rules | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/pkg/debian/rules b/pkg/debian/rules index 289ec3e..3d708f3 100755 --- a/pkg/debian/rules +++ b/pkg/debian/rules @@ -179,10 +179,10 @@ install: build mkdir -p $(CURDIR)/debian/ser/etc/default cp -f debian/ser.default $(CURDIR)/debian/ser/etc/default/ser # install the *.sql files for ser_mysql.sh script - cp -f scripts/mysql/*.sql $(CURDIR)/debian/ser/usr/lib/ser/ + cp -f scripts/mysql/*.sql $(CURDIR)/debian/ser-mysql-module/usr/lib/ser/ # and fix path to the *.sql files in ser_mysql.sh script sed -i 's#DEFAULT_SCRIPT_DIR=.*#DEFAULT_SCRIPT_DIR="/usr/lib/ser/"#' \ - $(CURDIR)/debian/ser/usr/sbin/ser_mysql.sh + $(CURDIR)/debian/ser-mysql-module/usr/sbin/ser_mysql.sh # install advanced ser config file for ser-oob package mkdir -p $(CURDIR)/debian/ser-oob/etc/ser cp -f etc/sip-router-oob.cfg $(CURDIR)/debian/ser-oob/etc/ser/ser-oob.cfg

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
18
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev November 2009