the headache is that currently on rsyslog, it's not a matter of reading
the config and then implementing it. it's a matter of read a line of the
config, implement that line, read the next line, implement that line, etc
each line can load a module, change the userid, set a config option, etc
(and can have side effects depending on the module involved)
in an ideal world your approach would be great, but I question if the
benifits are worth the large effort right now to re-write the
configuration parsing/implementation (including changing how all the
modules add config options)
David Lang
On Thu, 28 Apr 2011, Aaron Wiebe wrote:
This is the process I've used in the past:
1. Read the file into memory.
2. First pass parse and check for config validity.
3. Repeat 1 & 2 for included/referenced files.
4. Replace or merge new config after all config checks are complete
5. Clean up old config options that have not been validated/merged
from new config
-Aaron
On Thu, Apr 28, 2011 at 2:20 PM, Rainer Gerhards
<[email protected]> wrote:
-----Original Message-----
From: [email protected] [mailto:rsyslog-
[email protected]] On Behalf Of [email protected]
Sent: Thursday, April 28, 2011 8:17 PM
To: rsyslog-users
Subject: Re: [rsyslog] thoughts on rsyslog's (multi-)config system
On Thu, 28 Apr 2011, Aaron Wiebe wrote:
On Thu, Apr 28, 2011 at 12:11 PM, <[email protected]> wrote:
2. a wierd, out of the box thought (in the 90% as good for 20%
effort
category)
rather than tring to modify the running config, how about forking
the main
thread, having the old main thread close the inputs, and the new
main thread
'shutdown' all it's other threads, then the new main thread can
treat this
as something very close to a normal startup (basically modulo
privilage drop
issue)
you could either let the old process/threads run until they finish
delivering all their messages, or you could have them deliver the
messages
to the new main thread (the former is probably the easiest, the
question is
are there more corner cases with both sets of threads outputting to
the same
destinations, or with potentially mishandling messages that were
already
processed in the old copy that would have been processed differently
in the
new copy)
I've tried to do this with other software - it's a PAIN. Effectively
you have to transfer the memory state between threads/processes.
It's
not easy.
Honestly, config reload is less error prone.
my point is that insead of figuring out what effect all the loaded
modules
have, how to apply all the modifiers in order, etc. just throw out all
of
the existing config and start the new config clean from scratch, but do
it
in a separate process so that the existing one can keep processing the
logs it's already received.
That bad thing is that this doesn't work for existing TCP connections. Of
course you can start processing new connections with the "new" instance, but
that means that new data coming in via old connections - even hours later -
would still be processed by the old config.
Rainer
_______________________________________________
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
