On Fri, Jan 07, 2005 at 11:08:58PM -0700, Justin Gombos wrote:
I have a really irritating complex problem, and I doubt anyone can
solve it, but I'll post anyway -- just in case.
Nothing is impossible to solve. You simply need a surgical,
diagnostic approach.
You've been reading along here recently, right? Somebody I
can't quite place whose initials are DR has been saying quite
a bit lately to some other bloke: "What do the (verbose) logs
say?"
The verbose logs are the best way to diagnose an "irritating[,]
complex problem." Period. All the hand-waving and descriptions
with English words are not as useful and tend to leave out clues.
Inbound mail from this procmail list is getting munged such that the
string "Subject:" is getting replaced with a space. But this doesn't
happen all the time, just most of the time. It seems the anomaly does
Do you have any recipe or any call to an outside script or resource
that munges headers? What about your TOFU thing described elsewhere?
At the same time this problem began, messages from the wget mailing
list also began losing the "subject:" header, but are then dumped in a
folder called "Segmentation," instead of wget_2005 (procmail messages
are correctly dumped in procmail_2005). I never defined a folder to
be called segmentation, so procmail is seriously screwing things up.
I doubt it is procmail screwing things up. "segmentation" is a
suspicious word around operating systems. It usually has to do with
the phrase, "segmentation fault." (Do you have a second file called
"fault"?) Some program is barfing.
There is no reason for procmail to have this problem in isolation,
because the sole script that processes my procmail mail is generalized
and processes other mailing lists (which don't have this problem):
Well, then it's obviously something else. What recipes touch your
procmail list mail?
And wget is another class of lists that is not a "Beenthere" list, and
has its problem in isolation from the other lists of its class.
Do any of the recipes that procmail list mail is evaluated by touch
those list messages, too?
My library of scripts is very large. This problem is impossible to
troubleshoot, because when I process one message at a time and watch
the log files, all goes well. As soon as a batch of messages go to
procmail, messages from the procmail list and wget list are hosed.
Why should that miake it impossible to troubleshoot? You can process
multiple messages. use "formail -s" or put a test set of messages
somewhere wget can repeatedly try. Use flags to keep the test
messages from being deleted on the source server. (Or take away
write privs and wget won't be able to delete them.) :)
The logs are impossible to follow because the output is all out of
sequence. To keep things thoroughly confusing, I'm running two
processors with the symmetrical multiprocessor kernel.
Write a new log file for testing only.
:0
* DIAGS ?? .
{ LOGFILE = diags.`date +%y%m%d` }
Turn on DIAGS on the command line when you test procmail or
temporarily in an rcfile you're using.
--
dman
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail