Re: [libvirt] [PATCH 00/12] Structured syslog (Lumberjack/CEE) support

[Miloslav Trmac <mitr redhat com>]

----- 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