launchpad-dev team mailing list archive

[Tom Haddon <tom.haddon@xxxxxxxxxxxxx>]

On Thu, 2010-09-16 at 12:19 +1000, Martin Pool wrote:
> On 16 September 2010 11:57, Stuart Bishop <stuart.bishop@xxxxxxxxxxxxx> wrote:
> > 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.
> 
> Uh, ok, but I actually do want the debug output, I just don't want it
> sent by mail.

I think these are two slightly separate thoughts, both valid. I agree
that it'd be great as a matter of policy to have all output for all
cronscripts sent to log files, and only have stderr output emailed. 

> I think we should actually log everything to disk all the time, unless
> that's generating a truly unreasonable amount of data.

This is where we get into the question of how much to log (i.e. -q, -v,
etc.)

> >> 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).
> 
> <https://bugs.edge.launchpad.net/launchpad-foundations/+bug/640125>
>