> -----Original Message----- > From: Lennart Poettering [mailto:lenn...@poettering.net] > Sent: Friday, March 11, 2011 5:29 PM > To: Rainer Gerhards > Cc: Andrey Borzenkov; Michael Biebl; Mike Kazantsev; systemd- > de...@lists.freedesktop.org > Subject: Re: [systemd-devel] systemd-logger and external syslog daemon > > On Fri, 11.03.11 17:22, Rainer Gerhards (rgerha...@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, you have a too simplistic view of modern syslog ;) It's no longer about those poor 24 facilities. Routing based on origination is popular (and very useful) both in rsyslog and syslog-ng. For example, it offers performance benefits for high-end scenarios. So source matters. Don't just think about desktops ;) I see that you do some quite good things with systemd, but it is plain fact that these things violate some layers from a syslog perspective. So there *is* a problem with these things being done. I don't say it's a showstopper, and I agree it is useful, but It causes problems... For example have a look at the architecture picture (figure 5) on page 18 of this paper: http://www.gerhards.net/download/LinuxKongress2010rsyslog.pdf The different inputs are the different sources. So messages from /dev/log may be totally differently processed than those from the kernel log. What you ask for it to create a re-routing facility inside the message router. Rainer _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel