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

[Mike Kazantsev]

On Thu, 10 Mar 2011 22:01:39 +0100
Lennart Poettering <lennart at poettering.net> wrote:

> 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?
> 

The same rsyslog.
Format is "facility.priority cmd[pid]: ", but in case of kmsg looks like
rsyslog doesn't try to interpret "process[pid]: " prefix, at least, so
my guess is that it doesn't try to get any syslog metadata from this
messages, just passing them as-is from kernel.warning kernel[-].


> > 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.
> 

Thanks, will test it asap.


> Lennart
> 


-- 
Mike Kazantsev // fraggod.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20110311/1f7d465b/attachment.pgp>