On Thu, Sep 16, 2010 at 7:10 AM, Martin Pool <[email protected]> wrote: > In the near future errors from process-mail.py will be sent to a log > file not to lp-errors-reports. > > At the moment, in the production launchpad.net, errors from the > process-mail.py cronscript are sent by mail. Previously this only > said anything when the script failed, but as part of the DKIM LEP I > made it emit some debug/info messages. These are now going to an > errors mailing list, which is doubly bad because it creates noise for > people subscribed to the list, while also being hard for me to see the > errors to debug the deployment issues. > > I'm about to file an RT (approved by lifeless) asking the LOSAs to > send output from this cronscript to a file, as is done for some > (most?) of the others.
The other scripts don't emit much noise because they are not being run in verbose mode. If this script is emitting too much, it is self inflicted - in the crontab remove the -v to just get INFO and higher, or run with -q to just get WARNINGS. > Later on we could look at having messages >=error sent to stderr and > everything (including errors) set to a log file, which would help us > converge on having mail sent if and only if there is is a serious > problem. Yes. Because all cronscripts use the same logging setup, we can do this for all scripts at once. It needs to be specified in a bug report so work can be scheduled. It could all be done with command line arguments, or using the cronscript control file work (so -q and -v specify how much noise to emit to stderr, and the cronscript control file specifies what error levels go to which logfiles). -- Stuart Bishop <[email protected]> http://www.stuartbishop.net/ _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
