launchpad-dev team mailing list archive

[Stuart Bishop <stuart.bishop@xxxxxxxxxxxxx>]

On Thu, Sep 16, 2010 at 7:10 AM, Martin Pool <mbp@xxxxxxxxxxxxx> 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 <stuart@xxxxxxxxxxxxxxxx>
http://www.stuartbishop.net/