[systemd-devel] Linux Journal API/client lib
Rainer Gerhards
rgerhards at gmail.com
Mon Dec 5 01:51:16 PST 2011
On Mon, Dec 5, 2011 at 1:40 AM, Kay Sievers <kay.sievers at vrfy.org> wrote:
> On Sat, Dec 3, 2011 at 20:41, Rainer Gerhards <rgerhards at gmail.com> wrote:
>> I have digested our discussion now. Two questions came up:
>>
>> The first one is a bit direct and blunt, my apologies for that. But I
>> want to make sure I put effort into the right place. Do you see any
>> benefit in an interface like I described (reading and writing the
>> journal from the syslogd)? Or do you think this is a needless effort?
>
> Oh sure, I think it can be very useful. We might need to find out how
> to identify such a stream of data in the journal, or if we should make
> it possible log things for a different machine-id. Your example like
> the SOHO router which pushes out syslog data could possibly get a
> machine-id assigned from the syslogd config that processes the data.
> We need to find out the details ...
>
> Syslog will not go away in many setups, the network log from other
> hosts which speak syslog, real boxes or the specialized hardware like
> a SOHO router, will speak the current syslog for a very long time in
> the future. And we don't want to speak real syslog with the journal;
> that's all stuff that should be done with syslog, and possibly if it
> can act as a bridge to the journal index, it sounds like a very nice
> option to have.
This sounds reasonable to me as well. IMHO a bit problem in this
process is how to keep trusted things trusted. But I understand that
you currently have more important core things to do than tackle that
beast or interop. I would be happy to provide feedback once you look
at this issue.
>> The second one is on /dev/log: is what is provided to the syslogd just
>> like "the real thing"? I am specifically concerned if SCM_CREDENTIALS
>> will properly identify the log emitter.
>
> We expect we are able to fake all the properties. If not we will need
> to make that possible, we didn't look into the details as of now, but
> the plan surely is to make /dev/log behave like it is without the
> journald interception.
Yes, that would be very important, especially as the rate-limiting in
rsyslog heavily depends on SCM_CREDENTIALS (as do some other things,
but rate-limiting is the most important one IMHO).
Thanks again,
Rainer
More information about the systemd-devel
mailing list