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
