Yes, that's what I was asking. I did notice that hooking up an event to the RotatingFileHandler was not simple. I played with a quick implementation where the RotatingFileHandler told the parent Logger that the log had been rotated, and then the logger told the POutputDispatcher, which could then send an event. This was a rather crude violation of encapsulation of the classes in the design, though it did work of course. I'll just stick with doing a bit more work on a TICK event.
-- David On Thu, 02 Apr 2009 23:21 -0400, "Chris McDonough" <[email protected]> wrote: > I think you're asking if it'd be OK to emit an event when the > RotatingFileHandler opens a new log file and renames its "current" file > to > "file.1". This transition was never meant to be hooked internally; it > would be > better to hook a TICK in an event listener I think. The > RotatingFileHandler > happens to rotate log files, but it's really at the very end of the > output > process and was never meant to be hooked back up to the event system. > > - C > > > [email protected] wrote: > > Hi- > > > > I'd like to catch processes that are logging more than an expected > > amount. I can write an event handler on the "TICK_60" (or similar) > > event, and then scan the log directory to do this. A somewhat more > > efficient solution would be to receive an event when the process logs > > are rotated (and then take some secondary action to see if the process > > is logging too much). > > > > The latter approach would require something like a PROCESS_LOG_ROTATE > > event (which doesn't yet exist). I've looked at the supervisrod code and > > prototyped this event -- but I'd like to know if this is overkill in > > general. Should I just stick with the TICK_60 event and then scan the > > logs directory? Would a "logs rotated" event be generally useful? > > > > Thanks, > > -- David > > _______________________________________________ > > Supervisor-users mailing list > > [email protected] > > http://lists.supervisord.org/mailman/listinfo/supervisor-users > > > _______________________________________________ Supervisor-users mailing list [email protected] http://lists.supervisord.org/mailman/listinfo/supervisor-users
