> -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of Marcin Miroslaw > Sent: Tuesday, June 05, 2012 3:33 PM > To: [email protected] > Subject: Re: [rsyslog] Adding message when rsyslogd terminates > > W dniu 05.06.2012 15:19, Rainer Gerhards pisze: > > Even after reviewing the full debug log, this keeps being mysterious. It > somehow intends to submit the message, but it is never actually enqueued. As > we have small debug logs, we can probably go the extra length and include very > precise program flow information. > > > > IMPORTANT: you need to run ./configure with --enable-rtinst, else we will > > not > get any additional information. Then set > > > > export RSYSLOG_DEBUG="debug logfuncflow" > [...] > > > (this is an excerpt from the shutdown message processing on my machine). > Note that not 100% of all function calls are covered, but the vast majority > is. So > the debug log with these settings should provide very precise information - > let's > hope for the best... (at least it should provide clues where further > instrumentation would be beneficial). > > > > Please give it a spin. Note that the debug log is 3..5 times larger than > > what you > are used to. *Never* try this on a production system ;) > > I've tried on production desktop, we all are still alive;) Hehe, what I meant ist hat it will easily thrash a system that is running real production traffic (I guess the slowdown is around 100 times ;))
> Debug log is attached. Yup, that one helps. It is interesting how different timing I have. The root of the problem is that I set global input termination state and log the message after that. The queue engine checks this state and, depending on circumstances, refrains from enqueuing the message. This is actually a hard problem. Because if I log the message before shutting down the other inputs, rsyslog could hang for quite a while due to full queues. I need to review the whole thing in the big picture. I also need to find out why the same behavior does not occur at my environments (but I guess it actually is race-induced, but on the other hand...). In any case, we now have at least a solid track of what is going on. And it is quite more complex than originally thought. Thanks! Rainer _______________________________________________ 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
