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

[Lennart Poettering]

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

-- 
Lennart Poettering - Red Hat, Inc.