Logging code, async signal safety, and syslog CEE

[Mike Pontillo]

I was recently looking at an old (rejected) patch to add syslog CEE
support[1], and a related ticket asking to rewrite the syslog logger to be
async signal safe[2]. I'm hoping someone can help me understand the
potential issues here, because I would like to work on adding syslog CCE
support, and it seems like I should proceed with caution.

According to issue #5, the syslog() function is unsafe due to the
underlying use of sprintf(). However, in the logging code itself,
g_strdup_vprintf() is called prior to the callouts to the defined log
outputs. Is this call considered safe? What about other calls to GLib that
occur within the output routines, such as the call to g_mkstemp_full()?

Is there a test case I can execute to gain confidence that any new logging
code I add will be async signal safe? Are there existing, known calls to
the logger that can occur within a signal handler (or other circumstance
that requires async signal safety)?

The approach I was thinking of could build upon what was done for journald
support, in that it could make use of the "meta" struct to define
additional keys for the JSON message. I think the only complexity is the
need to build up a new string. I don't think there is any need to support a
"hierarchy"; building up a flat JSON dictionary should be all that is
needed. So, if it is undesirable to call out to a JSON library (this was
considered problematic in the original patch),  the strings to be
logged could be escaped and concatenated into a dictionary, and then sent
up in the same way as existing syslog messages.

NB: I also noticed that the journald structured logging fields tend to be
all uppercase. I feel like it might also be good to convert the keys to
lowercase, for consistency with the other CEE logs I have seen.

Would a contribution like this be welcome in libvirt? I would appreciate
any thoughts.

Thanks,
Mike

[1]:
https://listman.redhat.com/archives/libvir-list/2012-September/064560.html
[2]: https://gitlab.com/libvirt/libvirt/-/issues/5
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20220526/0efbe05e/attachment.htm>