> -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of [email protected] > Sent: Wednesday, November 04, 2009 2:29 PM > To: rsyslog-users > Subject: Re: [rsyslog] Queuing bug (4.5.5) / Problem in production > > On Wed, 4 Nov 2009, Rainer Gerhards wrote: > > >> it is really a pain to run into problems only in production. > > > > The problem with hunting such bugs is that we cannot get the > diagnostic > > information we need. I have thought about a solution. Could you > please > > comment if this one would be acceptable for your environment: > > > > I add the capability to send the debug log out via UDP syslog (not > via the > > usual channels, but rather via a special send function inside the > debug > > printf system). Then, when a problem occurs, we could enable the > debug printf > > (which is present in production builds as well) and make it output > the data > > to a remote server (or a special listener, even netcat, running on > the local > > machine). > > > > I could turn on/off this via a signal (as we currently do for sending > debug > > message to stdout). > > that would be a LOT easier than having to run in debug mode the entire > time.
The problem is that you would not get the information BEFORE you turned in on. In theory, it should even be possible with the current system and a file, but I need to check this out (I never used it that way, but the engine probably is capable of doing it). > would this have similar performance impact to running in debug mode? or > does this need less serialization, and therefor less impact? Think of it as turning on debug mode on the fly. That exactly is what it does. So before the signal, there is no impact, but after it is the same impact as usual. > > Alternatively, one could load imdiag into a suspect instance and use > that to > > gain more in-depth information. However, I am not sure if that would > be > > suitable for use in production, at least it is questionable from a > security > > POV. > > is loading this on the fly even possible? NO, that's the point. If we intend to pursue that path, imdiag always needs to be loaded. That does not have any performance impact (but a security impact!). Once imdiag is loaded, it could be used to do all sorts of "interesting" things (most of which need to be implemented first...). Rainer > > david Lang > > > Any feedback is appreciated. While I like to have better ability to > dig into > > problems as they occur, I don't think it makes sense to invest time > into > > coding something if it is unclear whether or not it could be > utilized... So > > unless I get sufficient positive feedback, I'll stay away from > implementing > > that. > > > > Rainer > > _______________________________________________ > > 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 _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
