[syslog-ng] Duplicate configuration items causing memory leak

[Dave Rawks]

On 11/09/2011 12:38 PM, Balazs Scheidler wrote:
>> Does this patch break the behavior described in the documentation for
>> 3.3.1?
>>
>>> If an object is defined twice (for example the original syslog-ng 
>>> configuration file and the file imported into this configuration
>>> file both define the same option, source, or other object), then the 
>>> object that is defined later in the configuration file will be 
>>> effective. For example, if you set a global option at the beginning 
>>> of the configuration file, and later include a file that defines the 
>>> same option with a different value, then the option defined in the 
>>> imported file will be used.
>>
>> If you cannot overload previously defined objects then the ability to
>> include config files becomes FAR less useful imho.
> 
> uhm, uhm. Yes it does. I didn't know this was a documented feature :)
> 
> This could be controlled (possibly by a configuration variable), but
> before I do that could you explain your usecase, which makes include
> files to be less useful?
> 

Well, the standard case for having includes would be for use in
distribution packaging. Where syslog-ng would ship with a default
configuration and would then do an include against a directory of files,
a "conf.d" style setup. Later other packages could drop bits of
configuration into conf.d. Lets say you install some theoretical log
collection and parsing application via a distribution provided package.
Previously when overloading was supported that new package could drop a
config chunk which overloads a "log object" from the default config so
that now instead of outputting to a file it outputs to a destination
object defined in this new config.

Actually I was assuming that not only would this behavior persist into
future versions of syslog-ng but I had also hoped that it would be
enhanced to allow for things like partial overloads or concatenation of
existing object definitions such as is available in software such as
nagios. Since there is no function by which later defined objects can
interrogate the state of earlier objects nor is there any capability for
conditional object definition (afaik) there is some inherint limitation
to the complexity of the configs which could be generated still, but
this would be a huge step forward in config flexibility.

------Separate but related thought ;)

Speaking of which, it would be nice if there was some method of bundling
objects together. So that for instance you could define:

> source s_local {
>         internal();
>         unix-dgram("/dev/log");
>         file("/proc/kmsg" program-override("kernel") flags(kernel));
> };
> source s_remote {
>         syslog(
>         transport("udp")
>         so_rcvbuf(16777216)
>         );
> };
> source s_everything {
>         source(s_local)
>         source(s_remote)
>         );
> };

I might be missing something, but afaict there is no easy method to do
such a definition in the documentation.

-Dave Rawks