On Wed, 4 Nov 2009, Rainer Gerhards wrote: >> -----Original Message----- >> From: [email protected] [mailto:rsyslog- >> [email protected]] On Behalf Of [email protected] >> >>> >>> 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).
yes, this would not help see what triggered the problem, but could be a huge help in figuring out what the current state of things are. going to a file could work as well. in either case a config option would have to be created to specify the destination. >> 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. even in a high volume production environment this can be tolorated for short time periods. currently there is no way (short of stop, reconfigure, start, stop, reconfigure, start) to try and gather this info, and each stop will loose logs, so this ability would be much better. >>> 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...). it all depends on what imdiag can do, and where the control signals come from. if the contol is via normal syslog messages it is a problem, on the other hand if it creates a new socket that it listens on that can only be written to by root it's probably far less of a problem. I guess the real response is that I don't know enough about imdiag to know the risks. David Lang _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
