Re: [syslog-ng] flags(final)

12 Nov 2009


      Balazs Scheidler wrote:
...
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.
OK, just so that it's known.  Meanwhile, I know what to look for if I 
see this again.

Thanks,
MJB