On Wed, 27 Apr 2011, Rainer Gerhards wrote:
Hi David,
thanks for the feedback. But I don't think I can avoid loading modules if I
will support the current config format. And this is something I definitely
want to do.
Other than that, you are of course right that I can use name-value pairs to
avoid loading modules in the first step. However, validation is required.
Unforutnately I did not explicitely spell out the validation step. But I
think it is a necessary step to be done right after loading a config and
before it turns into a real candidate config. So even in this PoV, loading
modules is necessary for validation and thus for the config load process.
Ok, I was thinking that the validation could be delayed until very late in
the process, basically at the point where you are considering switching to
the config.
you are spending a lot of effort in worrying about loading and unloading
modules.
what is the harm in leaving additional modules loaded? yes, they will eat
a little memory (but generally not a lot), but will they actually have any
impact on the running system? If not, I wouldn't worry about trying to
unload them (and all the tracking that requires)
As for the problem of multiple module paths, I would tend to say that if
you are changing things to that extent, you really should restart rsyslog.
that's like changing the rsyslog binary and expecting the system to cope
with it in flight.
one other headache that you don't mention is the problem of changing queue
types while there is data in the queue.
David Lang
Rainer
-----Original Message-----
From: [email protected] [mailto:rsyslog-
[email protected]] On Behalf Of [email protected]
Sent: Wednesday, April 27, 2011 9:05 PM
To: rsyslog-users
Subject: Re: [rsyslog] thoughts on rsyslog's (multi-)config system
On Wed, 27 Apr 2011, Rainer Gerhards wrote:
Hi all,
without any pressing need, I'd like to share with you some thoughts
of a
potential future rsyslog multi-config system:
http://blog.gerhards.net/2011/04/rsyslog-config-reload-random-
thoughts.html
This is NOT something I intend to fully implement soon, but I am
working a
bit on paving the way.
my first thought (while still reading the post) is that you really
shouldn't need to load the modules to parse the config file into a
memory
structure.
you will need to load the module to _validate_ the config (to see if
all
the config items are valid and contain valid data types)
but the config language should be such that the structure of the config
and the process of parsing the config options into a memory structure
should be a separate step before doing the validation.
I think this should significantly simplify your task compared to doing
the
validation and parsing at the same time.
among the other benifits, this lets you have one validation engine,
even
if you support multiple config languages (old + new for example)
David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
