----- 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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list