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
