Module: kamailio
Branch: 5.3
Commit: 8f5653e6cd84bc1dfa2498959b99f3fe2911b483
URL: https://github.com/kamailio/kamailio/commit/8f5653e6cd84bc1dfa2498959b99f3f…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2020-05-06T11:57:37+02:00
kamctl: kamdbclt mysql skip creating dbrouser if same as dbrwuser
(cherry picked from commit 66ef7ab7b078794b96ecee13f6867d5f90a8d63e)
---
Modified: utils/kamctl/kamdbctl.mysql
---
Diff: https://github.com/kamailio/kamailio/commit/8f5653e6cd84bc1dfa2498959b99f3f…
Patch: https://github.com/kamailio/kamailio/commit/8f5653e6cd84bc1dfa2498959b99f3f…
---
diff --git a/utils/kamctl/kamdbctl.mysql b/utils/kamctl/kamdbctl.mysql
index e8f8d2e861..358742dad4 100644
--- a/utils/kamctl/kamdbctl.mysql
+++ b/utils/kamctl/kamdbctl.mysql
@@ -161,9 +161,12 @@ kamailio_db_grant () # pars: <database name>
# Users: kamailio is the regular user, kamailioro only for reading
sql_query "" "CREATE USER '${DBRWUSER}'@'$DBHOST' IDENTIFIED BY '$DBRWPW';
- GRANT ALL PRIVILEGES ON $1.* TO '${DBRWUSER}'@'$DBHOST';
- CREATE USER '${DBROUSER}'@'$DBHOST' IDENTIFIED BY '$DBROPW';
- GRANT SELECT ON $1.* TO '${DBROUSER}'@'$DBHOST';"
+ GRANT ALL PRIVILEGES ON $1.* TO '${DBRWUSER}'@'$DBHOST';"
+
+ if [ "${DBRWUSER}" != "${DBROUSER}" ] ; then
+ sql_query "" "CREATE USER '${DBROUSER}'@'$DBHOST' IDENTIFIED BY '$DBROPW';
+ GRANT SELECT ON $1.* TO '${DBROUSER}'@'$DBHOST';"
+ fi
if [ $? -ne 0 ] ; then
merr "granting privileges to database $1 failed!"
@@ -172,9 +175,11 @@ kamailio_db_grant () # pars: <database name>
if [ "$DBHOST" != "localhost" ] ; then
sql_query "" "CREATE USER '$DBRWUSER'@'localhost' IDENTIFIED BY '$DBRWPW';
- GRANT ALL PRIVILEGES ON $1.* TO '$DBRWUSER'@'localhost';
- CREATE USER '$DBROUSER'@'localhost' IDENTIFIED BY '$DBROPW';
- GRANT SELECT ON $1.* TO '$DBROUSER'@'localhost';"
+ GRANT ALL PRIVILEGES ON $1.* TO '$DBRWUSER'@'localhost';"
+ if [ "${DBRWUSER}" != "${DBROUSER}" ] ; then
+ sql_query "" "CREATE USER '$DBROUSER'@'localhost' IDENTIFIED BY '$DBROPW';
+ GRANT SELECT ON $1.* TO '$DBROUSER'@'localhost';"
+ fi
if [ $? -ne 0 ] ; then
merr "granting localhost privileges to database $1 failed!"
exit 1
@@ -183,9 +188,11 @@ kamailio_db_grant () # pars: <database name>
if [ ! -z "$DBACCESSHOST" ] ; then
sql_query "" "CREATE USER '$DBRWUSER'@'$DBACCESSHOST' IDENTIFIED BY '$DBRWPW';
- GRANT ALL PRIVILEGES ON $1.* TO '$DBRWUSER'@'$DBACCESSHOST';
- CREATE USER '$DBROUSER'@'$DBACCESSHOST' IDENTIFIED BY '$DBROPW';
- GRANT SELECT ON $1.* TO '$DBROUSER'@'$DBACCESSHOST';"
+ GRANT ALL PRIVILEGES ON $1.* TO '$DBRWUSER'@'$DBACCESSHOST';"
+ if [ "${DBRWUSER}" != "${DBROUSER}" ] ; then
+ sql_query "" "CREATE USER '$DBROUSER'@'$DBACCESSHOST' IDENTIFIED BY '$DBROPW';
+ GRANT SELECT ON $1.* TO '$DBROUSER'@'$DBACCESSHOST';"
+ fi
if [ $? -ne 0 ] ; then
merr "granting access host privileges to database $1 failed!"
exit 1
@@ -203,8 +210,11 @@ kamailio_db_revoke () # pars: <database name>
minfo "revoking privileges to database $1 ..."
# Users: kamailio is the regular user, kamailioro only for reading
- sql_query "" "REVOKE ALL PRIVILEGES ON $1.* FROM '${DBRWUSER}'@'$DBHOST';
- REVOKE SELECT ON $1.* FROM '${DBROUSER}'@'$DBHOST';"
+ sql_query "" "REVOKE ALL PRIVILEGES ON $1.* FROM '${DBRWUSER}'@'$DBHOST';"
+
+ if [ "${DBRWUSER}" != "${DBROUSER}" ] ; then
+ sql_query "" "REVOKE SELECT ON $1.* FROM '${DBROUSER}'@'$DBHOST';"
+ fi
if [ $? -ne 0 ] ; then
merr "revoking privileges to database $1 failed!"
@@ -212,8 +222,10 @@ kamailio_db_revoke () # pars: <database name>
fi
if [ "$DBHOST" != "localhost" ] ; then
- sql_query "" "REVOKE ALL PRIVILEGES ON $1.* FROM '$DBRWUSER'@'localhost';
- REVOKE SELECT ON $1.* FROM '$DBROUSER'@'localhost';"
+ sql_query "" "REVOKE ALL PRIVILEGES ON $1.* FROM '$DBRWUSER'@'localhost';"
+ if [ "${DBRWUSER}" != "${DBROUSER}" ] ; then
+ sql_query "" "REVOKE SELECT ON $1.* FROM '$DBROUSER'@'localhost';"
+ fi
if [ $? -ne 0 ] ; then
merr "granting localhost privileges to database $1 failed!"
exit 1
@@ -221,8 +233,10 @@ kamailio_db_revoke () # pars: <database name>
fi
if [ ! -z "$DBACCESSHOST" ] ; then
- sql_query "" "REVOKE ALL PRIVILEGES ON $1.* FROM '$DBRWUSER'@'$DBACCESSHOST';
- REVOKE SELECT ON $1.* FROM '$DBROUSER'@'$DBACCESSHOST';"
+ sql_query "" "REVOKE ALL PRIVILEGES ON $1.* FROM '$DBRWUSER'@'$DBACCESSHOST';"
+ if [ "${DBRWUSER}" != "${DBROUSER}" ] ; then
+ sql_query "" "REVOKE SELECT ON $1.* FROM '$DBROUSER'@'$DBACCESSHOST';"
+ fi
if [ $? -ne 0 ] ; then
merr "granting access host privileges to database $1 failed!"
exit 1
Module: kamailio
Branch: 5.3
Commit: 4790825cc98068b07c1e0402bdea93f839a1fd77
URL: https://github.com/kamailio/kamailio/commit/4790825cc98068b07c1e0402bdea93f…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2020-05-06T11:57:22+02:00
htable: docs - more details about size attribute for htable
(cherry picked from commit 35f711e6ec74c6e67edf99adaa15cc353f2ce949)
---
Modified: src/modules/htable/doc/htable_admin.xml
---
Diff: https://github.com/kamailio/kamailio/commit/4790825cc98068b07c1e0402bdea93f…
Patch: https://github.com/kamailio/kamailio/commit/4790825cc98068b07c1e0402bdea93f…
---
diff --git a/src/modules/htable/doc/htable_admin.xml b/src/modules/htable/doc/htable_admin.xml
index 17391626a1..f0b560cfd1 100644
--- a/src/modules/htable/doc/htable_admin.xml
+++ b/src/modules/htable/doc/htable_admin.xml
@@ -341,11 +341,17 @@ $ kamcmd htable.dump htable
</listitem>
<listitem>
<para>
- <emphasis>size</emphasis> - number specifying the size of hash
- table. Larger value means less collisions. The number of entries
- (aka slots or buckets) in the table is 2^size. The possible range
+ <emphasis>size</emphasis> - number to control how many slots
+ (buckets) to create for the hash table. Larger value means more
+ slots with higher probability for less collisions. The actual number
+ slots (or buckets) created for the table is 2^size. The possible range
for this value is from 2 to 31, smaller or larger values will be
- increased to 3 (8 slots) or decreased to 14 (16384 slots).
+ increased to 3 (8 slots) or decreased to 14 (16384 slots). Note
+ that each slot can store more than one item, when there are
+ collisions of hash ids computed for keys. The items in the same
+ slot are stored in a linked list. In other words, the size is not
+ setting a limit of how many items can be stored in a hash table, as
+ long as there is enough free shared memory, new items can be added.
</para>
</listitem>
<listitem>
Hello,
based on the discussions from yesterday's online devel meeting, I am
planning to release next week (likely on Wednesday, May 6) the next
minor version out of branch 5.3, respectively 5.3.4.
Should anyone be aware of issues not reported to the bug tracker or
commits for fixes in master not backported to 5.3 branch, let us know.
For new issues, the best is to report them on the tracker. For commits,
you can provide links/hashids or make pull requests.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
### Description
After upgrading to 5.3.0 from 5.2.2 (standard packages on FreeBSD 12.0), I am experiencing intermittent crashes related to handling of BYE messages.
### Troubleshooting
#### Reproduction
This happens ~ weekly and I have not found a good way to reproduce it.
#### Debugging Data
An example backtrace is below from the last dumped core (the SIGSEGV one); unfortunately it overwrote the earlier one:
```
* thread #1, name = 'kamailio', stop reason = signal SIGSEGV
* frame #0: 0x00000008009c5b79 libc.so.7`___lldb_unnamed_symbol403$$libc.so.7 + 41
frame #1: 0x00000008009ed63e libc.so.7`__free + 990
frame #2: 0x000000080271562b libthr.so.3`pthread_rwlock_destroy + 59
frame #3: 0x0000000802bedbf6 libcrypto.so.111`CRYPTO_THREAD_lock_free + 22
frame #4: 0x0000000802aef3c4 libcrypto.so.111`RSA_free + 100
frame #5: 0x0000000802b10c32 libcrypto.so.111`EVP_PKEY_free + 66
frame #6: 0x000000080296ed86 libssl.so.111`___lldb_unnamed_symbol646$$libssl.so.111 + 134
frame #7: 0x000000080295f93c libssl.so.111`SSL_CTX_free + 236
frame #8: 0x00000008028aee42 tls.so`tls_free_domain + 114
frame #9: 0x00000008028af1d7 tls.so`tls_free_cfg + 199
frame #10: 0x00000008028af2df tls.so`tls_destroy_cfg + 191
frame #11: 0x00000008028ad1f1 tls.so`destroy_tls_h + 1185
frame #12: 0x000000000041adea kamailio`destroy_tls + 26
frame #13: 0x00000000002e36fd kamailio`cleanup + 269
frame #14: 0x00000000002eb5b7 kamailio`___lldb_unnamed_symbol5$$kamailio + 1351
frame #15: 0x00000000002ea5e5 kamailio`handle_sigs + 21669
frame #16: 0x00000000002fb83e kamailio`main_loop + 40014
frame #17: 0x0000000000307d2b kamailio`main + 50267
frame #18: 0x00000000002e311b kamailio`_start + 283
```
This is with OpenSSL 1.1 With the LD_PRELOAD hack to 5.2.2, things were completely stable; I am trying to use kamailio without the LD_PRELOAD'ed mutex wrapper now, which I believe is no longer required. It looks like the SSL-related stuff in the TLS crash (which was 5 minutes later!) is unrelated to the initial problem and may just be an artifact of one of the kamailio processes crashing earlier.
#### Log Messages
```
Nov 2 08:11:31 home /usr/local/sbin/kamailio[94702]: CRITICAL: {1 527440 BYE 973470944-5061-16392(a)BA.A.B.I} <core> [core/mem/q_malloc.c:149]: qm_debug_check_frag(): BUG: qm: prev. fragm. tail overwritten(c0c0c000, abcdefed)[0x801544c58:0x801544c90]! Memory allocator was called from core: core/action.c:754. Fragment marked by core: core/dset.c:733. Exec from core/mem/q_malloc.c:504.
Nov 2 08:13:41 home /usr/local/sbin/kamailio[94703]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 22
Nov 2 08:13:41 home kernel: pid 94702 (kamailio), uid 0: exited on signal 6 (core dumped)
Nov 2 08:13:41 home /usr/local/sbin/kamailio[94692]: ALERT: <core> [main.c:767]: handle_sigs(): child process 94702 exited by a signal 6
Nov 2 08:13:41 home /usr/local/sbin/kamailio[94692]: ALERT: <core> [main.c:770]: handle_sigs(): core was generated
Nov 2 08:14:56 home login[8284]: ROOT LOGIN (root) ON ttyu0
Nov 2 08:16:26 home kernel: pid 94692 (kamailio), uid 0: exited on signal 11 (core dumped)
```
I had an identical problem a week ago, also with a crash on a BYE for an active call:
```
Oct 27 13:00:02 home /usr/local/sbin/kamailio[79819]: CRITICAL: {1 598425 BYE 649761149-5061-291(a)BA.A.B.I} <core> [core/mem/q_malloc.c:149]: qm_debug_check_frag(): BUG: qm: prev. fragm. tail overwritten(c0c0c000, abcdefed)[0x801551808:0x801551840]! Memory allocator was called from core: core/action.c:754. Fragment marked by core: core/dset.c:733. Exec from core/mem/q_malloc.c:504.
Oct 27 13:02:09 home /usr/local/sbin/kamailio[79820]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 22
Oct 27 13:02:09 home kernel: pid 79819 (kamailio), uid 0: exited on signal 6 (core dumped)
Oct 27 13:02:09 home /usr/local/sbin/kamailio[79809]: ALERT: <core> [main.c:767]: handle_sigs(): child process 79819 exited by a signal 6
Oct 27 13:02:09 home /usr/local/sbin/kamailio[79809]: ALERT: <core> [main.c:770]: handle_sigs(): core was generated
Oct 27 13:04:55 home kernel: pid 79809 (kamailio), uid 0: exited on signal 11 (core dumped)
```
### 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.3.0 (x86_64/freebsd) 4cc67a
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, 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_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, select, kqueue.
id: 4cc67a
compiled on 18:51:34 Oct 25 2019 with cc 6.0
```
* **Operating System**:
FreeBSD 12.0
```
FreeBSD home.XXX 12.0-RELEASE-p10 FreeBSD 12.0-RELEASE-p10 GENERIC amd64
```
--
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/2121
Hello,
I am going to send a few emails on different topics to inform the
broader community on mailing lists about what was discussed during the
last online development meeting that happened last Wednesday, so
everyone becomes aware and add own opinions and suggestions.
First here is about the next major release, which is considered for the
mid of summer. To allow the usual 1-1.5 months of testing time frame,
the development has to be frozen in the first part of June (more or less
one month from now on).
If there will be no other proposals in the near future that end up in
postponing the release target date, then try to push to master branch
(or do pull requests) any new features that you want in Kamailio 5.4.x
in the next 4-5 weeks. Once the code is frozen, you would have to wait
for another release cycle to get new features in a stable branch.
During the online meeting there was no major missing feature reported,
if anyone here knows any, describe it and maybe some developer has time
to implement it.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Hello,
the presentity records (PUBLISH data) stored by the presence module
needed always an external storage backend (sql/no-sql database), for
subscriptions (active watchers) it was possible to use memory caching only.
I recently added support for cache-only module for PUBLISH data as well,
more details are presented in the news article:
* https://www.kamailio.org/w/2020/05/in-memory-presentity-records/
That could help simplifying network architecture on distributed
platforms leveraging cloud infrastructure and using replications
mechanisms (e.g., dmq, evapi+pua_json, nsq, ...) between the Kamailio nodes.
The impact on the code was quite significant, given that any PUBLISH
triggers a series of internal tasks (apply xcap rules, update watchers,
...), therefore I am calling for community testing to be sure old
operational modes were not affected as well as testing the new mode to
discover eventual issues -- just open an item on bug tracker when a
problem is discovered.
Special credits to Fred Posner (lod.com) for supporting the development
of this feature and to Emmanuel Schmidbauer for testing and
troubleshooting in the early phase of development.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda