[systemd-devel] systemd-logger and external syslog daemon

[Rainer Gerhards]

> -----Original Message-----
> From: Lennart Poettering [mailto:lennart at poettering.net]
> Sent: Friday, March 11, 2011 5:29 PM
> To: Rainer Gerhards
> Cc: Andrey Borzenkov; Michael Biebl; Mike Kazantsev; systemd-
> devel at lists.freedesktop.org
> Subject: Re: [systemd-devel] systemd-logger and external syslog daemon
> 
> On Fri, 11.03.11 17:22, Rainer Gerhards (rgerhards at hq.adiscon.com) wrote:
> 
> > > > Systemd shuffles the system log socket to the kernel log. That is
> > > > nice, because we have logging available right from the system start.
> > > > However, in rsyslog users can configure different rules based on
> > > > the log source. The issue now is that what used to be the local
> > > > log socket source now becomes the kernel log source. I don't think
> > > > this causes many problems in almost all environments, and I guess
> > > > it would require some non-trivial "magic" in rsyslog to handle the
> > > > situation (and I am not sure it is worth that). But I wanted to
> > > > mention this point ;)
> > >
> > > I think rules like this should look for the facility field, and we
> > > should
> > allow
> > > facility bits in the kmsg messages, so that userspace messages can
> > > clearly mark themselves as such.
> >
> > There are too few facilities for this to work. Also, the engine can
> > bind to different rulesets depending on the message origin. It is not
> > trivial to re-route messages in this context. Granted, that's not a
> > problem for a typical system, but it can be one in high-end environments.
> 
> Nah, the facility 0 is kernel, and that's all we need. So, if you find a
message in
> kmsg with facility=0 then you know it is the kernel which logged into the
> kernel log buffer. However, if facility is != 0, then it is userspace which
logged
> into the kernel log buffer.
> 
> I think we shouldn't confuse the transport with the origin of messages.
Since
> time began it was possible to log to /dev/kmsg from userspace. Not much
> code did so, but already then /proc/kmsg was a transport for both kernel
and
> userspace messages.
> 
> Traditionally userspace didn't add valid facility values to the messages it
> logged to /dev/kmsg when it did so. What I am suggesting is to add that, so
> that we can correct the current implicit assumption "transport is
/proc/kmsg
> → origin is kernel" into "facility is 0 → origin is kernel".

Lennart, you have a too simplistic view of modern syslog ;) It's no longer
about those poor 24 facilities. Routing based on origination is popular (and
very useful) both in rsyslog and syslog-ng. For example, it offers
performance benefits for high-end scenarios. So source matters. Don't just
think about desktops ;)

I see that you do some quite good things with systemd, but it is plain fact
that these things violate some layers from a syslog perspective. So there
*is* a problem with these things being done. I don't say it's a showstopper,
and I agree it is useful, but It causes problems...

For example have a look at the architecture picture (figure 5) on page 18 of
this paper:
http://www.gerhards.net/download/LinuxKongress2010rsyslog.pdf

The different inputs are the different sources. So messages from /dev/log may
be totally differently processed than those from the kernel log. What you ask
for it to create a re-routing facility inside the message router.

Rainer