On Fri, 2008-10-17 at 21:40 -0700, [EMAIL PROTECTED] wrote: > On Mon, 6 Oct 2008, Rainer Gerhards wrote: > > > So let me try to sum up where we are now: > > > > - it is considered useful to have a full daemon restart be done via HUP > > - we can not sufficiently simply detect whether the configuration > > has changed or not > > - there are situations where it is useful to have the ability to > > just close files, clear caches etc > > - people do not like existing things be used in new ways > > (least surprise principle) > > > > So I conclude: > > > > - SIGHUP, as ugly as it is, must stay with existing semantics > > - a new signal can be defined to just do file closure etc > > > > Unfortunately, this means that most systems will still use the terribly > > expensive during e.g. logrotation. However, this is considered > > acceptable because a) it always was this way, b) a higher demand > > environment then has options to avoid that. Over time, package > > maintainers my get maintainers of logrotate involved to change the HUP > > to the new signal. > > > > Am I grasping this right? > > I learned this week that on a HUP rsyslog will loose any messages that it > has in it's memory queue (due to the fact that it basicly does a full > shutdown and restart). I suspect that many other people would be surprised > at this as well.
Well, actually it depends. In the default configuration, this is true. But the spirit of the default configuration (suitable for most simple cases) is "I don't care about message loss". If you care about message loss, queues need to be configured so that no already-gathered messages are lost between sessions. If done so, messages are written to files before a shutdown and read from it upon restart. Of course, messages are still lost while the system is doing the restart (new ones). For a HUP and a very busy system, this can mean it takes a couple of seconds, even minutes, to do a full restart. After I noticed that the "message loss on HUP if not configured to avoid it" is not obvious, I added some explicit doc to the man pages so that people are warned they do a full restart. > > It looks like we have two options. > > 1. HUP will notice config file changes, but can loose queued logs > > 2. HUP will not notice config file changes, but will not loose queued logs > > I think that there would be less surprise in the second case. see comments above > > all the scripts that use HUP to roll logs don't really care about the > config files that was my initial observation. I will define another signal to just close the file. I hope I can get this done next week. Unfortunately, the financial crisis begins to hit the real world and this causes me to currently spent less time on new additions to rsyslog and more on profit-generating projects, but that should be doable in a day or two (the output module interface needs to be extend, a new administrative linked list implemented and the signal handler be done - changes to outputs are also necessary). > > I guess there is a third case, make a HUP not drop the queue, but if the > config file options for the queue change significantly, this can be a very > difficult thing to do This is extremely difficult, but of course doable. I think, however, this is only needed for a very limited number of cases. So this is probably something that I will only work on if a sponsor for this work shows up. Rainer > > David Lang > > _______________________________________________ > 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
