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