[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:17 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 09:55, Rainer Gerhards (rgerhards at hq.adiscon.com) wrote:
> 
> > > Sounds quite reasonable :)
> > >
> > > What would be also really nice - some systemd specific marker so
> > > rsyslog could extract syslogd messages from kmsg. Not sure if it is
> > > really doable without some gross kernel hack though.
> > >
> > > Special severity level may be ... PRINTK_SYSTEMD? :)
> >
> > There is also a subtle issue with the current systemd implementation,
> > and that could potentially solved by such a setting.
> >
> > 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.

For rsyslog, it would mean I need to find some kind of an inter-module
interface, where imklog shuffles some of the messages to imuxsock. Maybe it
would make more sense if imklog in such cases simply forwards the messages to
the system log socket (which in that scenario should be bound to rsyslog).
But I don't think this is a really pressing problem -- we better see at least
one instance of it in reality before trying to fix it...

Rainer