Hi Earl, Mhonarc gurus,
I apologize for the vagueness in my earlier mail note to the list.
Our system was melting down and I knew I couldn't look at it for
twelve hours, so I was throwing out a quick plea, hoping someone
could divine what I might have done wrong with only the vaguest of
hints. :-) Chris tried to step in to help, but he's never been
exposed to the twisty trails of my mhonarc configuration.
Let the divining begin--Earl wrote:
Do you have a reproducable test case? What do you exactly mean
by "generating indexes continuously for the last half an hour?"
By chance, are you using the OTHERINDEXES resource?
Yes, that was the problem - otherindexes. There is a typeo in
2.5.0:
--- mhopt.pl-orig Tue Nov 13 00:33:35 2001
+++ mhopt.pl Tue Nov 13 00:32:16 2001
@@ -433,7 +433,7 @@ sub get_resources {
unshift(@PerlINC, @array);
}
- @OtherIdx = remove_dups(\(_at_)OtherIdxs);
+ @OtherIdxs = remove_dups(\(_at_)OtherIdxs);
@PerlINC = remove_dups(\(_at_)PerlINC);
## Require mail parsing library
Very naughty little typeo there. Every time I added a new message
to an archive, every one of my OTHERINDEXES were added to the
.mhonarc.db's OtherIdxs list. By the time we noticed the system
was hosed, some lists like gcc-patches were generating some 70
copies of all four of its indexes. And there were ~800 messages
in each of those indexes. It makes me shudder just to think of
the horror. :-)
FWIW this has nothing to do with my fancy configuration; even the
simplest use of an -otherindex will reproduce the problem. It's
a clever bug because you think your 2.5.0 install went correctly
after some minimal testing (because it's only regenerating the
indexes a few times) -- it's a day or two later when the full effect
starts to hit you, and it's not at all obvious what's going wrong.
For us, we started to see these mhonarc's sitting around, waiting
for locks to open up and timing out after a long wait.
Anyway, thanks for all the help, I'm off to attempt some cleanup
before going to bed..
Jason
