mailman queue cleared (was: Re: email to root?)
Steve Traugott <stevegt <at> TerraLuna.Org>
2006-12-12 00:07:36 GMT
Sorry for the deja vu. Mailman was barfing on a corrupt python
pickle file, causing 12,000 spam messages to pile up in the admin
queue. While clearing that, I got a little over-conservative and let
this ancient message from Adam through as well.
All should be well now -- if anyone's sent anything to the list in the
last couple months and you didn't see it come through, let me know in
the next few days and I'll dig it out before the queue backups
On Mon, Mar 21, 2005 at 12:59:46PM -0500, Adam S. Moskowitz wrote:
> Vincent McIntyre <Vince.McIntyre <at> atnf.csiro.au> asked:
> > What, if anything, are people doing with mail that traditionally goes
> > to the 'root' account on the box?
> and John Borwick <borwicjh <at> wfu.edu> replied:
> > You must read (or parse) all this mail. . . .
> Yes, BUT . . .
> Vincent McIntyre <Vince.McIntyre <at> atnf.csiro.au> again:
> > Is it our doom to die of boredom from reading endless near-identical
> > emails from cron jobs? Say it ain't so!
> I think a better answer is to reduce the amount of mail being delivered.
> Why are routine cron jobs sending email if the job works as expected?
> What benefit does this provide?
> I have implemented schemes something like this: All routine cron jobs
> dump their output in a file in a directory somewhere; the first line of
> the file contains an easily-parsed status line indicating whether the
> job worked as expected, worked with minor problems, failed, etc. A
> single cron job runs after the expected completion time of all other
> cron jobs, parses the various crontab files just enough to know how many
> jobs should have run, looks for and parses the output files, and sends a
> *SINGLE* message (per machine if there aren't very many, or per cluster
> if there are lots of identical nodes) with a subject line something like
> Subject: cron jobs: # ok, # not ok, # missing
> The body of the message contains some additional information, maybe even
> the full output file from each job that failed (or that could be sent as
> a separate message by the "aggregator" job). The mail program is
> configured to make it obvious which node sent any given message ("From:
> root <at> nodeN").
> When you read your mail in the morning, you sort by sender and then scan
> for any messages that are worth reading.
> I could have used a scheme so that no messages would be sent if
> everything worked but I like this better in that it lets me see that
> things are running as expected. If you cared you could post-process your
> inbox and send yourself a message warning you if you didn't get the
> expected number of summary messages on any given day.
> So yes, you still need to read every message (or at least look at the
> subject line) -- but when this is down to ~10 messages a day no matter
> how many machines you have, well, that's really not a big deal.
> No, I can't give you the code to do this: It was highly-customized for
> each place I did it, and I didn't even think to save it when I left --
> but it didn't take me moew than a day or two to knock out the frame-
> work and then just the odd tweak now and then as outputs changed, etc.
> (Yes, I've more-or-less described an asynchronous, email-based version
> of Big Brother.
> Infrastructures mailing list
> Infrastructures <at> mailman.terraluna.org
Stephen G. Traugott (KG6HDQ)
Managing Partner, TerraLuna LLC
stevegt <at> TerraLuna.Org -- http://www.t7a.org