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 > <mico...@gmail.com <mailto:mico...@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 >> <mico...@gmail.com <mailto:mico...@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@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
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
