[SR-Users] TLS module not initialized in 4.3.3, worked in 4.1.5
Daniel-Constantin Mierla
miconda at gmail.com
Mon Nov 16 09:34:31 CET 2015
Hello,
the following log message:
Nov 13 17:29:37 lasola /usr/sbin/kamailio[3536]: DEBUG: <core>
[mem/shm_mem.c:235]: shm_mem_destroy(): destroying the shared memory lock
indicates that Kamailio is shutting down already. Can you check up in
the logs and see if there are other error messages?
Do you have /var/log/kamailio folder with appropriate permissions so
kamailio can create fifo file/etc.?
Cheers,
Daniel
On 13/11/15 18:07, Sebastian Damm wrote:
> Hi Daniel,
>
> I just moved the TLS config lines up top even before sl and tm module.
> Also moved the modparam stuff up there. When starting, Kamailio says,
> it is listening on a TLS socket, but netstat says, it isn't. It's
> basically the same behavior as before. (This is the last log line from
> shutting down and the very first lines when starting up.)
>
> Nov 13 17:29:37 lasola /usr/sbin/kamailio[3536]: DEBUG: <core>
> [mem/shm_mem.c:235]: shm_mem_destroy(): destroying the shared memory lock
> Nov 13 17:29:42 lasola /usr/sbin/kamailio[3704]: DEBUG: <core>
> [daemonize.c:583]: set_core_dump(): core dump limits set to
> 18446744073709551615
> Nov 13 17:29:42 lasola /usr/sbin/kamailio[3704]: WARNING: <core>
> [main.c:2475]: main(): tls support enabled, but no tls engine
> available (forgot to load the tls module?)
> Nov 13 17:29:42 lasola /usr/sbin/kamailio[3704]: WARNING: <core>
> [main.c:2476]: main(): disabling tls...
> Nov 13 17:29:42 lasola /usr/sbin/kamailio[3704]: DEBUG: <core>
> [async_task.c:88]: async_task_init(): start initializing asynk task
> framework
> Nov 13 17:29:42 lasola /usr/sbin/kamailio[3704]: DEBUG: <core>
> [sr_module.c:959]: init_mod(): tls
> Nov 13 17:29:42 lasola /usr/sbin/kamailio[3704]: WARNING: tls
> [tls_mod.c:287]: mod_init(): tls support is disabled (set enable_tls=1
> in the config to enable it)
>
> I tried finding out, when those messages are written to the log. The
> first one with "no engine available" comes from main.c, if it wants to
> initialize tls but the module is not loaded yet. But it comes only, if
> tls_disable is not set. So at this point, Kamailio knows that we want
> to use TLS. But when this message appears, Kamailio sets tls_disable
> to 1. The second message "tls support is disabled" comes from the tls
> module, and only when tls_disable is set. So that's quite logical,
> because it was set this way before.
>
> I compared the startup behavior between 4.1.3 and 4.3.3, and in 4.1.3
> we had it pretty late in the init section, so there were a lot of
> modules loaded before tls and it worked without a problem.
>
> I'm too bad in reading code, so I don't know what I have to do to get
> this message go away. The part of the code, where this is printed,
> changed a bit, but the conditions for printing the message stayed the
> same. I'm out of ideas what to check anymore.
>
> Best Regards,
> Sebastian
>
> On Fri, Nov 13, 2015 at 2:29 PM, Daniel-Constantin Mierla
> <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>
> Hello,
>
> it could be related to the fact that a lot of internal things are
> initialized when the first modparam is found in config, but I
> thought that change was done in 3.x.
>
> Can you put the tls module config part being the first? The other
> modules don't need to be initialized before, actually tls needs to
> be initialized and it does some of its init stuff when it is
> loaded (unlike the common to do init stuff in mod init).
>
> Cheers,
> Daniel
>
>
> On 13/11/15 14:16, Sebastian Damm wrote:
>> Hi Daniel,
>>
>> yes, we see this message.
>>
>> Nov 13 11:44:42 lasola /usr/sbin/kamailio[16113]: DEBUG: <core>
>> [sr_module.c:959]: init_mod(): tls
>> Nov 13 11:44:42 lasola /usr/sbin/kamailio[16113]: WARNING: tls
>> [tls_mod.c:287]: mod_init(): tls support is disabled (set
>> enable_tls=1 in the config to enable it)
>> Nov 13 11:44:42 lasola /usr/sbin/kamailio[16113]: DEBUG: <core>
>> [main.c:2520]: main(): Expect (at least) 30 kamailio processes in
>> your process list
>>
>> Okay, then the message right at the beginning probably just
>> irritated us. But as you can see, we have set enable_tls=1
>> (previously and in the documentation it was set to 'yes'), but it
>> still doesn't get enabled.
>>
>> Any more ideas?
>>
>> Best Regards,
>> Sebastian
>>
>> On Fri, Nov 13, 2015 at 12:32 PM, Daniel-Constantin Mierla
>> <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>>
>> Hello,
>>
>> if you start with debug=3, do you see the message:
>>
>> DEBUG: <core> [sr_module.c:959]: init_mod(): tls
>>
>> Cheers,
>> Daniel
>>
>>
>> On 13/11/15 12:17, Sebastian Damm wrote:
>>> Hello,
>>>
>>> we just updated one kamailio server from 4.1.5 to 4.3.3, and
>>> although the config file is correct and kamailio starts up,
>>> it doesn't initialize TLS and says " tls support enabled,
>>> but no tls engine available (forgot to load the tls module?)"
>>>
>>> In the log I see:
>>>
>>> Old shutdown (last lines):
>>> Nov 13 11:44:38 lasola /usr/sbin/kamailio[15890]: DEBUG:
>>> <core> [mem/shm_mem.c:235]: shm_mem_destroy(): destroying
>>> the shared memory lock
>>> Nov 13 11:44:41 lasola /usr/sbin/kamailio[14818]: ERROR:
>>> <core> [tcp_read.c:271]: tcp_read_data(): error reading:
>>> Connection reset by peer (104)
>>> Nov 13 11:44:41 lasola /usr/sbin/kamailio[14818]: ERROR:
>>> <core> [tcp_read.c:1296]: tcp_read_req(): ERROR:
>>> tcp_read_req: error reading
>>>
>>> New startup (first lines):
>>> Nov 13 11:44:42 lasola /usr/sbin/kamailio[16113]: DEBUG:
>>> <core> [daemonize.c:583]: set_core_dump(): core dump limits
>>> set to 18446744073709551615
>>> Nov 13 11:44:42 lasola /usr/sbin/kamailio[16113]: WARNING:
>>> <core> [main.c:2475]: main(): tls support enabled, but no
>>> tls engine available (forgot to load the tls module?)
>>> Nov 13 11:44:42 lasola /usr/sbin/kamailio[16113]: WARNING:
>>> <core> [main.c:2476]: main(): disabling tls...
>>> Nov 13 11:44:42 lasola /usr/sbin/kamailio[16113]: DEBUG:
>>> <core> [async_task.c:88]: async_task_init(): start
>>> initializing asynk task framework
>>> Nov 13 11:44:42 lasola /usr/sbin/kamailio[16113]: DEBUG:
>>> <core> [sr_module.c:959]: init_mod(): xmlrpc
>>> Nov 13 11:44:42 lasola /usr/sbin/kamailio[16113]: DEBUG:
>>> <core> [sr_module.c:689]: find_mod_export_record():
>>> find_export_record: found <bind_sl> in module sl
>>> [/usr/lib/x86_64-linux-gnu/kamailio/modules//sl.so]
>>> Nov 13 11:44:42 lasola /usr/sbin/kamailio[16113]: DEBUG:
>>> <core> [sr_module.c:959]: init_mod(): sl
>>>
>>> In our config file we have the following lines for TLS
>>> (pretty late, after all other module loading and after most
>>> parameters):
>>>
>>> #!ifdef ENABLETLS
>>> loadmodule "tls.so"
>>>
>>> modparam("tls", "private_key",
>>> "/etc/ssl/private/my.kamailio-key.pem")
>>> modparam("tls", "certificate", "/etc/ssl/certs/my.kamailio.crt")
>>> #!ifdef TLS_CA_CHAIN
>>> # Maybe we want to use a chain to the CA
>>> modparam("tls", "ca_list", "/etc/ssl/certs/my.ca-bundle.crt")
>>> #!endif
>>> enable_tls=1
>>> listen=tls:1.2.3.4:5061 <http://1.2.3.4:5061>
>>> #!endif
>>>
>>> After starting up, kamailio listens on port 5060, but not on
>>> port 5061. In version 4.1.1, this config worked without a
>>> problem.
>>>
>>> Has anybody seen this before? the tls module is there and
>>> available, it doesn't say anything about "cannot load
>>> module", and it is only a warning message. I'm also
>>> wondering, why this message is the first after starting the
>>> server. From config I would expect that sl, tm and all the
>>> other modules should be initialized before tls.
>>>
>>> Best Regards,
>>> Sebastian
>>>
>>>
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
Kamailio Advanced Training, Nov 30-Dec 2, Berlin - http://asipto.com/kat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20151116/0f145f58/attachment.html>
More information about the sr-users
mailing list