> > 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.
definitely > going to a file could work as well. in either case a config option > would > have to be created to specify the destination. traditionally, this is done via environment options, please see: http://www.rsyslog.com/doc-debug.html It may very well work just be specifying a file and sending SIGUSR1 - but I have never tried that in a production run (which also means I *never* tested it). When I added this mechanism, I selected envrionment variables because that enables to change the settings without touching the config file. Obviously it wouldn't be much of a problem to create config options for them as well. > > >> 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. Most of that needs to be written, so we can specify what is acceptable. So far it listens to a network socket. This was intended so that testcases can be build without the need to fiddle with local socket creation policies. One potential was would also to selectively enable/disable imdiag functionality inside the config file. The GUI front-end I (barely) started to write talks to imdiag, but this is not really anything decent so far. In the long term, I'd like to be able to pull things like queue status, modules loaded, action status and the like from a running instance as well as inject not only messages but change some settings on the fly. My initial need was to provide a consistent rsyslog/UDP monitoring solution (for performance testing) as well as problem analysis. Rainer > > David Lang > _______________________________________________ > 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
