[systemd-devel] Linux Journal API/client lib

[Kay Sievers]

On Sat, Dec 3, 2011 at 15:23, Rainer Gerhards <rgerhards at gmail.com> wrote:
> On Sat, Dec 3, 2011 at 12:54 PM, Kay Sievers <kay.sievers at vrfy.org> wrote:
>> Well, that's not making it hard to access information, it's trying
>> hard not to break established interfaces. If syslog *could* be
>> extended in a reasonable way, we wouldn't need a journal interface at
>> all. Adding any information might break tools, so we can only offer
>> the extended stuff in a new interface.
>
> I think this boils down to the fundamental difference in our view on
> syslog, so I guess it does not make much sense to argue here in this
> context. But Ifind it interesting to hear that you postulate that
> syslog logging is absolutely static and can not be changed at all. If
> one follows that claim, it is natural to see there can be no
> evolution, as evolution requires change by definition.
>
> Anyhow, as you say, there are interfaces that the syslog world can get
> hold of the complete journal data, and that is what I was originally
> interested to learn.
>
>>>>> 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
>>>
>>> I understood from your posting, that you provide everything that is
>>> logged, not matter what API is used, but only the non-structured data
>>> part.
>>
>> We just forward the exact same information syslog information we have
>> intercepted, and we will also the syslog compatible part of the native
>> journal information we received. But we are absolutely not allowed to
>> change the format of the messages we from /dev/log.
>
> Note that I was following your initial answer that the syslogd does
> not need to talk to the journal API because it receives all it needs
> via the system log socket. Now this seems not to be true, as important
> parts are missing. As such my initial assumption that the journal API
> must be used was true. I wanted to clarify that point.
>
> Also, I do not understand, even if syslog would be totally static, why
> it could break anything if you provide the full information, including
> structured data, for a message you received via the *new* API.
> Obviously, as it came in via the new API, the message did not exist
> before. It is hard to envision that you can break backwards
> compatibility for something that formerly did not even exist.

Sure the stuff that is received from all the new clients could be
logged in a different format. But it would require to select one of
these pretty uncommon formats, which we should avoid.

And as said, I'm not convinced that journald should ever get into the
business of any new syslog formats, that's what a syslog
implementation is for. The exception would be if glibc changes to add
metadata, then we can seriously start using the same format, but until
that happens, be better don't touch things.

You can just add a tiny bridge or make rsyslog receive the proper data
which has no fixed wire format at all, but is an API we can extend as
needed.

Honestly, I really don't understand your claims, all will be available
to you with just a few lines of code. Syslog should start integrating
with the system, not expect something else to translate the system's
data to just another pseudo free form wire format.

We can not and should not pimp up old syslog wire formats and break
all sorts of things we don't even want to look at. It would just be a
recipe for madness.

If syslog is needed syslog should solve that problem.

Kay