[syslog-ng] flags(final)

[Balazs Scheidler]

On Fri, 2009-11-06 at 17:06 -0500, Michael J. Bauer wrote:
> flags(final) is now working with my rewritten match() statements.  I 
> wonder if it was a combination of the older version I was initially 
> running and the odd structure of the log entry I was trying to use, but 
> I really am disinclined to try to chase it down.
> 
> However, in rewriting things, I did discover something else.
> 
> In cutting and pasting, I had accidentally done this in my config:
> 
> destination d_dhcpd {
>         file("/var/log/dhcpd"
>                 flush_lines(10)
>                 flush_timeout(1000));
> };
> 
> destination d_dhcpd {
>         file("/var/log/named"
>                 flush_lines(10)
>                 flush_timeout(1000));
> };
> 
> filter f_dhcpd {
>         match("dhcpd" value(PROGRAM));
> };
> 
> filter f_named {
>         match("named" value(PROGRAM));
> };
> 
> log {
>         source(s_sys);
>         filter(f_dhcpd);
>         destination(d_dhcpd);
>         flags(final);
> };
> 
> log {
>         source(s_sys);
>         filter(f_named);
>         destination(d_named);
>         flags(final);
> };
> 
> log {
>         source(s_sys);
>         destination(d_default);
>         flags(fallback);
> };
> 
> Note the log statement containing the non-existent 
> destination(d_named).  When I ran "/etc/init.d/syslog-ng reload", it 
> didn't crash, nor did it throw any error where I could see it.  What it 
> did do was start logging multiple copies of each line going to 
> destination(d_default), apparently one more line each time I did a 
> reload.  I didn't notice what was going on until it was at 8 copies of 
> each line, and it took me until 17 copies of each line to finally give 
> up and run "/etc/init.d/syslog-ng stop; /etc/init.d/syslog-ng start".  
> Once I did that, I got an error and corrected the problem.
> 
> This is probably an obscure bug, but it may be worth looking at.  It was 
> certainly entertaining after the fact.
> 
> MJB
> 
> Michael J. Bauer wrote:
> > I think I am misunderstanding what flags(final) is supposed to do.  I'm 
> > running syslog-ng 2.1.4 on RHEL 5.4 (Tikanga).
> >
> > I have a fairly simple syslog-ng configuration, which I've attached 
> > below.  I'm trying to pick off individual groups of log entries and put 
> > them in their own individual files.  I want to ensure that each gets 
> > logged exactly once, so I'm using flags(final).  I also have a catch-all 
> > at the end in case I've missed something, but the ultimate goal is to 
> > have that file present, but empty.
> >
> > However, with this configuration, the log entries that appear in 
> > d_network_address_translation (/var/log/network-address-translation) 
> > also appear in d_default (/var/log/default) despite the presence of 
> > flags(final) on an earlier log() line.  Should it work this way?  If so, 
> > what can I do to get the desired behavior?
> >
> > Thanks,
> > MJB
> >
> > options {
> >         sync (0);
> >         time_reopen (10);
> >         log_fifo_size (1000);
> >         long_hostnames (off);
> >         use_fqdn (no);
> >         create_dirs (no);
> >         keep_hostname (yes);
> > };
> >
> > source s_sys {
> >         file ("/proc/kmsg" log_prefix("kernel: "));
> >         unix-stream ("/dev/log");
> >         internal();
> >         udp(ip(0.0.0.0) port(514));
> > };
> >
> > destination d_network_address_translation              { 
> > file("/var/log/network-address-translation"); };
> > destination d_default          { file("/var/log/default"); };
> >
> > filter f_network_address_translation { host("router-service-interface") and
> >                                        priority(info) and
> >                                        facility(local2) and
> >                                        match("FWNAT"); };
> >
> > log { source(s_sys);
> >       filter(f_network_address_translation);
> >       destination(d_network_address_translation);
> >       flags(final); };
> > log { source(s_sys);
> >       destination(d_default); };
> >

I had one similar report already, but is only in our internal bugzilla.
If you have an unexisting destination reference and reload the
configuration, then something that you describe may happen.

I once tried to track it down, but it wasn't trivial, so I stopped and
this bug fell on the floor.

-- 
Bazsi