Hi @miconda ,
thanks for your feedback!
Regarding ksr_logdata_t
, most likely it got flagged by some static checker, but we've re-tested the original version and couldn't pin-point which exact check/rule triggered this.
Regarding the asprintf
- thanks for spotting the memory leak! We've never detected it using our memory checkers since we never actually use the default stub continuously - it always gets replaces when our custom module is initialised.
Then, when this new mechanism is used and what is the benefit? Can you provide some examples?
The benefits of being able to control the output format of the logs are mainly evident when Kamailio is used in a deployment alongside other products/tools, all of which are generating their logs using a common scheme. Thus, being able to control Kamailio log output scheme helps to:
Here's a sample output made possible with the help of this patch:
(scheme used: <pname> <ver> <timestamp> <lvl> <mname> <pid>:<file>:<line> <msg>
)
pname 1.35.15 2024-06-20T10:43:24.134886Z WARNING pname 13:libpname/core.cpp:85 Core successfully created!
pname 1.35.15 2024-06-20T10:43:24.135058Z INFO tls 13:tls_mod.c:445 use OpenSSL version: 30000070
pname 1.35.15 2024-06-20T10:43:24.135079Z INFO tls 13:tls_mod.c:447 With ECDH-Support!
pname 1.35.15 2024-06-20T10:43:24.135096Z INFO tls 13:tls_mod.c:450 With Diffie Hellman
pname 1.35.15 2024-06-20T10:43:24.135166Z WARNING tls 13:tls_init.c:980 openssl bug #1491 (crash/mem leaks on low memory) workaround enabled (on low memory tls operations will fail preemptively) with free memory thresholds 11534336 and 5767168 bytes
pname 1.35.15 2024-06-20T10:43:24.135203Z INFO core 13:core/cfg/cfg_ctx.c:589 tls.low_mem_threshold1 has been changed to 11534336
pname 1.35.15 2024-06-20T10:43:24.135223Z INFO core 13:core/cfg/cfg_ctx.c:589 tls.low_mem_threshold2 has been changed to 5767168
...
pname 1.35.15 2024-06-20T10:43:24.136142Z INFO tls 13:tls_mod.c:491 Loading SSL_CTX in process_no=0 rank=-127 ksr_tls_threads_mode=0
pname 1.35.15 2024-06-20T10:43:24.136176Z INFO tls 13:tls_domain.c:353 TLSs<default>: tls_method=23
pname 1.35.15 2024-06-20T10:43:24.136200Z INFO tls 13:tls_domain.c:365 TLSs<default>: certificate='/usr/local/lib/pname/certs/serv.crt'
...
pname 1.35.15 2024-06-20T10:43:33.612026Z TRACE pname 16:libpname/log/trace_object.hpp:19 Create > binding::SipMsg()
pname 1.35.15 2024-06-20T10:43:33.612093Z TRACE pname 16:libpname/binding/sip_msg.cpp:645 Call > binding::SipMsg::getCallId()
pname 1.35.15 2024-06-20T10:43:33.612136Z TRACE pname 16:libpname/log/logger.cpp:100 Call > zroute::Logger::setTraceId("3811ef5eb36d7024f1f3e7bfaf70e572")
pname 1.35.15 2024-06-20T10:43:33.612194Z INFO pname 16:/usr/local/etc/pname/./route.cfg:11 TraceID[3811ef5eb36d7024f1f3e7bfaf70e572] Processing "INVITE" request received from "sip:10.22.10.9:5060" [Call-Id: "8t1b49///1-94@10.22.10.9"]
pname 1.35.15 2024-06-20T10:43:33.612218Z INFO debugger 16:debugger_api.c:351 TraceID[3811ef5eb36d7024f1f3e7bfaf70e572] request_route=[DEFAULT_ROUTE] c=[/usr/local/etc/pname/./route.cfg] l=12 a=25 n=MYLOG_DBG
pname 1.35.15 2024-06-20T10:43:33.612244Z TRACE pname 16:libpname/log/logger.cpp:110 TraceID[3811ef5eb36d7024f1f3e7bfaf70e572] Call > zroute::Logger::isTraceIdSet()
pname 1.35.15 2024-06-20T10:43:33.613788Z DEBUG pname 16:/usr/local/etc/pname/././invite.cfg:2 TraceID[3811ef5eb36d7024f1f3e7bfaf70e572] Received INVITE request, routing
pname 1.35.15 2024-06-20T10:43:33.612266Z DEBUG pname 16:/usr/local/etc/pname/./route.cfg:12 TraceID[3811ef5eb36d7024f1f3e7bfaf70e572] INVITE sip:test@example.com SIP/2.0
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.