Revisiting: problem with filter behavior in 2.0.4
Hello. I posted the below message on 13 July to the list, but still received no response. I'm wondering if I'm seeing a bug in syslog-ng, or there's some configuration detail I've overlooked. Balazs, could you comment on this please? Since I posted the original message, I'm seeing all kinds of messages in the "critical.log" file that shouldn't belong, according to my understanding of the filtering, e.g. messages from facility+priority combination "user.info" without the string "crit" anywhere within the message (though oddly enough in that example, the word "subscription" is present in the message, which differs from "crit" by the addition of the "p" before the "t", but I'm not sure if that's anything more than coincidence). Anyway, I'd appreciate it if someone could help me look into this. -- aero1967@fastmail.fm -- http://www.fastmail.fm - A no graphics, no pop-ups email service ----- Original message ----- I'm seeing some results with filtering that I don't expect / understand. I have the following statements in syslog-ng.conf (I am just giving the relevant configuration lines): source src { unix-stream("/dev/log"); internal(); file("/proc/kmsg"); }; filter kern { facility(kern); }; filter kern_critical { filter(kern) and priority(emerg .. err); }; filter critical { filter(kern_critical) or match("crit*") or priority(emerg .. crit); }; template verbose_msg_fmt { template("$FULLDATE $FACILITY.$PRIORITY $MSG\n"); template_escape(no); }; destination root_tty { usertty("root"); }; destination critical_logfile { file("/var/log/critical.log" template(verbose_msg_fmt)); }; log { source(src); filter(critical); destination(root_tty); destination(critical_logfile); }; There are no other configuration lines which reference the critical_logfile destination , and no destination has a "final" flag. Now, when I check /var/log/critical.log, I get messages from the facility.priority combination of daemon.warning that do not contain any string starting with "crit". I also get messages from daemon.err, which also shouldn't match the filter. For example: 2007 Jul 12 10:51:07 daemon.warning <message, not containing the string crit anywhere> 2007 Jul 11 20:33:57 daemon.err <message, not containing the string crit anywhere> IIRC, I was using these same lines in a syslog-ng 1.6.x installation without these kinds of results.
On Wed, 2007-08-22 at 13:29 -0400, aero1967@fastmail.fm wrote:
I posted the below message on 13 July to the list, but still received no response. I'm wondering if I'm seeing a bug in syslog-ng, or there's some configuration detail I've overlooked. Balazs, could you comment on this please?
Since I posted the original message, I'm seeing all kinds of messages in the "critical.log" file that shouldn't belong, according to my understanding of the filtering, e.g. messages from facility+priority combination "user.info" without the string "crit" anywhere within the message (though oddly enough in that example, the word "subscription" is present in the message, which differs from "crit" by the addition of the "p" before the "t", but I'm not sure if that's anything more than coincidence).
match() has a regexp parameter in which '*' means (0-n) repetitions of the previous character. crit* matches cri, crit, critt, crittt and so on. -- Bazsi
participants (2)
-
aero1967ļ¼ fastmail.fm
-
Balazs Scheidler