The default transaction level in p_usrloc is `READ UNCOMMITED`.
Since the correct spelling is `commiTTed`, this default transaction level `read uncommiTed` is not accepted by databases.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3324
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3324(a)github.com>
(adding sr-dev)
Hi Alex,
the memory allocator of glibc was not really efficient regarding the particular needs of a SIP server (allocation of many small string objects).
That has probably improved in the last years, also system performance just got much faster.
Other programs/tools also use their own allocators, e.g. Firefox, Rust [1] for jemalloc.
There is some (not really well tested) support in the core for using the system memory allocator by the #define SYS_MALLOC.
It probably needs to be set in Makefile.defs, also deactivating the other PKG memory managers, but did not looked into it right now.
Cheers,
Henning
[1] https://news.ycombinator.com/item?id=8612645
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://gilawa.com
-----Original Message-----
From: Alex Balashov <abalashov(a)evaristesys.com>
Sent: Thursday, January 5, 2023 3:59 PM
To: Henning Westerholt <hw(a)gilawa.com>
Cc: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] pkg memory leak when acc module cdr_enabled
> On Jan 5, 2023, at 9:40 AM, Henning Westerholt <hw(a)gilawa.com> wrote:
>
> Hello Alex,
>
> there might be some performance implications by switching to system malloc. There is also easier debugging by internal Kamailio memory manager support.
>
> In this particular example with the leak, Kamailio would use in the end all of the system memory, and the machine out of memory killer will then randomly processes. So the limited memory pool also helps to protect the system against this kind of leaks.
I am in no position to assess the relative efficiencies of various memory allocators. But it seems a bit extraordinary to suppose that a custom allocator is more efficient than the general-purpose libc allocator, although it's obviously possible; some application-specific optimised allocators clearly make this argument (i.e. Redis + jemalloc).
Also, I wonder if the answer to this has changed over 20 years.
Unbounded allocation from leaks can certainly be a problem. But rendering a process useless by running out of (much more limited) package memory (much more quickly) can also be a problem. :-)
-- Alex
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
### Description
during sipp "tls caller and tls callee" test, do tls.reload repeatedly, the sipp tls connection will be disconnected and tls.reload will report error and can not be recovered
### Troubleshooting
#### Reproduction
(1)write a simple request_route logic in kamailio.cfg, as follows:
request_route {
add_local_rport();
$du = "sip:192.168.131.190:1001;transport=tls";
forward();
}
(2)start sipp caller to kamailio tls:0.0.0.0:5061 and kamailio will relay this request to callee
(3)at the same time, in another console, run the following cmds:
((i = 0)); while true; do /opt/kamailio/sbin/kamcmd tls.reload && echo $i && ((i = i+1)); done;
#### Debugging Data
None
#### Log Messages
tls.reload will report the following error, and it can not work again until kamailio is restarted:
error: 500 - Error while loading TLS configuration file (consult server log)
at the same time, sipp tls connection is disconnected by kamailio, some error is shown in the kamailo.log:
--------------------------------------------------------------------------------------------------------
Dec 14 10:59:54 localhost sipproxy[64723]: ERROR: tls [tls_server.c:1330]: tls_h_read_f(): protocol level error
Dec 14 10:59:54 localhost sipproxy[64723]: ERROR: tls [tls_server.c:1334]: tls_h_read_f(): src addr: 192.168.131.190:59545
Dec 14 10:59:54 localhost sipproxy[64723]: ERROR: tls [tls_server.c:1337]: tls_h_read_f(): dst addr: 192.168.131.190:5061
Dec 14 10:59:54 localhost sipproxy[64723]: ERROR: <core> [core/tcp_read.c:1478]: tcp_read_req(): ERROR: tcp_read_req: error reading - c: 0x7f3f67c89ba8 r: 0x7f3f67c89cd0 (-1)
--------------------------------------------------------------------------------------------------------
#### SIP Traffic
<!--
If the issue is exposed by processing specific SIP messages, grab them with ngrep or save in a pcap file, then add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
```
### Possible Solutions
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.6.2 (x86_64/linux)
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled on 10:03:56 Dec 14 2022 with gcc 4.9.4
```
* **Operating System**:
<!--
Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...;
Kernel details (output of `lsb_release -a` and `uname -a`)
-->
```
Linux localhost.localdomain 3.10.0-327.el7.x86_64 #1 SMP Thu Nov 19 22:10:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3305
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3305(a)github.com>
Module: kamailio
Branch: 5.6
Commit: efd90dc303221208a714ecc69daf744c39d47f0d
URL: https://github.com/kamailio/kamailio/commit/efd90dc303221208a714ecc69daf744…
Author: Kamailio Dev <kamailio.dev(a)kamailio.org>
Committer: Kamailio Dev <kamailio.dev(a)kamailio.org>
Date: 2023-01-06T12:47:01+01:00
modules: readme files regenerated - modules ... [skip ci]
---
Modified: src/modules/app_python/README
Modified: src/modules/app_python3/README
---
Diff: https://github.com/kamailio/kamailio/commit/efd90dc303221208a714ecc69daf744…
Patch: https://github.com/kamailio/kamailio/commit/efd90dc303221208a714ecc69daf744…
---
diff --git a/src/modules/app_python/README b/src/modules/app_python/README
index a1269d14f0e..a9d0b02890d 100644
--- a/src/modules/app_python/README
+++ b/src/modules/app_python/README
@@ -77,6 +77,10 @@ Chapter 1. Admin Guide
module, look at the files inside source tree located at
'modules/app_python/python_examples/'.
+ As python2 is deprecated in Debian and other distributions, please use
+ the ���app_python3��� module instead. This module will be removed future
+ releases.
+
2. Dependencies
2.1. Kamailio Modules
diff --git a/src/modules/app_python3/README b/src/modules/app_python3/README
index 49bc5774445..914350572b6 100644
--- a/src/modules/app_python3/README
+++ b/src/modules/app_python3/README
@@ -87,6 +87,11 @@ Chapter 1. Admin Guide
module, look at the files inside the source tree located at
'modules/app_python3/python_examples/'.
+ Note: if symbols exported to KEMI (module or function names) conflict
+ with Python's reserved keywords, use the 'getattr()' function or the
+ '__dict__' attribute for 'KSR' (e.g.,
+ 'KSR.__dict__["async"].task_route("myroute")').
+
2. Dependencies
2.1. Kamailio Modules
@@ -190,9 +195,9 @@ python_exec("my_python_function", "$rU");
in each worker when it next invokes a Python method. The module uses a
worker process lock to prevent recursive reloads.
- This function only reloads the user script and creates a new script
- object. It does not reinitialize the interpreter. E.g., references in
- the old module remain if not redefined by the new version.
+ This function only reloads (re-executes) the user script and creates a
+ new script object. It does not reinitialize the interpreter (references
+ in the old module remain if not redefined by the new version).
Name: app_python.reload
@@ -203,6 +208,24 @@ python_exec("my_python_function", "$rU");
kamcmd app_python.reload
...
+ Note that reload is done for the Python script provided as parameter to
+ this Kamailio module. To reload the Python libraries imported in this
+ script, use something like:
+...
+import mod1
+...
+import modN
+from importlib import reload
+
+def mod_init():
+ reload(mod1)
+ ...
+ reload(modN)
+ return kamailio()
+...
+
+ Where "modX" are the modules imported at the top.
+
5.2. app_python.api_list
List the functions available via Kemi framework.
### Description
I have the following URI:
```INVITE sip:123456789;phone-context=+1@192.168.1.1;transport=udp;user=phone SIP/2.0```
I want to remove the phone-context parameter from the URI, so I've tried to use the function:
```uri_param_rm``` from the siputils package:
```
if (uri_param_rm("phone-context")) {
t_relay_to_udp("192.168.1.2", "5060");
exit;
}
```
But this doesn't change anything, this parameter is still present in the URI.
I tried to use ```msg_apply_changes``` (just in case) function before relaying it - the result it the same, the parameter is still there.
Also, I've noticed that this function is not working either:
```
if (uri_param_any("phone-context")) {
xlog("L_INFO", "Phone Context");
}
```
while this one:
```get_uri_param("phone-context", "$var(phoneCtx)");``` - seems to be working fine.
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.6.2 (x86_64/linux) e292ba
```
* **Operating System**:
<!--
Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...;
Kernel details (output of `lsb_release -a` and `uname -a`)
-->
```
CentOS 7 X64
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3321
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3321(a)github.com>
### Description
The permissions module has two reload RPC commands, `permissions.addressReload` which reloads the `address` table, and `permissions.trustedReload`, which reloads the `trusted` table.
The module parameter `reload_delta` exists to prevent concurrent reloading of a single table:
> ##### 3.25. reload_delta (int)
> The number of seconds that have to be waited before executing a new RPC reload. By default there is a rate limiting of maximum one reload in five seconds.
>
> If set to 0, no rate limit is configured. Note carefully: use this configuration only in tests environments because executing two RPC reloads of the same table at the same time can cause to kamailio to crash.
If one of the reload rpc commands is issues (i.e. `permissions.addressReload`), then the OTHER reload command (`permissions.trustedReload`) will be blocked, despite acting against two separate tables.
### Troubleshooting
Reproduced the issue.
#### Reproduction
_(DB config for permissions module omitted for brevity)_
```
loadmodule "rtimer.so"
loadmodule "permissions.so"
loadmodule "jsonrpcs"
modparamx("rtimer", "timer", "name=permissions_reload;mode=0;interval=300")
modparam("rtimer", "exec", "timer=permissions_reload;route=RELOAD_PERMISSIONS")
route[RELOAD_PERMISSIONS] {
xnotice("Reloading trusted records\n");
jsonrpc_exec('{"jsonrpc": "2.0", "method": "permissions.trustedReload", "id": 1}');
xalert("jsonrpc response code: $jsonrpl(code) - the body is: $jsonrpl(body)\n");
xnotice("Reloading addresses\n");
jsonrpc_exec('{"jsonrpc": "2.0", "method": "permissions.addressReload", "id": 1}');
xalert("jsonrpc response code: $jsonrpl(code) - the body is: $jsonrpl(body)\n");
}
```
#### Debugging Data
The above config yields output like this:
```
2(8) NOTICE: <script>: Reloading trusted records
2(8) ALERT: <script>: jsonrpc response code: 200 - the body is: {
"jsonrpc": "2.0",
"result": "Reload OK",
"id": 1
}
2(8) NOTICE: <script>: Reloading addresses
2(8) ERROR: permissions [rpc.c:42]: rpc_check_reload(): ongoing reload
2(8) ALERT: <script>: jsonrpc response code: 500 - the body is: {
"jsonrpc": "2.0",
"error": {
"code": 500,
"message": "ongoing reload"
},
"id": 1
}
```
### Possible Solutions
Ideally each reload would be tracked separately. This could possibly involve separate `reload_delta` parameters for each table (although it seems excessive to change the interface).
It's also possible that this behavior is by design, in which case, clarification of the documentation for the `reload_delta` parameter would be nice.
### Additional Information
Problem occurs in kamailio 5.6.2. Likely within all version since the `reload_delta` parameter was added.
* **Operating System**:
Tested in Alpine, but OS seems irrelevant.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3318
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3318(a)github.com>