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. 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. all the scripts that use HUP to roll logs don't really care about the config files 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 David Lang _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
