[syslog-ng] flags(final)

[Michael J. Bauer]

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