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 -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel