> -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of [email protected] > Sent: Thursday, April 28, 2011 8:41 PM > To: rsyslog-users > Subject: Re: [rsyslog] thoughts on rsyslog's (multi-)config system > > 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)
Well, actually this is what I am currently working on -- restructure the config system to a more decent one. It's considerable work, and there will be no immediate benefits (other than that privilege dropping will work fully correct). I don't even know if I can complete that work in a single iteration or may need more than one. I think the long-term benefits will justify this "waste of time", as it first will seem to be. The current config system really is a blocker for some very useful things (e.g. the one we just discuss or a new config language). Rainer > > 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
