Hi, On Mon, 2010-07-26 at 19:43 -0700, Matthew Hall wrote:

Hello list,

In the course of my work I discovered two small defects in syslog-ng syslog-ng 3.0.7. Since I am not familiar enough with the code to patch these I am trying to do the best I can by reporting them to the experts. There are workarounds for these.

I am in the process of doing some other work on the product which I would like to contribute back in the near future after I figure out how the open-source contribution process works at this new company I joined.

Thank you for providing this product. I am impressed with the documentation and all of the capabilities and I look forward to becoming more expert with it over the coming few months.

Great to hear, we're always happy for more contributors. :) See my last blog posts on the topic.

Best Regards, Matthew Hall.

1) specifying the flags directive in a log stanza other than in the last position causes a syntax error

This specific format works:

log { filter(filter_local1); destination(dst_local1); parser(parse_switch); flags(final); };

Any format like this raises an error:

log { filter(filter_local1); destination(dst_local1); flags(final); parser(parse_switch); };

Is there some reason why or just a parser glitch?

Yup, this was changed in 3.0, where the log path directive was generalized. A log path can include branches to form a tree, rooted at the source and the destinations being the leafs. Message changes (e.g. rewrite rules) do not propagate over parallel branches. The syntax is like this: log { source(s_all); log { filter(f_branch1); destination(d_branch1); }; log { filter(f_branch2); destination(d_branch2); }; flags(final); }; So the flags can really appear at the last position.

2) using a version directive newer than the daemon version has unexpected behavior

If I feed 3.0 a file marked with @version: 3.1 tag, I get this error:

Configuration file has no version number, assuming syslog-ng 2.1 format. Please add @version: maj.min to the beginning of the file;

I think it does not make sense to fall back to the oldest format if the file has a newer version tag. Would it be better to try to process the file as the newest version with a warning, or print an error that the file is too new for 3.0 to read?

True enough, I've pushed these patches to syslog-ng 3.2 that implements what you describe. commit fb5c1444177e520124d578049dd53546faeaeb7c Author: Balazs Scheidler <bazsi@balabit.hu> Date: Wed Jul 28 09:58:10 2010 +0200 cfg: report too new config versions as well commit 021ca88602ea04628ad426923215aeb7adfae8a3 Author: Balazs Scheidler <bazsi@balabit.hu> Date: Wed Jul 28 09:57:53 2010 +0200 cfg-grammar: save the original formatting of LL_NUMBER/LL_FLOAT tokens Previously such tokens were reformatted in the case of the "string_or_number" rule, causing problems when the version number in the @version directive was parsed as 3.20 instead of 3.2. -- Bazsi