[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [libvirt] [PATCH 00/12] Structured syslog (Lumberjack/CEE) support
- From: Miloslav Trmac <mitr redhat com>
- To: "Daniel P. Berrange" <berrange redhat com>
- Cc: libvir-list redhat com
- Subject: Re: [libvirt] [PATCH 00/12] Structured syslog (Lumberjack/CEE) support
- Date: Tue, 9 Oct 2012 06:53:36 -0400 (EDT)
----- 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
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]