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.com117(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:9181originated 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:9181117(355) INFO: 2022-04-28T18:08:14.473375226Z 5f2567bf-25bb-4cb1-a306-dc28711d9fcb default.cfg:305 (log_request) to
sip:1117@1.sip-stress.com117(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
should be
Any hints/thoughts ?
should we try to have a better way to handle this inb dprint.c/dprint.h ?