On Sat, 2008-10-18 at 02:32 -0700, [EMAIL PROTECTED] wrote: > 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"
That's right. But I was not talking about a crash condition. I was talking about a shutdown (or a restart). With the default settings, rsyslog does what sysklogd does, that is (mostly) not care about message loss. If you shut down the daemon, it tries to drain the queue for a short timeout. If all messages can be processed during that time, we are fine and terminate rsyslogd without message loss. However, if there are too many messages queued, the daemon terminates after the timeout has expired and discards whatever messages are left unprocessed. This is done in an effort to keep compatible with sysklogd. Also, in most scenarios it is highly unlikely that message loss will occur, because the queue will not hold extended data for an extended period of time. If, however, this is anticipated, there are ways to configure rsyslog not to loose messages. For example, the timeout can be increased and/or the queue can be made disk-assisted and data be written to disk if they can not be processed during the timeout. During queue drain, no new messages are accepted (otherwise, how should we finally shut down?). Given a busy system, there is unavoidable message loss. Either you use old messages you already had in the queue, but have a quick restart and loose few new messages. Or you save the already existing messages but experience loss of new messages. This is another reason for the default, which I consider the best compromise under the circumstances given. This is also a good indication why you should not unnecessarily restart rsyslgod (or any other syslogd, because this is not a project-specific problem but rather a general one). With fully reliable protocols, you can of course make the sender block while you are shutting down. But all of this requires very careful planning. I assume folks who want to do that either have the necessary knowledge themselvs or hire someone who does. So there are three scenarios: a) hup b) regular shutdown c) system abort I think you did not take into account b), which is a quite common case. Other than that, I fully agree to you post. Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
