But then the FAQ contradicts this with it's "expanded
syslog-ng.conf" (http://www.campin.net/syslog-ng/expanded-syslog-ng.conf) where
it uses:
dunno what that site is but
http://www.balabit.com/network-security/syslog-ng/
is where syslog-ng comes from
source s_kernel
{ pipe("/proc/kmsg" log_prefix("kernel: ")); };
well that's plain wrong (see manual on balabit.com)
source src { file("/proc/kmsg"); unix-stream("/dev/log"); internal();
};
in http://www.campin.net/syslog-ng/faq.html#klogd
as it should be...
therefore I am not sure if enabling logging kernel messages without
disabling klogd is a good idea.
Of course. I don't use klogd here. Perhaps the packaging of syslog-ng
should be such that it's mutually exclusive of whatever provides klogd,
although I am not sure which package that is given that I don't use it
here. :-) I'm also unsure if the ipk format allows the specification
of "conflicts".
I just found it is run by /etc/init.d/boot .. maybe it should be
conditionally started only if some uci config of syslog-ng is not set..
or else ...
Also you should use file() and of course
add it to the log declaration.
Well, the package authors themselves seem to use file and pipe
with /proc/kmsg quite interchangeably. I think I'd like to see more
clarification before I change what I think has been the historical use
case.
do whatever you like, for me the reasoning (locking and rw accessing a
non writeable handler) in the official syslog-ng manual makes perfect sense
Of course, you can go ahead and submit a patch to change it yourself if
you like, but using pipe() is working plenty fine here and I log plenty
of kernel messages (i.e. every firewall exception and there are tons).
good for you ... still the patch is lacking the part where you actually
log the source
kind regards ede
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
