----- Original Message -----
Given systemd's fast adoption across a wide range of Linux distros, in particular the enterprise distros from Red Hat & SUSE, we're going to have journald support in places where structured logging really matters, likely expanding to all Linux distros in a reasonably short period. As such I don't really have a desire to also support Lumberjack format in libvirt natively. IMHO, system services should just log to journald and either journald can forward plain messages to syslog, or a tool can be created which pulls structured log data out of the journal and formats it in Lumberjack format.
I can live with that; however the libvirt use case I am looking at does require adding more metadata fields, and I can't see how doing that without memory allocation or imposing arbitrary limits is possible. Imposing arbitrary limits it is, I guess.
Re: async-signal-safe use: Yes, using a JSON library is more convenien and generally preferred to writing a yet another JSON encoder, and yes, a typical JSON library will not be async-signal-safe. However, applications are not required to use all JSON facilities. An application that wants to log a static string between fork() and execve() can just as easily log a static JSON string.
I don't really see logging preformatted static JSON strings as a satisfactory approach, especially when compared to the way you can use journald.
That is either write 150 lines of code, or rely on libsystemd-journal code that was not promised to be async-signal-safe?
Regarding libvirt specifically, virLogVMessage is rather far from async-signal-safe (e.g. virVasprintf(), virLogLock()), so this doesn't seem to be a concern for libvirt.
It actually *is* very much a concern for libvirt.
OK. Mirek