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. would this have similar performance impact to running in debug mode? or does this need less serialization, and therefor less impact? > 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? 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
