Re: [libvirt] [PATCH 00/12] Structured syslog (Lumberjack/CEE) support
----- 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