6 May
2022
6 May
'22
1:11 p.m.
Hello,
(sending again with proper subject)
seeing some weirdness in kamailio logs while testing kamailio under
docker/kubernetes and logging to stderr, not sure if its related to
kamailio or the infrastructure itself.
running in 8 core host, it looks like the write to stderr has some race
condition if that's even possible.
the breaks happen with different processes and i wonder if the LOG_FX and
DPRINT_NON_CRIT macros are responsible for that.
it looks like 2 different processes could evaluate to true and try to write
to stderr at same time.
two examples
real output
116(354) INFO: 2022-04-28T18:08:14.476102048Z
3ebe6ff3-1799-4798-baa3-a109df32711d registrar-role.cfg:745
(route_to_external_aor) 117(355) INFO: 2022-04-28T18:08:14.473375226Z
5f2567bf-25bb-4cb1-a306-dc28711d9fcb default.cfg:305 (log_request) to
sip:1117@1.sip-stress.com
117(355) INFO: 2022-04-28T18:08:14.476592352Z
5f2567bf-25bb-4cb1-a306-dc28711d9fcb default.cfg:324 (classify_source) end
- routing to contact sip:1104@10.23.0.2:9181
originated from internal sources
should be
116(354) INFO: 2022-04-28T18:08:14.476102048Z
3ebe6ff3-1799-4798-baa3-a109df32711d registrar-role.cfg:745
(route_to_external_aor) end - routing to contact sip:1104@10.23.0.2:9181
117(355) INFO: 2022-04-28T18:08:14.473375226Z
5f2567bf-25bb-4cb1-a306-dc28711d9fcb default.cfg:305 (log_request) to
sip:1117@1.sip-stress.com
117(355) INFO: 2022-04-28T18:08:14.476592352Z
5f2567bf-25bb-4cb1-a306-dc28711d9fcb default.cfg:324
(classify_source) originated from internal sources
second example
real output
71(309) INFO: 2022-04-28T18:08:14.514892167Z cid-10440-3(a)10.21.0.1
default.cfg:304 (log_request) 116(354) INFO: 2022-04-28T18:08:14.521506921Z
cid-10440-26(a)10.21.0.1 default.cfg:751 (internal_reply) 200 OK
from sip:1002@1.sip-stress.com
should be
71(309) INFO: 2022-04-28T18:08:14.514892167Z cid-10440-3(a)10.21.0.1
default.cfg:304 (log_request) from sip:1002@1.sip-stress.com
116(354) INFO: 2022-04-28T18:08:14.521506921Z cid-10440-26(a)10.21.0.1
default.cfg:751 (internal_reply) 200 OK
Any hints/thoughts ?
should we try to have a better way to handle this inb dprint.c/dprint.h ?
Thanks