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.
David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
