On Sat, 18 Oct 2008, Rainer Gerhards wrote: > 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".
there's a big difference between "I don't care about message loss if a system crashed" and "I don't care about message loss at all" admins should evaluate the probability of the different message loss scenerios and decide on the appropriate cost/benifit for their situation. it's very possible that someone may not care about loosing logs when a system crashes (becouse it's a fairly rare event), but isn't willing to loose logs just to rotate log files. > 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. and unfortunantly, the process of writing the pending queue to disk and then reading it back after a restart can greatly lengthen the restart, causing incoming logs to be missed (depending on how able the log sender is to queue the log messages for your) > 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. thanks. >> >> 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 the purpose of this message was mostly to try and prompt the other people who commented in this thread to think about the issue and comment on their expectations. >> >> 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 am not trying to preasure you into rushing on this, just to get opinions on which is the 'more expected' behavior for HUP >> >> 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. I would definantly not recommend this one becouse of the difficulty involved, but in the interest of completeness I thought it needed to be mentioned. David Lang _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
