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