[systemd-devel] Linux Journal API/client lib

[Kay Sievers]

On Fri, Dec 2, 2011 at 19:07, Rainer Gerhards <rgerhards at gmail.com> wrote:
> On Fri, Dec 2, 2011 at 6:59 PM, Kay Sievers <kay.sievers at vrfy.org> wrote:
>> On Fri, Dec 2, 2011 at 17:02, Rainer Gerhards <rgerhards at gmail.com> wrote:

>> Well, if syslogd, or any other consumer, is interested in the
>> metadata, it should not rely in /dev/log. /dev/log will probably stay
>> what it is which is mostly plain old syslog with a header and a
>> timestamp and the human readable string. All stuff that wants the
>> metadata should use the proper API and get the records from there. The
>> '/dev/log proxy' is just to ensure full syslogd compatibility, not to
>> provide any new data which do not really fit into the plaintext file
>> format.
>
> Why are you making it deliberately hard to interoperate?

Making what hard? Interoperate? What do you mean? Syslog can very
easily be a consumer of the journal data, if it's interested in it.

> If you
> already supply the event you gather via the log socket, why not
> provide the complete set of information (probably as an opt-in
> feature)? That way the syslogd would not need a specific input
> capability (input module in rsyslog terms) to capture the log data.
> Things could just remain as is.

You mean the native log messages only or all messages, including the
ones journald retrieves from /dev/log?

> What you call the "plaintext file
> format" issue is being solved anyhow in the meantime. Look at RFC5424
> or CEE. So how to encode the fields is actually not a question at all.
> If you provide proper formatting, the syslogd would not even need to
> be aware of what's going on... (at least for CEE, rsyslog also has a
> parser for structured data in legacy syslog, but that's non-standard).

The journal is not meant to replace syslog, if syslog is needed, nor
to act as a proxy to enrich /dev/log messages. We need to change as
little as possible, and that includes keeping the same format on the
output (the fd handed to syslog) as we get at the input side
(/dev/log).

If one day glibc changes or there is another generally useful new
syslog client API, we can do alll that, but as of now, I'm convinced
that the journal should just make it easy to get all the information
out, but it should not try to add stuff to established interfaces, and
it should not natively speak any syslog enhanced format. That stays as
the job for syslog.

Kay