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@10.21.0.1 default.cfg:304 (log_request) 116(354) INFO: 2022-04-28T18:08:14.521506921Z cid-10440-26@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@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@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