On Thu, 10 Mar 2011 22:01:39 +0100 Lennart Poettering <lenn...@poettering.net> wrote:
> On Wed, 23.02.11 12:48, Mike Kazantsev (mk.frag...@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
signature.asc
Description: PGP signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel