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

[Lennart Poettering]

On Wed, 23.02.11 12:48, Mike Kazantsev (mk.fraggod at gmail.com) wrote:

> Good day,
> 
> 
> I've recently deployed systemd on a machine that uses some syslog
> monitoring software and the software went nuts because messages from
> systemd logger were inconsistent with other logging - they all look
> like this:
> 
>   kernel.warning kernel[-]: process[pid]: message contents
> 
> Thus, regardless of what systemd.exec(5) states, SyslogFacility= and
> SyslogLevel= is irrelevant - to a syslog daemon they will be passed as
> "kernel.warning".

Hmm, that is borked. We do provider proper error levels when we write
things to kmsg. This must get lost later on. But we do strip the
facility, so that it gets replaced by "kernel", that is true.

The only reason we strip the facility however is because the "dmesg"
tool chokes on it. The kernel is completely fine with it. I think if
we'd fix dmesg we should have no trouble with making the kernel log
buffer a full featured syslog queue like any other.

And the "kernel[-]: " syntax must be from your log implementation,
too. What syslog implementation is that?

> Naturally, the reason is "systemd-kmsg-syslogd" daemon, which spawns
> early on boot from syslog.socket and creates /dev/log, which is
> accessed by systemd-logger long before external syslog daemon starts.
> Syslog daemon (rsyslog in my case) just grabs these from kmsg.
> 
> After that, substituting /dev/log for another socket (like
> rsyslog.socket seem to do) or just removing it doesn't seem to
> matter - systemd-logger will keep feeding messages to dmesg via
> kmsg-syslogd.

Well, not anymore if you use a socket activatable syslog daemon. In that
case the original socket is just handed over and rsyslog continues
dispatching syslog messages where the bridge left of.
 
> I read Kay Sievers's earlier post in this list on the subject, which
> states "Syslog services have been patched to be able to seemlessly take
> over an already opened /dev/log. rsyslog is upstream already...".
> 
> Yet I've tried latest scm version of rsyslog and it doesn't seem to
> "take over an already opened /dev/log" if started via upstream-shipped
> rsyslog.socket unit (which just uses "ListenDatagram=/dev/log") line.

it does now, since a couple of days, see my headsup message i posted a
few days ago.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.