[syslog-ng] syslog-ng 3.5.1 - question about flags(final)...

[Balazs Scheidler]

On Mon, 2013-11-18 at 22:02 +0000, Johnson, Chris (HP TippingPoint
Roseville) wrote:
> Hello all,
> 
>  
> 
> I'm in the process of upgrading from version 3.3.9 to 3.5.1 and have a
> question about how the 'flags(final);' is working in 3.5.1.
> 
>  
> 
> In 3.3.9, I use the following structure of imbedded log statements:
> 
> ################################################################################
> 
> # Service ipsec
> 
> #
> 
> filter f_ipsec_pgm{program("IPSEC-*" type("glob"))
> 
>         or program("IKE-*" type("glob"))
> 
>         or program("CHARON-*" type("glob"))
> 
>         or program("charon-*" type("glob"));
> 
> };
> 
> filter f_ipsec_lvl_01{level(warning..emerg)};
> 
> filter f_ipsec_lvl_02{level(info..emerg)};
> 
> log {
> 
>         source(s_local);
> 
>         filter(f_ipsec_pgm);
> 
>         log {
> 
>                 filter(f_ipsec_lvl_01);
> 
>                 destination(d_logID_11);
> 
>         };
> 
>         log {
> 
>                 filter(f_ipsec_lvl_02);
> 
>                 rewrite(r_quote_newlines);
> 
>                 destination(d_logID_13);
> 
>         };
> 
>         flags(final);
> 
> };
> 
>  
> 
> In this case log messages of the 'correct' program would further be
> filtered on their severity level.
> 
> ·        Info level messages would only be sent to 'd_logID_13'
> 
> ·        Warning level messages (and above) would be sent to BOTH
> 'd_logID_11' and 'd_logID_13'.
> 
> ·        Debug level messages would be discarded.
> 
> Under 3.5.1, the 'filtering ' stops after it matches once:
> 
> ·        Warning messages (and above) are only sent to 'd_logID_11'
> and NOT 'd_logID_13'.
> 
> ·        Info messages are still (correctly) being sent only to
> 'd_logID_13'.
> 
> If I remove (or comment out) the 'flags(final);' statement, messages
> are filtered correctly (i.e. the way I *want* them to be filtered J)
> 
> except that they also are being processed by all the following log
> statements and are being caught in my final filter of 'program("*"
> type("glob"))'.
> 
> NOTE: yes, I know that I could use 'flags(fallback)' in my final
> filter, but that would still have every message processed by every log
> filter, and I would like to avoid that.
> 
>  
> 
> So, what would be the correct way to set up my log statement to
> re-create the 3.3 behavior?

This sounds like a bug to me. Although there's nothing related in the
3.5 tree, 3.4 had a great reorganization in the area.

Let me check.

-- 
Bazsi