SNMPstats has a queued buffer that contains registration changes based on callbacks from usrloc. If one loads SNMPstats this queue grows forever and is only emptied when someone actually calls exactly the right parts of the MIB. At that time the queue is processed and an internal copy of the location table is produced and published. If one uses other parts of the MIB the queue keeps growing.
This can be turned off by disabling the modparam "Export_registrar".
Proposed changes:
- Improve the README
- Check if the processing of the queue can happen on timer instead of waiting for accidental checks.
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/636
I have rebooted my kamailio machine and now the value of kamailio dialogs is always 0:
KAMAILIO-MIB::kamailioCurNumDialogs.0 = Gauge32: 0
KAMAILIO-MIB::kamailioCurNumDialogsInProgress.0 = Gauge32: 0
KAMAILIO-MIB::kamailioCurNumDialogsInSetup.0 = Gauge32: 0
KAMAILIO-MIB::kamailioTotalNumFailedDialogSetups.0 = Counter32: 0
And also the status is:
KAMAILIO-MIB::kamailioDialogUsageState.0 = INTEGER: idle(0)
How can I change it to active(1)? I have dialog.so loaded as well as modparam("dialog", "dlg_flag", 4) and dlg_manage().
If I do 'kamctl stats dialog':
# kamctl stats dialog
dialog:active_dialogs = 498
dialog:early_dialogs = 57
dialog:expired_dialogs = 24
dialog:failed_dialogs = 73222
dialog:processed_dialogs = 539449
I have the same configruation of SNMPstats and kamailio in 2 other machines and it works perfectly. In this machine it worked until I rebooted the machine.
I asked this question in th emailing list and I got the following response:
"Must be something in how the SNMP module reads the data from the statistics counters."
I don't know if this could help.
Thank you.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/424
Hi devs,
The logs of our Kamailio servers are rich for such lines:
```
Oct 28 06:57:35 ip-172-31-0-139 /usr/local/sbin/kamailio[31963]: ERROR: <core> [tcp_read.c:271]: tcp_read_data(): error reading: Connection reset by peer (104)
Oct 28 06:57:35 ip-172-31-0-139 /usr/local/sbin/kamailio[31963]: ERROR: <core> [tcp_read.c:1296]: tcp_read_req(): ERROR: tcp_read_req: error reading
```
The servers serve WS, WSS, UDP, TCP and TLS as connection transports. So we cannot figure what happens and if this is really a problem, but we get accused by whoever audits the servers.
What could be done to make this more trackable? Or maybe these messages should be suppressed, if there's no way to track them and they don't mean any problem?
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/385
Hi im currently using freetds via unixodbc to connect to a sql azure db which is ok but suffers from various connection busy errors. I would like to use the ms odbc driver as it supports MARS (multiple active result sets) which should stop the connection busy errors, and numerous other sql server specific enhancements However despite the odbc driver working fine with the unixodbc cli tools kamailio crashes when I try and start the service.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/501
Hello All,
Kamailio instance just crashed with the following logs
May 13 06:05:34 P172 /usr/local/kamailio/sbin/kamailio[12693]: CRITICAL: <core> [pass_fd.c:275]: receive_fd(): EOF on 10
May 13 06:05:34 P172 /usr/local/kamailio/sbin/kamailio[12667]: ALERT: <core> [main.c:739]: handle_sigs(): child process 12671 exited by a signal 11
May 13 06:05:34 P172 /usr/local/kamailio/sbin/kamailio[12667]: ALERT: <core> [main.c:742]: handle_sigs(): core was generated
May 13 06:05:34 P172 /usr/local/kamailio/sbin/kamailio[12667]: INFO: <core> [main.c:754]: handle_sigs(): terminating due to SIGCHLD
....
....
May 13 06:05:34 P172 /usr/local/kamailio/sbin/kamailio[12667]: INFO: <core> [mem/f_malloc.c:598]: fm_free(): freeing a free fragment (0x7f23ff39cb88/0x7f23ff39cbd0) - ignore
the gdb traces are as below,
(gdb) bt
#0 0x0000000000000000 in ?? ()
#1 0x00007f23facf0f86 in run_create_callbacks (dlg=0x7f23ff849b18, msg=0x7f24201ead80) at dlg_cb.c:230
#2 0x00007f23fad0cedf in dlg_new_dialog (req=0x7f24201ead80, t=0x7f23ff848488, run_initial_cbs=1) at dlg_handlers.c:869
#3 0x00007f23fad0b80e in dlg_onreq (t=0x7f23ff848488, type=1, param=0x7f241feabc60 <params>) at dlg_handlers.c:722
#4 0x00007f241fbe4b25 in run_reqin_callbacks_internal (hl=0x7f23ff3536e8, trans=0x7f23ff848488, params=0x7f241feabc60 <params>) at t_hooks.c:360
#5 0x00007f241fbe4c31 in run_reqin_callbacks (trans=0x7f23ff848488, req=0x7f24201ead80, code=1) at t_hooks.c:385
#6 0x00007f241fba0e63 in build_cell (p_msg=0x7f24201ead80) at h_table.c:373
#7 0x00007f241fbf6e8c in new_t (p_msg=0x7f24201ead80) at t_lookup.c:1269
#8 0x00007f241fbf8194 in t_newtran (p_msg=0x7f24201ead80) at t_lookup.c:1409
#9 0x00007f241fbc9f8c in t_relay_to (p_msg=0x7f24201ead80, proxy=0x0, proto=0, replicate=0) at t_funcs.c:242
#10 0x00007f241fc0c9e8 in _w_t_relay_to (p_msg=0x7f24201ead80, proxy=0x0, force_proto=0) at tm.c:1425
#11 0x00007f241fc0dc6d in w_t_relay (p_msg=0x7f24201ead80, _foo=0x0, _bar=0x0) at tm.c:1626
#12 0x000000000041f71f in do_action (h=0x7ffd11757ce0, a=0x7f2420089228, msg=0x7f24201ead80) at action.c:1054
#13 0x000000000042c5aa in run_actions (h=0x7ffd11757ce0, a=0x7f2420089228, msg=0x7f24201ead80) at action.c:1549
#14 0x000000000042cc6a in run_actions_safe (h=0x7ffd1175b210, a=0x7f2420089228, msg=0x7f24201ead80) at action.c:1614
#15 0x000000000055a40a in rval_get_int (h=0x7ffd1175b210, msg=0x7f24201ead80, i=0x7ffd117580d4, rv=0x7f2420087d88, cache=0x0) at rvalue.c:912
#16 0x000000000055ea84 in rval_expr_eval_int (h=0x7ffd1175b210, msg=0x7f24201ead80, res=0x7ffd117580d4, rve=0x7f2420087d80) at rvalue.c:1910
#17 0x000000000055eee6 in rval_expr_eval_int (h=0x7ffd1175b210, msg=0x7f24201ead80, res=0x7ffd11758238, rve=0x7f2420089430) at rvalue.c:1918
#18 0x000000000041f1ca in do_action (h=0x7ffd1175b210, a=0x7f2420089e68, msg=0x7f24201ead80) at action.c:1030
#19 0x000000000042c5aa in run_actions (h=0x7ffd1175b210, a=0x7f2420075ef0, msg=0x7f24201ead80) at action.c:1549
#20 0x000000000041f68e in do_action (h=0x7ffd1175b210, a=0x7f242008a0c8, msg=0x7f24201ead80) at action.c:1045
#21 0x000000000042c5aa in run_actions (h=0x7ffd1175b210, a=0x7f2420046f50, msg=0x7f24201ead80) at action.c:1549
#22 0x000000000041bee8 in do_action (h=0x7ffd1175b210, a=0x7f242002e2d0, msg=0x7f24201ead80) at action.c:678
#23 0x000000000042c5aa in run_actions (h=0x7ffd1175b210, a=0x7f242002df30, msg=0x7f24201ead80) at action.c:1549
#24 0x000000000041f68e in do_action (h=0x7ffd1175b210, a=0x7f2420030280, msg=0x7f24201ead80) at action.c:1045
#25 0x000000000042c5aa in run_actions (h=0x7ffd1175b210, a=0x7f242002b418, msg=0x7f24201ead80) at action.c:1549
#26 0x000000000041f68e in do_action (h=0x7ffd1175b210, a=0x7f2420031a10, msg=0x7f24201ead80) at action.c:1045
#27 0x000000000042c5aa in run_actions (h=0x7ffd1175b210, a=0x7f2420031a10, msg=0x7f24201ead80) at action.c:1549
#28 0x000000000041bee8 in do_action (h=0x7ffd1175b210, a=0x7f241ff08e60, msg=0x7f24201ead80) at action.c:678
#29 0x000000000042c5aa in run_actions (h=0x7ffd1175b210, a=0x7f241ff083c8, msg=0x7f24201ead80) at action.c:1549
#30 0x000000000041f68e in do_action (h=0x7ffd1175b210, a=0x7f241ff090c0, msg=0x7f24201ead80) at action.c:1045
#31 0x000000000042c5aa in run_actions (h=0x7ffd1175b210, a=0x7f241feff908, msg=0x7f24201ead80) at action.c:1549
#32 0x000000000042cd53 in run_top_route (a=0x7f241feff908, msg=0x7f24201ead80, c=0x0) at action.c:1635
#33 0x000000000051d57a in receive_msg (
buf=0xabb500 <buf> "INVITE sip:a92a88a0-18d0-11e6-b333-9dc315c4caad@sunilmore.in SIP/2.0\r\nVia: SIP/2.0/UDP sunilmore.in:6000;rport;branch=z9hG4bK87avNBSpD6ajB\r\nMax-Forwards: 69\r\nFrom: \"\" <sip:123456789@sunilmore.in>"..., len=1972, rcv_info=0x7ffd1175b580) at receive.c:240
#34 0x00000000006302f1 in udp_rcv_loop () at udp_server.c:495
#35 0x00000000004b3062 in main_loop () at main.c:1600
#36 0x00000000004ba772 in main (argc=13, argv=0x7ffd1175ba88) at main.c:2616
The version i am using is
version: kamailio 4.4.1 (x86_64/linux) 90be8b
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 90be8b
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/619
The column name is currently not free'd. Some db bankends copy this
data so that memory is leaked. Some store internal database pointers
and those shouldn't be free'd. One returns a pointer to a stack
variable which shouldn't be done.
The patch cleans up all db backends to copy the column name and frees
that column name as part of the database result cleanup function.
Author: Chris Double <doublec(a)silentcircle.com>
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/611
-- Commit Summary --
* Free database column name as part of database result cleanup
-- File Changes --
M lib/srdb1/db_res.c (3)
M modules/db_berkeley/km_bdb_res.c (9)
M modules/db_mongodb/mongodb_dbase.c (9)
M modules/db_mysql/km_res.c (9)
M modules/db_postgres/km_res.c (10)
M modules/db_text/dbt_api.c (9)
M modules/db_unixodbc/res.c (8)
M modules/xmlrpc/xmlrpc.c (2)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/611.patchhttps://github.com/kamailio/kamailio/pull/611.diff
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/611
```
CC (clang38) [M ims_dialog.so] dlg_hash.o
dlg_hash.c:674:37: warning: equality comparison with extraneous parentheses [-Wparentheses-equality]
if ((d_entry_out->first == d_entry_out->last)) {
~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
dlg_hash.c:674:37: note: remove extraneous parentheses around the comparison to silence this warning
if ((d_entry_out->first == d_entry_out->last)) {
~ ^ ~
dlg_hash.c:674:37: note: use '=' to turn this equality comparison into an assignment
if ((d_entry_out->first == d_entry_out->last)) {
^~
=
CC (clang38) [M ims_qos.so] rx_avp.o
rx_avp.c:492:16: warning: comparison of unsigned expression >= 0 is always true [-Wtautological-compare]
if (bandwidth >= 0) {
~~~~~~~~~ ^ ~
rx_avp.c:504:16: warning: comparison of unsigned expression >= 0 is always true [-Wtautological-compare]
if (bandwidth >= 0) {
~~~~~~~~~ ^ ~
CC (clang38) [M ims_registrar_scscf.so] save.o
save.c:114:21: warning: comparison of unsigned expression >= 0 is always true [-Wtautological-compare]
if (expires_hdr >= 0)
~~~~~~~~~~~ ^ ~
```
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/637
-- Commit Summary --
* modules/ims_auth lib/ims: use header type instead of header flag
* modules/ims_qos modules/ims_registrar_scscf: fix comparison of unsigned expression
* modules/ims_dialog: fix clang warning -Wparentheses-equality
-- File Changes --
M lib/ims/ims_getters.c (6)
M modules/ims_auth/utils.c (4)
M modules/ims_dialog/dlg_hash.c (2)
M modules/ims_qos/rx_avp.c (4)
M modules/ims_registrar_scscf/save.c (2)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/637.patchhttps://github.com/kamailio/kamailio/pull/637.diff
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/637
Hi!
In order to be able to test the API for the http_client I have created a separate module. I couldn’t let it live in the same directory, so I created a new module directory for it. If I keep it in the same directory the Makefile automatically links it with the http_client so-file, which is not what I want.
I would like to store it somewhere - I can either commit is a module that doesn’t compile by default, store it in a hidden branch and forget about it or get help in fixing the Makefile so it can optionally compile in the same directory.
Which would be the way forward?
Right now it doesn’t do much more than bind to the API, but hopefully it will soon be able to test all the provided API functions.
/O