24 Jul
2018
24 Jul
'18
11:20 a.m.
Hi,
I run Kamailio 5.0.1 with MariaDB database.
There is no issue at the initialization, meaning the db is opened by
kamailio and the hash tables loaded from the db tables.
Example:
# kamcmd htable.dump propertiesHash
{
entry: 1
size: 1
slot: {
item: {
name: cfg.env
But the htable.reload command fails:
error: 500 - Failed to open htable db connection
The Kamailio log reports that it can't connect the db :
DEBUG: ctl [../../core/io_wait.h:380]: io_watch_add(): DBG:
io_watch_add(0x7f68c74ab300, 10, 3, 0xdc9410), fd_no=1
DEBUG: ctl [io_listener.c:442]: handle_new_connect(): handle_stream read:
new connection (1) on /var/run/kamailio//kamailio_ctl
DEBUG: <core> [core/sr_module.c:694]: find_mod_export_record():
find_export_record: found <db_bind_api> in module db_mysql
[/usr/lib64/kamailio/modules/db_mysql.so]
DEBUG: <core> [db.c:209]: db_bind_mod(): using db bind api for db_mysql
DEBUG: <core> [db.c:314]: db_do_init2(): connection 0x7f68cc354c10 not found
in pool
DEBUG: db_mysql [km_my_con.c:98]: db_mysql_new_connection(): opening
connection: mysql://xxxx:xxxx@/siprouter
ERROR: db_mysql [km_my_con.c:124]: db_mysql_new_connection(): driver error:
Can't connect to local MySQL server through socket
'/var/lib/mysql/mysql.sock' (2 "No such file or directory")
ERROR: <core> [db.c:318]: db_do_init2(): could not add connection to the
pool
ERROR: htable [ht_db.c:92]: ht_db_open_con(): failed to connect to the
database
My local db is located at /myqdata/mysiprdb/data where is the mysiprdb.sock
file. But the log shows that Kamailio is looking for
/var/lib/mysql/mysql.sock.
Does this error make sense to you ?
Is it possible to fix this problem by configuration in Kamailio ?
My kamailio.cfg script contains :
# ----- htable
modparam("htable", "db_url",
"mysql://[kamailio]/siprouter")
modparam("htable", "fetch_rows", 1000)
modparam("htable", "htable",
"mbxrangeHash=>size=4;dbtable=mbxrange;")
modparam("htable", "htable",
"abpqHash=>size=12;dbtable=abpq;")
modparam("htable", "htable",
"zabpqHash=>size=12;dbtable=zabpq;")
modparam("htable", "htable",
"propertiesHash=>size=4;dbtable=properties;")
In the /myqdata/mysiprdb/data/my.cnf, I added the following entries for
Kamailio:
[kamailio]
socket = /myqdata/mysiprdb/data/mysiprdb.sock
user = siprouter
password = ##########
default-character-set = utf8
Thanks all for help.
Cordialement.
Patrick GINHOUX
2 Aug
2 Aug
9:43 a.m.
Does anybody encounter a problem with the kamcmd htable.reload
propertiesHash command ?
Cordialement.
Patrick GINHOUX
Unisys | +33 1 46 69 52 12 | +33 6 60 32 24 74 | patrick.ginhoux(a)unisys.com
De : sr-users <sr-users-bounces(a)lists.kamailio.org> De la part de Ginhoux,
Patrick
Envoyé : mardi 24 juillet 2018 10:20
À : Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Objet : [SR-Users] kamcmd htable.reload propertiesHash problem
Hi,
I run Kamailio 5.0.1 with MariaDB database.
There is no issue at the initialization, meaning the db is opened by
kamailio and the hash tables loaded from the db tables.
Example:
# kamcmd htable.dump propertiesHash
{
entry: 1
size: 1
slot: {
item: {
name: cfg.env
But the htable.reload command fails:
error: 500 - Failed to open htable db connection
The Kamailio log reports that it cant connect the db :
DEBUG: ctl [../../core/io_wait.h:380]: io_watch_add(): DBG:
io_watch_add(0x7f68c74ab300, 10, 3, 0xdc9410), fd_no=1
DEBUG: ctl [io_listener.c:442]: handle_new_connect(): handle_stream read:
new connection (1) on /var/run/kamailio//kamailio_ctl
DEBUG: <core> [core/sr_module.c:694]: find_mod_export_record():
find_export_record: found <db_bind_api> in module db_mysql
[/usr/lib64/kamailio/modules/db_mysql.so]
DEBUG: <core> [db.c:209]: db_bind_mod(): using db bind api for db_mysql
DEBUG: <core> [db.c:314]: db_do_init2(): connection 0x7f68cc354c10 not found
in pool
DEBUG: db_mysql [km_my_con.c:98]: db_mysql_new_connection(): opening
connection: mysql://xxxx:xxxx@/siprouter
ERROR: db_mysql [km_my_con.c:124]: db_mysql_new_connection(): driver error:
Can't connect to local MySQL server through socket
'/var/lib/mysql/mysql.sock' (2 "No such file or directory")
ERROR: <core> [db.c:318]: db_do_init2(): could not add connection to the
pool
ERROR: htable [ht_db.c:92]: ht_db_open_con(): failed to connect to the
database
My local db is located at /myqdata/mysiprdb/data where is the mysiprdb.sock
file. But the log shows that Kamailio is looking for
/var/lib/mysql/mysql.sock.
Does this error make sense to you ?
Is it possible to fix this problem by configuration in Kamailio ?
My kamailio.cfg script contains :
# ----- htable
modparam("htable", "db_url",
"mysql://[kamailio]/siprouter")
modparam("htable", "fetch_rows", 1000)
modparam("htable", "htable",
"mbxrangeHash=>size=4;dbtable=mbxrange;")
modparam("htable", "htable",
"abpqHash=>size=12;dbtable=abpq;")
modparam("htable", "htable",
"zabpqHash=>size=12;dbtable=zabpq;")
modparam("htable", "htable",
"propertiesHash=>size=4;dbtable=properties;")
In the /myqdata/mysiprdb/data/my.cnf, I added the following entries for
Kamailio:
[kamailio]
socket = /myqdata/mysiprdb/data/mysiprdb.sock
user = siprouter
password = ##########
default-character-set = utf8
Thanks all for help.
Cordialement.
Patrick GINHOUX
10:01 a.m.
Am Dienstag, 24. Juli 2018, 10:20:01 CEST schrieb Ginhoux, Patrick:
I run Kamailio 5.0.1 with MariaDB database.
There is no issue at the initialization, meaning the db is opened by
kamailio and the hash tables loaded from the db tables.
Hello Patrick,
this is strange. Normally if it can initialize correctly during startup, then
it also should be able to use the database later on.
I did a quick check of the htable module in the repository. There have been a
few fixes related to rpc commands and also a bit related to the database in
the last year. But I did not saw from the git logs anything like you
described.
Nevertheless, you should try to setup the latest 5.0 release (5.0.7) - maybe
on a test system and see if the error is also happening there. There should be
no changes in database or configuration comparing to 5.0.1.
Best regards,
Henning
Example:
# kamcmd htable.dump propertiesHash
[..]
But the htable.reload command fails:
error: 500 - Failed to open htable db connection
The Kamailio log reports that it can't connect the db :
DEBUG: ctl [../../core/io_wait.h:380]: io_watch_add(): DBG:
io_watch_add(0x7f68c74ab300, 10, 3, 0xdc9410), fd_no=1
DEBUG: ctl [io_listener.c:442]: handle_new_connect(): handle_stream read:
new connection (1) on /var/run/kamailio//kamailio_ctl
DEBUG: <core> [core/sr_module.c:694]: find_mod_export_record():
find_export_record: found <db_bind_api> in module db_mysql
[/usr/lib64/kamailio/modules/db_mysql.so]
DEBUG: <core> [db.c:209]: db_bind_mod(): using db bind api for db_mysql
DEBUG: <core> [db.c:314]: db_do_init2(): connection 0x7f68cc354c10 not found
in pool
DEBUG: db_mysql [km_my_con.c:98]: db_mysql_new_connection(): opening
connection: mysql://xxxx:xxxx@/siprouter
ERROR: db_mysql [km_my_con.c:124]: db_mysql_new_connection(): driver error:
Can't connect to local MySQL server through socket
'/var/lib/mysql/mysql.sock' (2 "No such file or directory")
ERROR: <core> [db.c:318]: db_do_init2(): could not add connection to the
pool
ERROR: htable [ht_db.c:92]: ht_db_open_con(): failed to connect to the
database
My local db is located at /myqdata/mysiprdb/data where is the mysiprdb.sock
file. But the log shows that Kamailio is looking for
/var/lib/mysql/mysql.sock.
Does this error make sense to you ?
Is it possible to fix this problem by configuration in Kamailio ?
My kamailio.cfg script contains :
# ----- htable
modparam("htable", "db_url",
"mysql://[kamailio]/siprouter")
modparam("htable", "fetch_rows", 1000)
modparam("htable", "htable",
"mbxrangeHash=>size=4;dbtable=mbxrange;")
modparam("htable", "htable",
"abpqHash=>size=12;dbtable=abpq;")
modparam("htable", "htable",
"zabpqHash=>size=12;dbtable=zabpq;")
modparam("htable", "htable",
"propertiesHash=>size=4;dbtable=properties;")
In the /myqdata/mysiprdb/data/my.cnf, I added the following entries for
Kamailio:
[kamailio]
socket = /myqdata/mysiprdb/data/mysiprdb.sock
user = siprouter
password = ##########
default-character-set = utf8
Thanks all for help.
Cordialement.
Patrick GINHOUX
--
Henning Westerholt
https://skalatan.de/blog/
10:33 a.m.
Hi Henning,
Thanks for your review.
As you said, that's strange behavior.
So I'm going to upgrade to 5.0.7, the time to set up a server. I'll keep you
posted asap.
Cordialement.
Patrick GINHOUX
Unisys | +33 1 46 69 52 12 | +33 6 60 32 24 74 | patrick.ginhoux(a)unisys.com
-----Message d'origine-----
De : Henning Westerholt <hw(a)kamailio.org>
Envoyé : jeudi 2 août 2018 09:02
À : sr-users(a)lists.kamailio.org
Cc : Ginhoux, Patrick <patrick.ginhoux(a)fr.unisys.com>
Objet : Re: [SR-Users] kamcmd htable.reload propertiesHash problem
Am Dienstag, 24. Juli 2018, 10:20:01 CEST schrieb Ginhoux, Patrick:
I run Kamailio 5.0.1 with MariaDB database.
There is no issue at the initialization, meaning the db is opened by
kamailio and the hash tables loaded from the db tables.
Hello Patrick,
this is strange. Normally if it can initialize correctly during startup,
then
it also should be able to use the database later on.
I did a quick check of the htable module in the repository. There have been
a
few fixes related to rpc commands and also a bit related to the database in
the last year. But I did not saw from the git logs anything like you
described.
Nevertheless, you should try to setup the latest 5.0 release (5.0.7) - maybe
on a test system and see if the error is also happening there. There should
be
no changes in database or configuration comparing to 5.0.1.
Best regards,
Henning
Example:
# kamcmd htable.dump propertiesHash
[..]
But the htable.reload command fails:
error: 500 - Failed to open htable db connection
The Kamailio log reports that it can't connect the db :
DEBUG: ctl [../../core/io_wait.h:380]: io_watch_add(): DBG:
io_watch_add(0x7f68c74ab300, 10, 3, 0xdc9410), fd_no=1
DEBUG: ctl [io_listener.c:442]: handle_new_connect(): handle_stream read:
new connection (1) on /var/run/kamailio//kamailio_ctl
DEBUG: <core> [core/sr_module.c:694]: find_mod_export_record():
find_export_record: found <db_bind_api> in module db_mysql
[/usr/lib64/kamailio/modules/db_mysql.so]
DEBUG: <core> [db.c:209]: db_bind_mod(): using db bind api for db_mysql
DEBUG: <core> [db.c:314]: db_do_init2(): connection 0x7f68cc354c10 not
found
in pool
DEBUG: db_mysql [km_my_con.c:98]: db_mysql_new_connection(): opening
connection: mysql://xxxx:xxxx@/siprouter
ERROR: db_mysql [km_my_con.c:124]: db_mysql_new_connection(): driver
error:
Can't connect to local MySQL server through
socket
'/var/lib/mysql/mysql.sock' (2 "No such file or directory")
ERROR: <core> [db.c:318]: db_do_init2(): could not add connection to the
pool
ERROR: htable [ht_db.c:92]: ht_db_open_con(): failed to connect to the
database
My local db is located at /myqdata/mysiprdb/data where is the
mysiprdb.sock
file. But the log shows that Kamailio is looking for
/var/lib/mysql/mysql.sock.
Does this error make sense to you ?
Is it possible to fix this problem by configuration in Kamailio ?
My kamailio.cfg script contains :
# ----- htable
modparam("htable", "db_url",
"mysql://[kamailio]/siprouter")
modparam("htable", "fetch_rows", 1000)
modparam("htable", "htable",
"mbxrangeHash=>size=4;dbtable=mbxrange;")
modparam("htable", "htable",
"abpqHash=>size=12;dbtable=abpq;")
modparam("htable", "htable",
"zabpqHash=>size=12;dbtable=zabpq;")
modparam("htable", "htable",
"propertiesHash=>size=4;dbtable=properties;")
In the /myqdata/mysiprdb/data/my.cnf, I added the following entries for
Kamailio:
[kamailio]
socket = /myqdata/mysiprdb/data/mysiprdb.sock
user = siprouter
password = ##########
default-character-set = utf8
Thanks all for help.
Cordialement.
Patrick GINHOUX
--
Henning Westerholt
https://skalatan.de/blog/
3 Aug
3 Aug
8:56 a.m.
Hi Henning,
Instead of installing a new server, I tried to upgrade the one running the
5.0.1 level. It has the following packages installed:
kamailio-perl-5.0.1-1.1.x86_64
kamailio-5.0.1-1.1.x86_64
kamailio-mysql-5.0.1-1.1.x86_64
kamailio-snmpstats-5.0.1-1.1.x86_64
So I have download the 5.0.7 packages into a separate folder:
kamailio-rpms_5.0.7
kamailio-5.0.7-1.el7.x86_64.rpm
kamailio-mysql-5.0.7-1.el7.x86_64.rpm
kamailio-perl-5.0.7-1.el7.x86_64.rpm
kamailio-snmpstats-5.0.7-1.el7.x86_64.rpm
kamailio-ims-5.0.7-1.el7.x86_64.rpm
The update command rpm -Uvh --force kamailio* detects a dependency on the
mod_perl package :
warning: kamailio-5.0.7-1.el7.x86_64.rpm: Header V3 DSA/SHA1 Signature, key
ID 941fdbdd: NOKEY
error: Failed dependencies:
mod_perl is needed by kamailio-perl-5.0.7-1.el7.x86_64
I try to find this mod_perl package but it does no longer exist for RedHat
7. We can find multiple articles referencing this change in RHEL.
It seems there is an alternative way to get this module in a EPEL repository
(https://huntingbears.nl/2013/12/17/no-mod_perl-in-rhel-7-and-centos-7/).
It is to me a huge work to simply update my current Kamailio to 5.0.7.
Does this mod_perl change makes sense to you ?
Have you an idea to get rid of this dependency?
Thank in advance for your suggestion .
Cordialement.
Patrick GINHOUX
Unisys | +33 1 46 69 52 12 | +33 6 60 32 24 74 | patrick.ginhoux(a)unisys.com
-----Message d'origine-----
De : Ginhoux, Patrick
Envoyé : jeudi 2 août 2018 09:33
À : 'Henning Westerholt' <hw(a)kamailio.org>
Cc : sr-users(a)lists.kamailio.org
Objet : RE: [SR-Users] kamcmd htable.reload propertiesHash problem
Hi Henning,
Thanks for your review.
As you said, that's strange behavior.
So I'm going to upgrade to 5.0.7, the time to set up a server. I'll keep you
posted asap.
Cordialement.
Patrick GINHOUX
Unisys | +33 1 46 69 52 12 | +33 6 60 32 24 74 |
<mailto:patrick.ginhoux@unisys.com> patrick.ginhoux(a)unisys.com
-----Message d'origine-----
De : Henning Westerholt < <mailto:hw@kamailio.org> hw(a)kamailio.org
Envoyé : jeudi 2 août 2018 09:02
À : <mailto:sr-users@lists.kamailio.org> sr-users(a)lists.kamailio.org
Cc : Ginhoux, Patrick < <mailto:patrick.ginhoux@fr.unisys.com>
patrick.ginhoux(a)fr.unisys.com>
Objet : Re: [SR-Users] kamcmd htable.reload propertiesHash problem
Am Dienstag, 24. Juli 2018, 10:20:01 CEST schrieb Ginhoux, Patrick:
I run Kamailio 5.0.1 with MariaDB database.
There is no issue at the initialization, meaning the
db is opened by
kamailio and the hash tables loaded from the db
tables.
Hello Patrick,
this is strange. Normally if it can initialize correctly during startup,
then
it also should be able to use the database later on.
I did a quick check of the htable module in the repository. There have been
a
few fixes related to rpc commands and also a bit related to the database in
the last year. But I did not saw from the git logs anything like you
described.
Nevertheless, you should try to setup the latest 5.0 release (5.0.7) - maybe
on a test system and see if the error is also happening there. There should
be
no changes in database or configuration comparing to 5.0.1.
Best regards,
Henning
Example:
# kamcmd htable.dump propertiesHash
[..]
But the htable.reload command fails:
error: 500 - Failed to open htable db connection
The Kamailio log reports that it can't connect the
db :
DEBUG: ctl [../../core/io_wait.h:380]: io_watch_add():
DBG:
io_watch_add(0x7f68c74ab300, 10, 3, 0xdc9410), fd_no=1
DEBUG: ctl [io_listener.c:442]: handle_new_connect():
handle_stream read:
new connection (1) on /var/run/kamailio//kamailio_ctl
DEBUG: <core> [core/sr_module.c:694]:
find_mod_export_record():
find_export_record: found <db_bind_api> in
module db_mysql
[/usr/lib64/kamailio/modules/db_mysql.so]
DEBUG: <core> [db.c:209]: db_bind_mod(): using
db bind api for db_mysql
DEBUG: <core> [db.c:314]: db_do_init2():
connection 0x7f68cc354c10 not
found
in pool
DEBUG: db_mysql [km_my_con.c:98]:
db_mysql_new_connection(): opening
connection: mysql://xxxx:xxxx@/siprouter
ERROR: db_mysql [km_my_con.c:124]:
db_mysql_new_connection(): driver
error:
Can't connect to local MySQL server through socket
'/var/lib/mysql/mysql.sock' (2 "No such
file or directory")
ERROR: <core> [db.c:318]: db_do_init2(): could
not add connection to the
pool
ERROR: htable [ht_db.c:92]: ht_db_open_con(): failed
to connect to the
database
My local db is located at /myqdata/mysiprdb/data where
is the
mysiprdb.sock
file. But the log shows that Kamailio is looking for
/var/lib/mysql/mysql.sock.
Does this error make sense to you ?
Is it possible to fix this problem by configuration in
Kamailio ?
My kamailio.cfg script contains :
# ----- htable
modparam("htable", "db_url",
"mysql://[kamailio]/siprouter")
modparam("htable", "fetch_rows",
1000)
modparam("htable", "htable",
"mbxrangeHash=>size=4;dbtable=mbxrange;")
modparam("htable", "htable",
"abpqHash=>size=12;dbtable=abpq;")
modparam("htable", "htable",
"zabpqHash=>size=12;dbtable=zabpq;")
modparam("htable", "htable",
"propertiesHash=>size=4;dbtable=properties;")
In the /myqdata/mysiprdb/data/my.cnf, I added the
following entries for
Kamailio:
[kamailio]
socket = /myqdata/mysiprdb/data/mysiprdb.sock
user = siprouter
password = ##########
default-character-set = utf8
Thanks all for help.
Cordialement.
Patrick GINHOUX
--
Henning Westerholt
<https://skalatan.de/blog/> https://skalatan.de/blog/
9:42 a.m.
Am Freitag, 3. August 2018, 07:56:28 CEST schrieb Ginhoux, Patrick:
Instead of installing a new server, I tried to upgrade
the one running the
5.0.1 level. It has the following packages installed:
kamailio-perl-5.0.1-1.1.x86_64
kamailio-5.0.1-1.1.x86_64
kamailio-mysql-5.0.1-1.1.x86_64
kamailio-snmpstats-5.0.1-1.1.x86_64
So I have download the 5.0.7 packages into a separate folder:
kamailio-rpms_5.0.7
kamailio-5.0.7-1.el7.x86_64.rpm
kamailio-mysql-5.0.7-1.el7.x86_64.rpm
kamailio-perl-5.0.7-1.el7.x86_64.rpm
kamailio-snmpstats-5.0.7-1.el7.x86_64.rpm
kamailio-ims-5.0.7-1.el7.x86_64.rpm
The update command rpm -Uvh --force kamailio* detects a dependency on the
mod_perl package :
warning: kamailio-5.0.7-1.el7.x86_64.rpm: Header V3 DSA/SHA1 Signature, key
ID 941fdbdd: NOKEY
error: Failed dependencies:
mod_perl is needed by kamailio-perl-5.0.7-1.el7.x86_64
I try to find this mod_perl package but it does no longer exist for RedHat
7. We can find multiple articles referencing this change in RHEL.
It seems there is an alternative way to get this module in a EPEL repository
(https://huntingbears.nl/2013/12/17/no-mod_perl-in-rhel-7-and-centos-7/).
It is to me a huge work to simply update my current Kamailio to 5.0.7.
Does this mod_perl change makes sense to you ?
Have you an idea to get rid of this dependency?
Hello Patrick,
probably a stupid question, but do you actually use the perl module inside
your kamailio cfg? If not - I would suggest to just remove the 5.0.1 perl
module, and also not install it for 5.0.7.
If you need it - the quoted artice states that its actually not difficult to
install mod_perl from the EPEL repository. This looks quite ok: "EPEL is the
high-quality RPM collection for RHEL and CentOS linux, maintened by the Fedora
project.".
Best regards,
Henning
--
Henning Westerholt
https://skalatan.de/blog/
10:29 a.m.
Unfortunately, I use the perl module in my kamailio.cfg.
So you're correct, I could install the mod_perl from the EPEL project. This
is possible on my test server in my lab.
At the moment, I had collected manually all rpm packages required for 5.0.1
(like Perl or snmp packages), that' was already a huge work.
Now if at each stream there is new dependencies, I would have to solve the
dependencies for other repo like with the EPEL repo.
But in a next step, I have to do the same installation on a customer site on
preimaged server with the following restrictions :
- from this site, I have no access to the internet (That's why, up to new, I
only download the packages I need)
- the preimaged server are RHEL 7.4 server without no required package
removed.
As said, I configured the EPEL repo on my test server and then try to
installed to mod_perl module. I starts ok but fails for other dependencies
(see attached).
So upgrading from Kamailio 5.0.1 to 5.0.7 is not as simple as I expected.
I hope I'm clear in my explanation.
Cordialement.
Patrick GINHOUX
Unisys | +33 1 46 69 52 12 | +33 6 60 32 24 74 | patrick.ginhoux(a)unisys.com
-----Message d'origine-----
De : Henning Westerholt <hw(a)kamailio.org>
Envoyé : vendredi 3 août 2018 08:43
À : Ginhoux, Patrick <patrick.ginhoux(a)fr.unisys.com>
Cc : sr-users(a)lists.kamailio.org
Objet : Re: [SR-Users] kamcmd htable.reload propertiesHash problem
Am Freitag, 3. August 2018, 07:56:28 CEST schrieb Ginhoux, Patrick:
Instead of installing a new server, I tried to upgrade
the one running the
5.0.1 level. It has the following packages installed:
kamailio-perl-5.0.1-1.1.x86_64
kamailio-5.0.1-1.1.x86_64
kamailio-mysql-5.0.1-1.1.x86_64
kamailio-snmpstats-5.0.1-1.1.x86_64
So I have download the 5.0.7 packages into a separate folder:
kamailio-rpms_5.0.7
kamailio-5.0.7-1.el7.x86_64.rpm
kamailio-mysql-5.0.7-1.el7.x86_64.rpm
kamailio-perl-5.0.7-1.el7.x86_64.rpm
kamailio-snmpstats-5.0.7-1.el7.x86_64.rpm
kamailio-ims-5.0.7-1.el7.x86_64.rpm
The update command rpm -Uvh --force kamailio* detects a dependency on
the
mod_perl package :
warning: kamailio-5.0.7-1.el7.x86_64.rpm: Header V3 DSA/SHA1 Signature,
key
ID 941fdbdd: NOKEY
error: Failed dependencies:
mod_perl is needed by kamailio-perl-5.0.7-1.el7.x86_64
I try to find this mod_perl package but it does no longer exist for RedHat
7. We can find multiple articles referencing this change in RHEL.
It seems there is an alternative way to get this module in a EPEL
repository
(https://huntingbears.nl/2013/12/17/no-mod_perl-in-rhel-7-and-centos-7/).
It is to me a huge work to simply update my current Kamailio to 5.0.7.
Does this mod_perl change makes sense to you ?
Have you an idea to get rid of this dependency?
Hello Patrick,
probably a stupid question, but do you actually use the perl module inside
your kamailio cfg? If not - I would suggest to just remove the 5.0.1 perl
module, and also not install it for 5.0.7.
If you need it - the quoted artice states that its actually not difficult to
install mod_perl from the EPEL repository. This looks quite ok: "EPEL is the
high-quality RPM collection for RHEL and CentOS linux, maintened by the
Fedora
project.".
Best regards,
Henning
--
Henning Westerholt
https://skalatan.de/blog/
4 Aug
4 Aug
11:59 a.m.
Am Freitag, 3. August 2018, 09:29:40 CEST schrieb Ginhoux, Patrick:
Unfortunately, I use the perl module in my
kamailio.cfg.
So you're correct, I could install the mod_perl from the EPEL project. This
is possible on my test server in my lab.
At the moment, I had collected manually all rpm packages required for 5.0.1
(like Perl or snmp packages), that' was already a huge work.
Now if at each stream there is new dependencies, I would have to solve the
dependencies for other repo like with the EPEL repo.
But in a next step, I have to do the same installation on a customer site on
preimaged server with the following restrictions :
- from this site, I have no access to the internet (That's why, up to new, I
only download the packages I need)
- the preimaged server are RHEL 7.4 server without no required package
removed.
As said, I configured the EPEL repo on my test server and then try to
installed to mod_perl module. I starts ok but fails for other dependencies
(see attached).
So upgrading from Kamailio 5.0.1 to 5.0.7 is not as simple as I expected.
I hope I'm clear in my explanation.
Hello Patrick,
I understand. Unfortunately I have no Red Hat 7 system available at the moment
that I could test locally.
I see that its no easy for you to update. But in my opinion you really should
considering an update, especially as there are many bugs fixed in 5.0.7 (also
some security related).
If you can't install from an repository, you can always build from the 5.0
stable branch source. There is documentation in our wiki on the process. This
is something a lot of our users do. Or you can build an own (local) RPM packet
and install this.
Maybe somebody else with more insight into the latest htable fixes can point
to a recent fix - but even this needs to be installed somehow on your side.
Best regards,
Henning
-----Message d'origine-----
De : Henning Westerholt <hw(a)kamailio.org>
Envoyé : vendredi 3 août 2018 08:43
À : Ginhoux, Patrick <patrick.ginhoux(a)fr.unisys.com>
Cc : sr-users(a)lists.kamailio.org
Objet : Re: [SR-Users] kamcmd htable.reload propertiesHash problem
Am Freitag, 3. August 2018, 07:56:28 CEST schrieb Ginhoux, Patrick:
--
Henning Westerholt
https://skalatan.de/blog/
Instead of installing a new server, I tried to
upgrade the one running the
5.0.1 level. It has the following packages installed:
kamailio-perl-5.0.1-1.1.x86_64
kamailio-5.0.1-1.1.x86_64
kamailio-mysql-5.0.1-1.1.x86_64
kamailio-snmpstats-5.0.1-1.1.x86_64
So I have download the 5.0.7 packages into a separate folder:
kamailio-rpms_5.0.7
kamailio-5.0.7-1.el7.x86_64.rpm
kamailio-mysql-5.0.7-1.el7.x86_64.rpm
kamailio-perl-5.0.7-1.el7.x86_64.rpm
kamailio-snmpstats-5.0.7-1.el7.x86_64.rpm
kamailio-ims-5.0.7-1.el7.x86_64.rpm
The update command rpm -Uvh --force kamailio* detects a dependency on
the
mod_perl package :
warning: kamailio-5.0.7-1.el7.x86_64.rpm: Header V3 DSA/SHA1 Signature,
key
ID 941fdbdd: NOKEY
error: Failed dependencies:
mod_perl is needed by kamailio-perl-5.0.7-1.el7.x86_64
I try to find this mod_perl package but it does no longer exist for RedHat
7. We can find multiple articles referencing this change in RHEL.
It seems there is an alternative way to get this module in a EPEL
repository
(https://huntingbears.nl/2013/12/17/no-mod_perl-in-rhel-7-and-centos-7/).
It is to me a huge work to simply update my current Kamailio to 5.0.7.
Does this mod_perl change makes sense to you ?
Have you an idea to get rid of this dependency?
Hello Patrick,
probably a stupid question, but do you actually use the perl module inside
your kamailio cfg? If not - I would suggest to just remove the 5.0.1 perl
module, and also not install it for 5.0.7.
If you need it - the quoted artice states that its actually not difficult to
install mod_perl from the EPEL repository. This looks quite ok: "EPEL is the
high-quality RPM collection for RHEL and CentOS linux, maintened by the
Fedora
project.".
Best regards,
Henning
12:46 p.m.
Hi,
I'm thinking about the difficulty to upgrade my Kamailio server from the
5.0.1 level to the 5.0.7 level because of dependencies.
This difficulty comes from because the kamailio-perl-5.0.7-1.el7.x86_64.rpm
requires the mod_perl module (and this one no longer exists on a RHEL 7
distro).
My question then is what has been changed between the 5.0.1 and the 5.0.7
level to require the mod_perl module ?
As my server still run RHEL 7.4, why I don't not encounter the issue with
the 5.0.1 ?
Any thoughts on this analysis ?
Cordialement.
Patrick GINHOUX
Unisys | +33 1 46 69 52 12 | +33 6 60 32 24 74 | patrick.ginhoux(a)unisys.com
-----Message d'origine-----
De : sr-users <sr-users-bounces(a)lists.kamailio.org> De la part de Ginhoux,
Patrick
Envoyé : vendredi 3 août 2018 09:30
À : Henning Westerholt <hw(a)kamailio.org>
Cc : sr-users(a)lists.kamailio.org
Objet : Re: [SR-Users] kamcmd htable.reload propertiesHash problem
Unfortunately, I use the perl module in my kamailio.cfg.
So you're correct, I could install the mod_perl from the EPEL project. This
is possible on my test server in my lab.
At the moment, I had collected manually all rpm packages required for 5.0.1
(like Perl or snmp packages), that' was already a huge work.
Now if at each stream there is new dependencies, I would have to solve the
dependencies for other repo like with the EPEL repo.
But in a next step, I have to do the same installation on a customer site on
preimaged server with the following restrictions :
- from this site, I have no access to the internet (That's why, up to new, I
only download the packages I need)
- the preimaged server are RHEL 7.4 server without no required package
removed.
As said, I configured the EPEL repo on my test server and then try to
installed to mod_perl module. I starts ok but fails for other dependencies
(see attached).
So upgrading from Kamailio 5.0.1 to 5.0.7 is not as simple as I expected.
I hope I'm clear in my explanation.
Cordialement.
Patrick GINHOUX
Unisys | +33 1 46 69 52 12 | +33 6 60 32 24 74 | patrick.ginhoux(a)unisys.com
-----Message d'origine-----
De : Henning Westerholt <hw(a)kamailio.org>
Envoyé : vendredi 3 août 2018 08:43
À : Ginhoux, Patrick <patrick.ginhoux(a)fr.unisys.com>
Cc : sr-users(a)lists.kamailio.org
Objet : Re: [SR-Users] kamcmd htable.reload propertiesHash problem
Am Freitag, 3. August 2018, 07:56:28 CEST schrieb Ginhoux, Patrick:
Instead of installing a new server, I tried to upgrade
the one running the
5.0.1 level. It has the following packages installed:
kamailio-perl-5.0.1-1.1.x86_64
kamailio-5.0.1-1.1.x86_64
kamailio-mysql-5.0.1-1.1.x86_64
kamailio-snmpstats-5.0.1-1.1.x86_64
So I have download the 5.0.7 packages into a separate folder:
kamailio-rpms_5.0.7
kamailio-5.0.7-1.el7.x86_64.rpm
kamailio-mysql-5.0.7-1.el7.x86_64.rpm
kamailio-perl-5.0.7-1.el7.x86_64.rpm
kamailio-snmpstats-5.0.7-1.el7.x86_64.rpm
kamailio-ims-5.0.7-1.el7.x86_64.rpm
The update command rpm -Uvh --force kamailio* detects a dependency on
the
mod_perl package :
warning: kamailio-5.0.7-1.el7.x86_64.rpm: Header V3 DSA/SHA1 Signature,
key
ID 941fdbdd: NOKEY
error: Failed dependencies:
mod_perl is needed by kamailio-perl-5.0.7-1.el7.x86_64
I try to find this mod_perl package but it does no longer exist for RedHat
7. We can find multiple articles referencing this change in RHEL.
It seems there is an alternative way to get this module in a EPEL
repository
(https://huntingbears.nl/2013/12/17/no-mod_perl-in-rhel-7-and-centos-7/).
It is to me a huge work to simply update my current Kamailio to 5.0.7.
Does this mod_perl change makes sense to you ?
Have you an idea to get rid of this dependency?
Hello Patrick,
probably a stupid question, but do you actually use the perl module inside
your kamailio cfg? If not - I would suggest to just remove the 5.0.1 perl
module, and also not install it for 5.0.7.
If you need it - the quoted artice states that its actually not difficult to
install mod_perl from the EPEL repository. This looks quite ok: "EPEL is the
high-quality RPM collection for RHEL and CentOS linux, maintened by the
Fedora
project.".
Best regards,
Henning
--
Henning Westerholt
https://skalatan.de/blog/
7 Aug
7 Aug
5:50 p.m.
Hi Henning,
Some update on my upgrade to kamailio 5.0.7.
First of all, I posted other question related to the mod_perl requirement,
etc... and I got some interesting answers.
I succeeded to get rid of the dependencies and now my server is upgraded to
5.0.7. Unfortunately, Kamailio doesn't start and is in a kind of loop.
The kamailio.log contains entries I've never seen before with 5.0.1. Extract
of the log :
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/cfg.y:1623]:
yyparse(): loading module app_perl.so
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/sr_module.c:575]: load_module(): trying to load
</usr/lib64/kamailio/modules/app_perl.so>
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/sr_module.c:624]: load_module(): attempt to lookup exports structure
failed - dlerror: /usr/lib64/kamailio/modules/app_perl.so: undefined symbol:
exports
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/sr_module.c:636]: load_module(): looking up exports with name:
_app_perl_exports
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/sr_module.c:652]: load_module():
/usr/lib64/kamailio/modules/app_perl.so: exports dlflags interface is
deprecated and it will not be supported in newer versions; consider using
mod_register() instead
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/sr_module.c:624]: load_module(): attempt to lookup exports structure
failed - dlerror: /usr/lib64/kamailio/modules/app_perl.so: undefined symbol:
exports
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/sr_module.c:636]: load_module(): looking up exports with name:
_app_perl_exports
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/cfg.lex:1713]:
pp_define(): defining id: MOD_app_perl
.
.
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/cfg.lex:1713]:
pp_define(): defining id: NODETYPE_MGCF
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/cfg.lex:1803]:
pp_define_set(): ### setting define ID [NODETYPE_MGCF] value [1]
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/cfg.lex:1713]:
pp_define(): defining id: NODETYPE_MMM
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/cfg.lex:1803]:
pp_define_set(): ### setting define ID [NODETYPE_MMM] value [2]
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/cfg.lex:1713]:
pp_define(): defining id: MGCF_NODESTRING
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/cfg.lex:1803]:
pp_define_set(): ### setting define ID [MGCF_NODESTRING] value ["MGCF"]
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/modparam.c:83]:
set_mod_param_regex(): 'app_perl' matches module 'app_perl'
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/sr_module.c:794]: find_param_export(): found <modpath> in module
app_perl [/usr/lib64/kamailio/modules/app_perl.so]
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/modparam.c:99]:
set_mod_param_regex(): found <modpath> in module app_perl
[/usr/lib64/kamailio/modules/app_perl.so]
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/modparam.c:83]:
set_mod_param_regex(): 'app_perl' matches module 'app_perl'
Aug 7 10:02:09 vm-siprouter74 kamailio: WARNING: <core> [core/cfg.y:3388]:
warn_at(): warning in config file /etc/kamailio/kamailio.cfg, line 978,
column 6-13: constant value in if(...)
Then lot of [core/route_struct.c:nnnn] entries, I have never seen before
with kamailio 5.0.1 :
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:467]: print_action(): f_ptr<0x7f65e4973bd0>
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:493]: print_action(): , 2
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:524]: print_action(): , "L_WARN"
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:546]: print_action(): );
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:545]: print_action(): };
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:519]: print_action(): } else {
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:545]: print_action(): };
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:442]: print_action(): assign(
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:483]: print_action(): type<21>
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:517]: print_action(): , type<22>
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:546]: print_action(): );
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:401]: print_action(): if (
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:483]: print_action(): type<22>
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:485]: print_action(): ) {
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:442]: print_action(): assign(
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:483]: print_action(): type<21>
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:517]: print_action(): , type<22>
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:546]: print_action(): );
This sequence of [core/route_struct.c:nnnn] entries ends with :
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:467]: print_action(): f_ptr<0x7f65e4973bd0>
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:493]: print_action(): , 2
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:524]: print_action(): , "L_DBG"
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:546]: print_action(): );
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/route.c:2134]:
print_rl():
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/route.c:129]:
route_add(): mapping routing block (0xaff280)[core:receive-parse-error] to 5
Aug 7 10:02:09 vm-siprouter74 kamailio: INFO: <core> [core/sctp_core.c:75]:
sctp_core_check_support(): SCTP API not enabled - if you want to use it,
load sctp module
Aug 7 10:02:09 vm-siprouter74 kamailio: WARNING: <core>
[core/socket_info.c:1314]: fix_hostname(): could not rev. resolve
129.227.83.78
Aug 7 10:02:09 vm-siprouter74 kamailio: WARNING: <core>
[core/socket_info.c:1314]: fix_hostname(): could not rev. resolve
129.227.82.79
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/mem/pkg.c:100]:
pkg_print_manager(): pkg - using memory manager: q_malloc
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/mem/shm.c:277]:
shm_print_manager(): shm - using memory manager: q_malloc
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/cfg/cfg.c:176]:
cfg_declare(): DEBUG: register_cfg_def(): new config group has been
registered: 'core' (num=52, size=208)
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/cfg/cfg.c:176]:
cfg_declare(): DEBUG: register_cfg_def(): new config group has been
registered: 'tcp' (num=26, size=104)
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/timer.c:256]:
init_timer(): starting with *ticks=1478539463
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/timer.c:298]:
init_timer(): timer_list between 0x7f65d9accfd0 and 0x7f65d9b10fd0
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/pt.c:145]:
register_procs(): registering new processes: 0 (old) + 1 (new) = 1 (total)
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/daemonize.c:207]: enable_dumpable(): trying enable core dumping...
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/daemonize.c:225]: enable_dumpable(): core dumping is enabled now
(1)...
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: <core>
[core/daemonize.c:583]: set_core_dump(): core dump limits set to
18446744073709551615
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: <core>
[core/async_task.c:108]: async_task_init(): start initializing asynk task
framework
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: <core>
[core/sr_module.c:971]: init_mod(): db_mysql
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: db_mysql
[km_db_mysql.c:86]: kam_mysql_mod_init(): MySQL client version is
10.1.30-MariaDB
Then the jsonrpcs mod-init fails to change the owner/group for the
/var/run/kamailio/kamailio_rpc_fifo :
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: <core>
[core/sr_module.c:971]: init_mod(): jsonrpcs
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: jsonrpcs
[jsonrpcs_mod.c:1087]: mod_init(): preparing to listen on fifo file:
/var/run/kamailio/kamailio_rpc_fifo
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: jsonrpcs
[jsonrpcs_fifo.c:151]: jsonrpc_init_fifo_file(): testing if fifo file exists
...
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: jsonrpcs
[jsonrpcs_fifo.c:72]: jsonrpc_init_fifo_server(): FIFO created @
/var/run/kamailio/kamailio_rpc_fifo
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: ERROR: jsonrpcs
[jsonrpcs_fifo.c:82]: jsonrpc_init_fifo_server(): Failed to change the
owner/group for /var/run/kamailio/kamailio_rpc_fifo to 248.248; Operation
not permitted[1]
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: CRITICAL: jsonrpcs
[jsonrpcs_fifo.c:209]: jsonrpc_init_fifo_file(): failed to init jsonrpc fifo
server file stream
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: ERROR: jsonrpcs
[jsonrpcs_fifo.c:539]: jsonrpc_fifo_mod_init(): cannot initialize fifo
transport
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: ERROR: jsonrpcs
[jsonrpcs_mod.c:1090]: mod_init(): cannot initialize fifo transport
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: ERROR: jsonrpcs
[jsonrpcs_fifo.c:539]: jsonrpc_fifo_mod_init(): cannot initialize fifo
transport
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: ERROR: jsonrpcs
[jsonrpcs_mod.c:1090]: mod_init(): cannot initialize fifo transport
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: ERROR: <core>
[core/sr_module.c:974]: init_mod(): Error while initializing module jsonrpcs
(/usr/lib64/kamailio/modules/jsonrpcs.so)
Then the connection to my MySQL server fails also:
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: <core>
[core/sr_module.c:698]: find_mod_export_record(): find_export_record: found
<db_bind_api> in module db_mysql [/usr/lib64/kamailio/modules/db_mysql.so]
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: <core>
[db.c:209]: db_bind_mod(): using db bind api for db_mysql
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: <core>
[db.c:314]: db_do_init2(): connection 0x7f65e4974868 not found in pool
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: db_mysql
[km_my_con.c:98]: db_mysql_new_connection(): opening connection:
mysql://xxxx:xxxx@localhost/siprouter
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: ERROR: db_mysql
[km_my_con.c:129]: db_mysql_new_connection(): driver error: Can't connect to
local MySQL server through socket '/var/lib/mysql/mysql.sock' (2 "No such
file or directory")
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: ERROR: <core>
[db.c:318]: db_do_init2(): could not add connection to the pool
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: ERROR: htable
[ht_db.c:92]: ht_db_open_con(): failed to connect to the database
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: tm
[t_funcs.c:86]: tm_shutdown(): DEBUG: tm_shutdown : start
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: tm
[t_funcs.c:89]: tm_shutdown(): DEBUG: tm_shutdown : emptying hash table
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: tm
[t_funcs.c:91]: tm_shutdown(): DEBUG: tm_shutdown : removing semaphores
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: tm
[t_funcs.c:93]: tm_shutdown(): DEBUG: tm_shutdown : destroying tmcb lists
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: tm
[t_funcs.c:96]: tm_shutdown(): DEBUG: tm_shutdown : done
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: INFO: <core>
[core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: <core>
[core/mem/shm.c:174]: shm_core_lock_destroy(): destroying the shared memory
lock
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: <core>
[core/mem/shm.c:266]: shm_destroy_manager(): destroying memory manager:
q_malloc
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: <core>
[core/mem/pkg.c:89]: pkg_destroy_manager(): destroying memory manager:
q_malloc
Hereafter I can see that kamailio is looping :
Aug 7 10:02:09 vm-siprouter74 kamailio: WARNING: <core> [core/cfg.y:3388]:
warn_at(): warning in config file /etc/kamailio/kamailio.cfg, line 978,
column 6-13: constant value in if(...)
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:546]: print_action(): );
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:448]: print_action(): UNKNOWN(
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:483]: print_action(): type<22>
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:442]: print_action(): assign(
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:483]: print_action(): type<21>
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:517]: print_action(): , type<22>
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:546]: print_action(): );
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:442]: print_action(): assign(
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:483]: print_action(): type<21>
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:517]: print_action(): , type<22>
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:546]: print_action(): );
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:401]: print_action(): if (
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:483]: print_action(): type<22>
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:485]: print_action(): ) {
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:418]: print_action(): external_module_call(
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:467]: print_action(): f_ptr<0x7f34c32babd0>
Ive been told that the upgrade from 5.0.1 to 5.0.7 would be simple, but it
is not.
At the moment, I dont know how to fix the different errors above.
So if you or somebody else can help me, that would be good.
Cordialement.
Patrick GINHOUX
-----Message d'origine-----
De : sr-users <sr-users-bounces(a)lists.kamailio.org> De la part de Ginhoux,
Patrick
Envoyé : samedi 4 août 2018 11:46
À : Henning Westerholt <hw(a)kamailio.org>rg>; Kamailio (SER) - Users Mailing
List <sr-users(a)lists.kamailio.org>
Objet : Re: [SR-Users] kamcmd htable.reload propertiesHash problem
Hi,
I'm thinking about the difficulty to upgrade my Kamailio server from the
5.0.1 level to the 5.0.7 level because of dependencies.
This difficulty comes from because the kamailio-perl-5.0.7-1.el7.x86_64.rpm
requires the mod_perl module (and this one no longer exists on a RHEL 7
distro).
My question then is what has been changed between the 5.0.1 and the 5.0.7
level to require the mod_perl module ?
As my server still run RHEL 7.4, why I don't not encounter the issue with
the 5.0.1 ?
Any thoughts on this analysis ?
Cordialement.
Patrick GINHOUX
Unisys | +33 1 46 69 52 12 | +33 6 60 32 24 74 |
<mailto:patrick.ginhoux@unisys.com> patrick.ginhoux(a)unisys.com
-----Message d'origine-----
De : sr-users < <mailto:sr-users-bounces@lists.kamailio.org>
sr-users-bounces(a)lists.kamailio.org> De la part de Ginhoux,
Patrick
Envoyé : vendredi 3 août 2018 09:30
À : Henning Westerholt < <mailto:hw@kamailio.org> hw(a)kamailio.org>
Cc : <mailto:sr-users@lists.kamailio.org> sr-users(a)lists.kamailio.org
Objet : Re: [SR-Users] kamcmd htable.reload propertiesHash problem
Unfortunately, I use the perl module in my kamailio.cfg.
So you're correct, I could install the mod_perl from the EPEL project. This
is possible on my test server in my lab.
At the moment, I had collected manually all rpm packages required for 5.0.1
(like Perl or snmp packages), that' was already a huge work.
Now if at each stream there is new dependencies, I would have to solve the
dependencies for other repo like with the EPEL repo.
But in a next step, I have to do the same installation on a customer site on
preimaged server with the following restrictions :
- from this site, I have no access to the internet (That's why, up to new, I
only download the packages I need)
- the preimaged server are RHEL 7.4 server without no required package
removed.
As said, I configured the EPEL repo on my test server and then try to
installed to mod_perl module. I starts ok but fails for other dependencies
(see attached).
So upgrading from Kamailio 5.0.1 to 5.0.7 is not as simple as I expected.
I hope I'm clear in my explanation.
Cordialement.
Patrick GINHOUX
Unisys | +33 1 46 69 52 12 | +33 6 60 32 24 74 |
<mailto:patrick.ginhoux@unisys.com> patrick.ginhoux(a)unisys.com
-----Message d'origine-----
De : Henning Westerholt < <mailto:hw@kamailio.org> hw(a)kamailio.org
Envoyé : vendredi 3 août 2018 08:43
À : Ginhoux, Patrick < <mailto:patrick.ginhoux@fr.unisys.com>
patrick.ginhoux(a)fr.unisys.com>
Cc : <mailto:sr-users@lists.kamailio.org> sr-users(a)lists.kamailio.org
Objet : Re: [SR-Users] kamcmd htable.reload propertiesHash problem
Am Freitag, 3. August 2018, 07:56:28 CEST schrieb Ginhoux, Patrick:
Instead of installing a new server, I tried to upgrade
the one running the
5.0.1 level. It has the following packages installed:
kamailio-perl-5.0.1-1.1.x86_64
kamailio-5.0.1-1.1.x86_64
kamailio-mysql-5.0.1-1.1.x86_64
kamailio-snmpstats-5.0.1-1.1.x86_64
So I have download the 5.0.7 packages into a separate
folder:
kamailio-rpms_5.0.7
kamailio-5.0.7-1.el7.x86_64.rpm
kamailio-mysql-5.0.7-1.el7.x86_64.rpm
kamailio-perl-5.0.7-1.el7.x86_64.rpm
kamailio-snmpstats-5.0.7-1.el7.x86_64.rpm
kamailio-ims-5.0.7-1.el7.x86_64.rpm
The update command rpm -Uvh --force kamailio*
detects a dependency on
the
mod_perl package :
warning: kamailio-5.0.7-1.el7.x86_64.rpm: Header V3
DSA/SHA1 Signature,
key
ID 941fdbdd: NOKEY
error: Failed dependencies:
mod_perl is needed by
kamailio-perl-5.0.7-1.el7.x86_64
I try to find this mod_perl package but it does no
longer exist for RedHat
7. We can find multiple articles referencing this
change in RHEL.
It seems there is an alternative way to get this
module in a EPEL
repository
(
<https://huntingbears.nl/2013/12/17/no-mod_perl-in-rhel-7-and-centos-7/>
https://huntingbears.nl/2013/12/17/no-mod_perl-in-rhel-7-and-centos-7/).
It is to me a huge work to simply update my current
Kamailio to 5.0.7.
Does this mod_perl change makes sense to you ?
Have you an idea to get rid of this dependency?
Hello Patrick,
probably a stupid question, but do you actually use the perl module inside
your kamailio cfg? If not - I would suggest to just remove the 5.0.1 perl
module, and also not install it for 5.0.7.
If you need it - the quoted artice states that its actually not difficult to
install mod_perl from the EPEL repository. This looks quite ok: "EPEL is the
high-quality RPM collection for RHEL and CentOS linux, maintened by the
Fedora
project.".
Best regards,
Henning
--
Henning Westerholt
<https://skalatan.de/blog/> https://skalatan.de/blog/
9 Aug
9 Aug
10:51 a.m.
Hi Henning,
Some update since recent discussions about the changes between 5.0.1 and
5.0.7 with Sergey Safarov :
- The mod_perl module had been introduced by mistake in the 5.0.7
stream so that new packages are now available (5.0.7-7) without this module,
packages I use to upgrade my server.
- Once the upgrade done to 5.0.7-7 level, I reported 2 problems :
o An error reported by the jsonrpcs module : ERROR: jsonrpcs
[jsonrpcs_fifo.c:82]: jsonrpc_init_fifo_server(): Failed to change the
owner/group for /var/run/kamailio/kamailio_rpc_fifo to 248.248; Operation
not permitted[1]
ð It is fixed now by configuring the USER/GROUP parameters with the correct
values in the systemd unit file
o An error to open the MySQL: ERROR: db_mysql [km_my_con.c:129]:
db_mysql_new_connection(): driver error: Can't connect to local MySQL server
through socket '/var/lib/mysql/mysql.sock' (2 "No such file or
directory")
ð Initially on my Kamailio with 5.0.1, I had created these 2 symbolic links
to get the connection to the local MySQL server:
#Symbolic links for the MySQL to MariaDB change to allow kamailio to locate
the mysql libs and then open the siprouter database
ln -s /opt/mysql/na/10.2.14/lib64/libmysqlclient.so.18.0.0
/usr/lib64/libmysqlclient.so.18
ln -s /myqdata/mysiprdb/data/my.cnf /etc/my.cnf
This was good for kamailio to open the local MySQL server, but it failed to
reload a Hash table; the kamcmd htable.reload propertiesHash returns a
problem :
kamcmd htable.reload propertiesHash
error: 500 - Failed to open htable db connection
The kamailio.log reported that it can't connect the db :
DEBUG: <core> [core/sr_module.c:694]: find_mod_export_record():
find_export_record: found <db_bind_api> in module db_mysql
[/usr/lib64/kamailio/modules/db_mysql.so]
DEBUG: <core> [db.c:209]: db_bind_mod(): using db bind api for db_mysql
DEBUG: <core> [db.c:314]: db_do_init2(): connection 0x7f68cc354c10 not found
in pool
DEBUG: db_mysql [km_my_con.c:98]: db_mysql_new_connection(): opening
connection: mysql://xxxx:xxxx@/siprouter
ERROR: db_mysql [km_my_con.c:124]: db_mysql_new_connection(): driver error:
Can't connect to local MySQL server through socket
'/var/lib/mysql/mysql.sock' (2 "No such file or directory")
ð Now with my Kamailio upgraded with 5.0.7-7, it fails immediately at the
startup to connect the local MySQL server.
DEBUG: <core> [core/sr_module.c:698]: find_mod_export_record():
find_export_record: found <db_bind_api> in module db_mysql
[/usr/lib64/kamailio/modules/db_mysql.so]
DEBUG: <core> [db.c:209]: db_bind_mod(): using db bind api for db_mysql
DEBUG: <core> [db.c:314]: db_do_init2(): connection 0x7f65e4974868 not found
in pool
DEBUG: db_mysql [km_my_con.c:98]: db_mysql_new_connection(): opening
connection: mysql://xxxx:xxxx@localhost/siprouter
ERROR: db_mysql [km_my_con.c:129]: db_mysql_new_connection(): driver error:
Can't connect to local MySQL server through socket
'/var/lib/mysql/mysql.sock' (2 "No such file or directory")
That is a strange behavior versus the one with kamailio 5.0.1, but it is
maybe better as it immediately fails.
In all the case, I had have to do the following the fix the issue :
mkdir /var/lib/mysql
ln -s /myqdata/mysiprdb/data/mysiprdb.sock /var/lib/mysql/mysql.sock
This new symbolic link would then replace the first I had created : ln -s
/myqdata/mysiprdb/data/my.cnf /etc/my.cnf.
If I can consider these problems as fixed, it lets me confused on the manner
the db_mysql module works.
I would expect that it would find by configuration the location on the local
MySQL server. But is seems not.
If you have comments on that, please advise.
Thanks in advance.
Cordialement.
Patrick GINHOUX
Unisys | +33 1 46 69 52 12 | +33 6 60 32 24 74 | patrick.ginhoux(a)unisys.com
De : sr-users <sr-users-bounces(a)lists.kamailio.org> De la part de Ginhoux,
Patrick
Envoyé : mardi 7 août 2018 16:50
À : Henning Westerholt <hw(a)kamailio.org>
Cc : Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Objet : Re: [SR-Users] kamcmd htable.reload propertiesHash problem
Hi Henning,
Some update on my upgrade to kamailio 5.0.7.
First of all, I posted other question related to the mod_perl requirement,
etc... and I got some interesting answers.
I succeeded to get rid of the dependencies and now my server is upgraded to
5.0.7. Unfortunately, Kamailio doesn't start and is in a kind of loop.
The kamailio.log contains entries I've never seen before with 5.0.1. Extract
of the log :
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/cfg.y:1623]:
yyparse(): loading module app_perl.so
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/sr_module.c:575]: load_module(): trying to load
</usr/lib64/kamailio/modules/app_perl.so>
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/sr_module.c:624]: load_module(): attempt to lookup exports structure
failed - dlerror: /usr/lib64/kamailio/modules/app_perl.so: undefined symbol:
exports
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/sr_module.c:636]: load_module(): looking up exports with name:
_app_perl_exports
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/sr_module.c:652]: load_module():
/usr/lib64/kamailio/modules/app_perl.so: exports dlflags interface is
deprecated and it will not be supported in newer versions; consider using
mod_register() instead
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/sr_module.c:624]: load_module(): attempt to lookup exports structure
failed - dlerror: /usr/lib64/kamailio/modules/app_perl.so: undefined symbol:
exports
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/sr_module.c:636]: load_module(): looking up exports with name:
_app_perl_exports
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/cfg.lex:1713]:
pp_define(): defining id: MOD_app_perl
.
.
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/cfg.lex:1713]:
pp_define(): defining id: NODETYPE_MGCF
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/cfg.lex:1803]:
pp_define_set(): ### setting define ID [NODETYPE_MGCF] value [1]
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/cfg.lex:1713]:
pp_define(): defining id: NODETYPE_MMM
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/cfg.lex:1803]:
pp_define_set(): ### setting define ID [NODETYPE_MMM] value [2]
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/cfg.lex:1713]:
pp_define(): defining id: MGCF_NODESTRING
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/cfg.lex:1803]:
pp_define_set(): ### setting define ID [MGCF_NODESTRING] value ["MGCF"]
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/modparam.c:83]:
set_mod_param_regex(): 'app_perl' matches module 'app_perl'
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/sr_module.c:794]: find_param_export(): found <modpath> in module
app_perl [/usr/lib64/kamailio/modules/app_perl.so]
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/modparam.c:99]:
set_mod_param_regex(): found <modpath> in module app_perl
[/usr/lib64/kamailio/modules/app_perl.so]
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/modparam.c:83]:
set_mod_param_regex(): 'app_perl' matches module 'app_perl'
Aug 7 10:02:09 vm-siprouter74 kamailio: WARNING: <core> [core/cfg.y:3388]:
warn_at(): warning in config file /etc/kamailio/kamailio.cfg, line 978,
column 6-13: constant value in if(...)
Then lot of [core/route_struct.c:nnnn] entries, I have never seen before
with kamailio 5.0.1 :
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:467]: print_action(): f_ptr<0x7f65e4973bd0>
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:493]: print_action(): , 2
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:524]: print_action(): , "L_WARN"
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:546]: print_action(): );
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:545]: print_action(): };
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:519]: print_action(): } else {
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:545]: print_action(): };
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:442]: print_action(): assign(
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:483]: print_action(): type<21>
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:517]: print_action(): , type<22>
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:546]: print_action(): );
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:401]: print_action(): if (
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:483]: print_action(): type<22>
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:485]: print_action(): ) {
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:442]: print_action(): assign(
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:483]: print_action(): type<21>
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:517]: print_action(): , type<22>
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:546]: print_action(): );
This sequence of [core/route_struct.c:nnnn] entries ends with :
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:467]: print_action(): f_ptr<0x7f65e4973bd0>
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:493]: print_action(): , 2
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:524]: print_action(): , "L_DBG"
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:546]: print_action(): );
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/route.c:2134]:
print_rl():
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/route.c:129]:
route_add(): mapping routing block (0xaff280)[core:receive-parse-error] to 5
Aug 7 10:02:09 vm-siprouter74 kamailio: INFO: <core> [core/sctp_core.c:75]:
sctp_core_check_support(): SCTP API not enabled - if you want to use it,
load sctp module
Aug 7 10:02:09 vm-siprouter74 kamailio: WARNING: <core>
[core/socket_info.c:1314]: fix_hostname(): could not rev. resolve
129.227.83.78
Aug 7 10:02:09 vm-siprouter74 kamailio: WARNING: <core>
[core/socket_info.c:1314]: fix_hostname(): could not rev. resolve
129.227.82.79
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/mem/pkg.c:100]:
pkg_print_manager(): pkg - using memory manager: q_malloc
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/mem/shm.c:277]:
shm_print_manager(): shm - using memory manager: q_malloc
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/cfg/cfg.c:176]:
cfg_declare(): DEBUG: register_cfg_def(): new config group has been
registered: 'core' (num=52, size=208)
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/cfg/cfg.c:176]:
cfg_declare(): DEBUG: register_cfg_def(): new config group has been
registered: 'tcp' (num=26, size=104)
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/timer.c:256]:
init_timer(): starting with *ticks=1478539463
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/timer.c:298]:
init_timer(): timer_list between 0x7f65d9accfd0 and 0x7f65d9b10fd0
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core> [core/pt.c:145]:
register_procs(): registering new processes: 0 (old) + 1 (new) = 1 (total)
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/daemonize.c:207]: enable_dumpable(): trying enable core dumping...
Aug 7 10:02:09 vm-siprouter74 kamailio: DEBUG: <core>
[core/daemonize.c:225]: enable_dumpable(): core dumping is enabled now
(1)...
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: <core>
[core/daemonize.c:583]: set_core_dump(): core dump limits set to
18446744073709551615
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: <core>
[core/async_task.c:108]: async_task_init(): start initializing asynk task
framework
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: <core>
[core/sr_module.c:971]: init_mod(): db_mysql
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: db_mysql
[km_db_mysql.c:86]: kam_mysql_mod_init(): MySQL client version is
10.1.30-MariaDB
Then the jsonrpcs mod-init fails to change the owner/group for the
/var/run/kamailio/kamailio_rpc_fifo :
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: <core>
[core/sr_module.c:971]: init_mod(): jsonrpcs
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: jsonrpcs
[jsonrpcs_mod.c:1087]: mod_init(): preparing to listen on fifo file:
/var/run/kamailio/kamailio_rpc_fifo
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: jsonrpcs
[jsonrpcs_fifo.c:151]: jsonrpc_init_fifo_file(): testing if fifo file exists
...
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: jsonrpcs
[jsonrpcs_fifo.c:72]: jsonrpc_init_fifo_server(): FIFO created @
/var/run/kamailio/kamailio_rpc_fifo
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: ERROR: jsonrpcs
[jsonrpcs_fifo.c:82]: jsonrpc_init_fifo_server(): Failed to change the
owner/group for /var/run/kamailio/kamailio_rpc_fifo to 248.248; Operation
not permitted[1]
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: CRITICAL: jsonrpcs
[jsonrpcs_fifo.c:209]: jsonrpc_init_fifo_file(): failed to init jsonrpc fifo
server file stream
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: ERROR: jsonrpcs
[jsonrpcs_fifo.c:539]: jsonrpc_fifo_mod_init(): cannot initialize fifo
transport
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: ERROR: jsonrpcs
[jsonrpcs_mod.c:1090]: mod_init(): cannot initialize fifo transport
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: ERROR: jsonrpcs
[jsonrpcs_fifo.c:539]: jsonrpc_fifo_mod_init(): cannot initialize fifo
transport
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: ERROR: jsonrpcs
[jsonrpcs_mod.c:1090]: mod_init(): cannot initialize fifo transport
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: ERROR: <core>
[core/sr_module.c:974]: init_mod(): Error while initializing module jsonrpcs
(/usr/lib64/kamailio/modules/jsonrpcs.so)
Then the connection to my MySQL server fails also:
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: <core>
[core/sr_module.c:698]: find_mod_export_record(): find_export_record: found
<db_bind_api> in module db_mysql [/usr/lib64/kamailio/modules/db_mysql.so]
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: <core>
[db.c:209]: db_bind_mod(): using db bind api for db_mysql
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: <core>
[db.c:314]: db_do_init2(): connection 0x7f65e4974868 not found in pool
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: db_mysql
[km_my_con.c:98]: db_mysql_new_connection(): opening connection:
mysql://xxxx:xxxx@localhost/siprouter
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: ERROR: db_mysql
[km_my_con.c:129]: db_mysql_new_connection(): driver error: Can't connect to
local MySQL server through socket '/var/lib/mysql/mysql.sock' (2 "No such
file or directory")
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: ERROR: <core>
[db.c:318]: db_do_init2(): could not add connection to the pool
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: ERROR: htable
[ht_db.c:92]: ht_db_open_con(): failed to connect to the database
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: tm
[t_funcs.c:86]: tm_shutdown(): DEBUG: tm_shutdown : start
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: tm
[t_funcs.c:89]: tm_shutdown(): DEBUG: tm_shutdown : emptying hash table
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: tm
[t_funcs.c:91]: tm_shutdown(): DEBUG: tm_shutdown : removing semaphores
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: tm
[t_funcs.c:93]: tm_shutdown(): DEBUG: tm_shutdown : destroying tmcb lists
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: tm
[t_funcs.c:96]: tm_shutdown(): DEBUG: tm_shutdown : done
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: INFO: <core>
[core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: <core>
[core/mem/shm.c:174]: shm_core_lock_destroy(): destroying the shared memory
lock
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: <core>
[core/mem/shm.c:266]: shm_destroy_manager(): destroying memory manager:
q_malloc
Aug 7 10:02:09 vm-siprouter74 /usr/sbin/kamailio[20218]: DEBUG: <core>
[core/mem/pkg.c:89]: pkg_destroy_manager(): destroying memory manager:
q_malloc
Hereafter I can see that kamailio is looping :
Aug 7 10:02:09 vm-siprouter74 kamailio: WARNING: <core> [core/cfg.y:3388]:
warn_at(): warning in config file /etc/kamailio/kamailio.cfg, line 978,
column 6-13: constant value in if(...)
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:546]: print_action(): );
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:448]: print_action(): UNKNOWN(
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:483]: print_action(): type<22>
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:442]: print_action(): assign(
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:483]: print_action(): type<21>
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:517]: print_action(): , type<22>
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:546]: print_action(): );
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:442]: print_action(): assign(
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:483]: print_action(): type<21>
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:517]: print_action(): , type<22>
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:546]: print_action(): );
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:401]: print_action(): if (
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:483]: print_action(): type<22>
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:485]: print_action(): ) {
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:418]: print_action(): external_module_call(
Aug 7 10:02:10 vm-siprouter74 kamailio: DEBUG: <core>
[core/route_struct.c:467]: print_action(): f_ptr<0x7f34c32babd0>
Ive been told that the upgrade from 5.0.1 to 5.0.7 would be simple, but it
is not.
At the moment, I dont know how to fix the different errors above.
So if you or somebody else can help me, that would be good.
Cordialement.
Patrick GINHOUX
-----Message d'origine-----
De : sr-users <sr-users-bounces(a)lists.kamailio.org
<mailto:sr-users-bounces@lists.kamailio.org> > De la part de Ginhoux,
Patrick
Envoyé : samedi 4 août 2018 11:46
À : Henning Westerholt <hw(a)kamailio.org <mailto:hw@kamailio.org> >; Kamailio
(SER) - Users Mailing List <sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org> >
Objet : Re: [SR-Users] kamcmd htable.reload propertiesHash problem
Hi,
I'm thinking about the difficulty to upgrade my Kamailio server from the
5.0.1 level to the 5.0.7 level because of dependencies.
This difficulty comes from because the kamailio-perl-5.0.7-1.el7.x86_64.rpm
requires the mod_perl module (and this one no longer exists on a RHEL 7
distro).
My question then is what has been changed between the 5.0.1 and the 5.0.7
level to require the mod_perl module ?
As my server still run RHEL 7.4, why I don't not encounter the issue with
the 5.0.1 ?
Any thoughts on this analysis ?
Cordialement.
Patrick GINHOUX
Unisys | +33 1 46 69 52 12 | +33 6 60 32 24 74 |
<mailto:patrick.ginhoux@unisys.com> patrick.ginhoux(a)unisys.com
-----Message d'origine-----
De : sr-users < <mailto:sr-users-bounces@lists.kamailio.org>
sr-users-bounces(a)lists.kamailio.org> De la part de Ginhoux,
Patrick
Envoyé : vendredi 3 août 2018 09:30
À : Henning Westerholt < <mailto:hw@kamailio.org> hw(a)kamailio.org>
Cc : <mailto:sr-users@lists.kamailio.org> sr-users(a)lists.kamailio.org
Objet : Re: [SR-Users] kamcmd htable.reload propertiesHash problem
Unfortunately, I use the perl module in my kamailio.cfg.
So you're correct, I could install the mod_perl from the EPEL project. This
is possible on my test server in my lab.
At the moment, I had collected manually all rpm packages required for 5.0.1
(like Perl or snmp packages), that' was already a huge work.
Now if at each stream there is new dependencies, I would have to solve the
dependencies for other repo like with the EPEL repo.
But in a next step, I have to do the same installation on a customer site on
preimaged server with the following restrictions :
- from this site, I have no access to the internet (That's why, up to new, I
only download the packages I need)
- the preimaged server are RHEL 7.4 server without no required package
removed.
As said, I configured the EPEL repo on my test server and then try to
installed to mod_perl module. I starts ok but fails for other dependencies
(see attached).
So upgrading from Kamailio 5.0.1 to 5.0.7 is not as simple as I expected.
I hope I'm clear in my explanation.
Cordialement.
Patrick GINHOUX
Unisys | +33 1 46 69 52 12 | +33 6 60 32 24 74 |
<mailto:patrick.ginhoux@unisys.com> patrick.ginhoux(a)unisys.com
-----Message d'origine-----
De : Henning Westerholt < <mailto:hw@kamailio.org> hw(a)kamailio.org
Envoyé : vendredi 3 août 2018 08:43
À : Ginhoux, Patrick < <mailto:patrick.ginhoux@fr.unisys.com>
patrick.ginhoux(a)fr.unisys.com>
Cc : <mailto:sr-users@lists.kamailio.org> sr-users(a)lists.kamailio.org
Objet : Re: [SR-Users] kamcmd htable.reload propertiesHash problem
Am Freitag, 3. August 2018, 07:56:28 CEST schrieb Ginhoux, Patrick:
Instead of installing a new server, I tried to upgrade
the one running the
5.0.1 level. It has the following packages installed:
kamailio-perl-5.0.1-1.1.x86_64
kamailio-5.0.1-1.1.x86_64
kamailio-mysql-5.0.1-1.1.x86_64
kamailio-snmpstats-5.0.1-1.1.x86_64
So I have download the 5.0.7 packages into a separate
folder:
kamailio-rpms_5.0.7
kamailio-5.0.7-1.el7.x86_64.rpm
kamailio-mysql-5.0.7-1.el7.x86_64.rpm
kamailio-perl-5.0.7-1.el7.x86_64.rpm
kamailio-snmpstats-5.0.7-1.el7.x86_64.rpm
kamailio-ims-5.0.7-1.el7.x86_64.rpm
The update command rpm -Uvh --force kamailio*
detects a dependency on
the
mod_perl package :
warning: kamailio-5.0.7-1.el7.x86_64.rpm: Header V3
DSA/SHA1 Signature,
key
ID 941fdbdd: NOKEY
error: Failed dependencies:
mod_perl is needed by
kamailio-perl-5.0.7-1.el7.x86_64
I try to find this mod_perl package but it does no
longer exist for RedHat
7. We can find multiple articles referencing this
change in RHEL.
It seems there is an alternative way to get this
module in a EPEL
repository
(
<https://huntingbears.nl/2013/12/17/no-mod_perl-in-rhel-7-and-centos-7/>
https://huntingbears.nl/2013/12/17/no-mod_perl-in-rhel-7-and-centos-7/).
It is to me a huge work to simply update my current
Kamailio to 5.0.7.
Does this mod_perl change makes sense to you ?
Have you an idea to get rid of this dependency?
Hello Patrick,
probably a stupid question, but do you actually use the perl module inside
your kamailio cfg? If not - I would suggest to just remove the 5.0.1 perl
module, and also not install it for 5.0.7.
If you need it - the quoted artice states that its actually not difficult to
install mod_perl from the EPEL repository. This looks quite ok: "EPEL is the
high-quality RPM collection for RHEL and CentOS linux, maintened by the
Fedora
project.".
Best regards,
Henning
--
Henning Westerholt
<https://skalatan.de/blog/> https://skalatan.de/blog/
10:30 p.m.
Am Donnerstag, 9. August 2018, 09:51:31 CEST schrieb Ginhoux, Patrick:
Some update since recent discussions about the changes
between 5.0.1 and
5.0.7 with Sergey Safarov :
Hello Patrick,
thank you for the update, and great that you figured out the issues.
- The mod_perl module had been introduced by mistake in the 5.0.7
stream so that new packages are now available (5.0.7-7) without this module,
packages I use to upgrade my server.
Yes, I saw the commit. Good that its now fixed. Some more comments below.
- Once the upgrade done to 5.0.7-7 level, I
reported 2 problems :
o An error reported by the jsonrpcs module : ERROR: jsonrpcs
[jsonrpcs_fifo.c:82]: jsonrpc_init_fifo_server(): Failed to change the
owner/group for /var/run/kamailio/kamailio_rpc_fifo to 248.248; Operation
not permitted[1]
ð It is fixed now by configuring the USER/GROUP parameters with the correct
values in the systemd unit file
o An error to open the MySQL: ERROR: db_mysql [km_my_con.c:129]:
db_mysql_new_connection(): driver error: Can't connect to local MySQL server
through socket '/var/lib/mysql/mysql.sock' (2 "No such file or
directory")
ð Initially on my Kamailio with 5.0.1, I had created these 2 symbolic links
to get the connection to the local MySQL server:
#Symbolic links for the MySQL to MariaDB change to allow kamailio to locate
the mysql libs and then open the siprouter database
ln -s /opt/mysql/na/10.2.14/lib64/libmysqlclient.so.18.0.0
/usr/lib64/libmysqlclient.so.18
ln -s /myqdata/mysiprdb/data/my.cnf /etc/my.cnf
This was good for kamailio to open the local MySQL server, but it failed to
reload a Hash table; the kamcmd htable.reload propertiesHash returns a
problem :
kamcmd htable.reload propertiesHash
error: 500 - Failed to open htable db connection
The kamailio.log reported that it can't connect the db :
DEBUG: <core> [core/sr_module.c:694]: find_mod_export_record():
find_export_record: found <db_bind_api> in module db_mysql
[/usr/lib64/kamailio/modules/db_mysql.so]
DEBUG: <core> [db.c:209]: db_bind_mod(): using db bind api for db_mysql
DEBUG: <core> [db.c:314]: db_do_init2(): connection 0x7f68cc354c10 not found
in pool
DEBUG: db_mysql [km_my_con.c:98]: db_mysql_new_connection(): opening
connection: mysql://xxxx:xxxx@/siprouter
ERROR: db_mysql [km_my_con.c:124]: db_mysql_new_connection(): driver error:
Can't connect to local MySQL server through socket
'/var/lib/mysql/mysql.sock' (2 "No such file or directory")
ð Now with my Kamailio upgraded with 5.0.7-7, it fails immediately at the
startup to connect the local MySQL server.
Interesting behavior, but as you said - good that its fails now immediately.
DEBUG: <core> [core/sr_module.c:698]:
find_mod_export_record():
find_export_record: found <db_bind_api> in module db_mysql
[/usr/lib64/kamailio/modules/db_mysql.so]
DEBUG: <core> [db.c:209]: db_bind_mod(): using db bind api for db_mysql
DEBUG: <core> [db.c:314]: db_do_init2(): connection 0x7f65e4974868 not found
in pool
DEBUG: db_mysql [km_my_con.c:98]: db_mysql_new_connection(): opening
connection: mysql://xxxx:xxxx@localhost/siprouter
ERROR: db_mysql [km_my_con.c:129]: db_mysql_new_connection(): driver error:
Can't connect to local MySQL server through socket
'/var/lib/mysql/mysql.sock' (2 "No such file or directory")
That is a strange behavior versus the one with kamailio 5.0.1, but it is
maybe better as it immediately fails.
In all the case, I had have to do the following the fix the issue :
mkdir /var/lib/mysql
ln -s /myqdata/mysiprdb/data/mysiprdb.sock /var/lib/mysql/mysql.sock
This new symbolic link would then replace the first I had created : ln -s
/myqdata/mysiprdb/data/my.cnf /etc/my.cnf.
If I can consider these problems as fixed, it lets me confused on the manner
the db_mysql module works.
I would expect that it would find by configuration the location on the local
MySQL server. But is seems not.
[..]
Do you have a [client] section in your my.cnf? It should indeed pick this up
then. (Have a look to the db_mysql README for an example). If you don't have
this, I think the mysql libraries then just look for the compiled default.
There are no module settings in db_mysql module to configure the socket
setting. It just call the mysql client library.
If your server runs now and the reload cmd also works fine, I think you should
be ready to go, the problem is fixed.
Best regards,
Henning
--
Henning Westerholt
https://skalatan.de/blog/
10 Aug
10 Aug
11:07 a.m.
Hi Henning,
I review the my.cnf file on my serve. I dont find the readme,
but by looking the doc
(https://www.kamailio.org/docs/modules/stable/modules/db_mysql.html#idp38664
564), it seems correct.
It is located at <<<< /myqdata/mysiprdb/data/my.cnf >>>.
It contains the following sections :
[client]
port=3306
socket=/myqdata/mysiprdb/data/mysiprdb.sock
[kamailio]
socket = /myqdata/mysiprdb/data/mysiprdb.sock
user = siprouter
password = Isgcomms1!
default-character-set = utf8
In my kamailio.cfg, I have :
modparam("htable", "db_url",
"mysql://siprouter:Isgcomms1!@localhost/siprouter")
So, I expected that there is no need to have symlinkg to locate the db.
Is there a config issue ?
Cordialement.
Patrick GINHOUX
Unisys | +33 1 46 69 52 12 | +33 6 60 32 24 74 | patrick.ginhoux(a)unisys.com
-----Message d'origine-----
De : Henning Westerholt <hw(a)kamailio.org
Envoyé : jeudi 9 août 2018 21:31
À : Ginhoux, Patrick <patrick.ginhoux(a)fr.unisys.com>
Cc : Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Objet : Re: [SR-Users] kamcmd htable.reload propertiesHash problem
Am Donnerstag, 9. August 2018, 09:51:31 CEST schrieb Ginhoux, Patrick:
Some update since recent discussions about the changes
between 5.0.1 and
5.0.7 with Sergey Safarov :
Hello Patrick,
thank you for the update, and great that you figured out the issues.
- The mod_perl module had been introduced by
mistake in the 5.0.7
stream so that new packages are now available
(5.0.7-7) without this
module,
packages I use to upgrade my server.
Yes, I saw the commit. Good that its now fixed. Some more comments below.
- Once the upgrade done to 5.0.7-7 level, I
reported 2 problems :
o An error reported by the jsonrpcs module : ERROR:
jsonrpcs
[jsonrpcs_fifo.c:82]: jsonrpc_init_fifo_server():
Failed to change the
owner/group for /var/run/kamailio/kamailio_rpc_fifo
to 248.248; Operation
not permitted[1]
ð It is fixed now by configuring the USER/GROUP
parameters with the
correct
values in the systemd unit file
o An error to open the MySQL: ERROR: db_mysql
[km_my_con.c:129]:
db_mysql_new_connection(): driver error: Can't
connect to local MySQL
server
through socket '/var/lib/mysql/mysql.sock' (2
"No such file or directory")
ð Initially on my Kamailio with 5.0.1, I had created
these 2 symbolic
links
to get the connection to the local MySQL server:
#Symbolic links for the MySQL to MariaDB change to
allow kamailio to
locate
the mysql libs and then open the siprouter database
ln -s
/opt/mysql/na/10.2.14/lib64/libmysqlclient.so.18.0.0
/usr/lib64/libmysqlclient.so.18
ln -s /myqdata/mysiprdb/data/my.cnf /etc/my.cnf
This was good for kamailio to open the local MySQL
server, but it failed
to
reload a Hash table; the kamcmd htable.reload
propertiesHash returns a
problem :
kamcmd htable.reload propertiesHash
error: 500 - Failed to open htable db connection
The kamailio.log reported that it can't connect
the db :
DEBUG: <core> [core/sr_module.c:694]:
find_mod_export_record():
find_export_record: found <db_bind_api> in
module db_mysql
[/usr/lib64/kamailio/modules/db_mysql.so]
DEBUG: <core> [db.c:209]: db_bind_mod(): using
db bind api for db_mysql
DEBUG: <core> [db.c:314]: db_do_init2():
connection 0x7f68cc354c10 not
found
in pool
DEBUG: db_mysql [km_my_con.c:98]:
db_mysql_new_connection(): opening
connection: mysql://xxxx:xxxx@/siprouter
ERROR: db_mysql [km_my_con.c:124]:
db_mysql_new_connection(): driver
error:
Can't connect to local MySQL server through socket
'/var/lib/mysql/mysql.sock' (2 "No such
file or directory")
ð Now with my Kamailio upgraded with 5.0.7-7, it
fails immediately at the
startup to connect the local MySQL server.
Interesting behavior, but as you said - good that its fails now immediately.
DEBUG: <core> [core/sr_module.c:698]:
find_mod_export_record():
find_export_record: found <db_bind_api> in
module db_mysql
[/usr/lib64/kamailio/modules/db_mysql.so]
DEBUG: <core> [db.c:209]: db_bind_mod(): using
db bind api for db_mysql
DEBUG: <core> [db.c:314]: db_do_init2():
connection 0x7f65e4974868 not
found
in pool
DEBUG: db_mysql [km_my_con.c:98]:
db_mysql_new_connection(): opening
connection: mysql://xxxx:xxxx@localhost/siprouter
ERROR: db_mysql [km_my_con.c:129]:
db_mysql_new_connection(): driver
error:
Can't connect to local MySQL server through socket
'/var/lib/mysql/mysql.sock' (2 "No such
file or directory")
That is a strange behavior versus the one with
kamailio 5.0.1, but it is
maybe better as it immediately fails.
In all the case, I had have to do the following the
fix the issue :
mkdir /var/lib/mysql
ln -s /myqdata/mysiprdb/data/mysiprdb.sock
/var/lib/mysql/mysql.sock
This new symbolic link would then replace the first I
had created : ln -s
/myqdata/mysiprdb/data/my.cnf /etc/my.cnf.
If I can consider these problems as fixed, it lets me
confused on the
manner
the db_mysql module works.
I would expect that it would find by configuration the
location on the
local
MySQL server. But is seems not.
[..]
Do you have a [client] section in your my.cnf? It should indeed pick this up
then. (Have a look to the db_mysql README for an example). If you don't have
this, I think the mysql libraries then just look for the compiled default.
There are no module settings in db_mysql module to configure the socket
setting. It just call the mysql client library.
If your server runs now and the reload cmd also works fine, I think you
should
be ready to go, the problem is fixed.
Best regards,
Henning
--
Henning Westerholt
<https://skalatan.de/blog/> https://skalatan.de/blog/
2302
days inactive
2319
days old
12 comments
2 participants
participants (2)
-
Ginhoux, Patrick -
Henning Westerholt