My biggest use case for SIGHUP tends to be updating addresses of things in a cloud environment. For rsyslog I just use DNS.
On Thu, 24 Nov 2016, 19:31 David Lang, <da...@lang.hm> wrote: On Thu, 24 Nov 2016, mosto...@gmail.com wrote: >> what are people's thoughts on these ideas? > > Notice there can be multiple reload scenarios: > - reload rsyslog config (new modules, inputs, rulesets, actions...) for now I am explicitly not trying to support the reload of the entire config. That really is a hard problem and effectively the same thing as a restart (and what happens to log messaes if the new config doesn't have the same queues as the old config? > - add new inputs and remove inputs so that things can be unmounted > - modify a template > - resize a queue I don't see these as being that useful. And resizing a queue can be rather complicated. growing an array means you have to have the address space for it to grow into, or you have to copy the contents of the array. shrinking an array doesn't actually give you more available ram, it just results in unused ram. > The simplest approach I can imagine is to signal HUP to reload: when signal > is received, everything is stopped, reloaded and resumed. It may be faster > than restart, cause modules are already loaded or objects (templates, > inputs...) still in memory. rsyslog used to do that, but it resulted in log messages being lost at every hup (especially in high-traffic, complex config use-cases), that's why the HUP was changed to just be a log rotation thing, closing all outputs. the problem with using HUP like this is that you don't know when the process is complete. you don't know when the system actually delivers the signal to the process, let alone when the process finishes closing everything. A synchronous API for this sort of thing would be useful. > There's a lot of space for improvement: unload unneeded modules, restart only > modified objects, rollover updates...but TBH I don't know if I would go to > such API. what would you mean by 'restarting' something? I think you would be adding a huge number of complex mechanisms that would never be used, and therefor would be likely to develop hidden bugs. David Lang _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT. _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
