procmail
[Top] [All Lists]

Re: Coredump on large emails

2001-12-05 08:32:42
Mmailer prog died with signal 11 (core dumped)


From comments that have arisen on this list already a few times over,
for example, the last month (see searchable list archives at procmail.org),
I am led to suspect the reason - though I am not at all sure.

        Odd. I did a search of the archives, and went back about 6 months.
I didn't find enough information in those searchable archives to really
find an answer I thought was appropriate.

My suspicions is that procmail is trying to ingest the entire message,
but that it is too large for the program's cache.  

        I believe I agree.

According to the
similar messages here recently, the solution would then be to use
the i flag, because procmail should not want to care whether it
can read the whole message or not to determine dsuccess as long as it
has found the suspect condition string.

        You mean the :


       i    Ignore any write errors on this recipe (i.e., usually
            due to an early closed pipe).


        I'm not sure what the implications of this are. The message, although
HUGE, is a valid message. It technically has to scan the whole message and
find out that it is a valid message, then deliver to the user.  If I tell
it to ignore a "write error" (Just WHERE is the write error occuring?) what
other issues will I cause?

If I'm misperceiving or misstating the obvious, I'm sure someone
will jump in here to correct my surmisal.

When you come up against baffling problems, your first action should
be to ensure that you are running a log from the .procmailrc and that
you have set it to verbose - and, of course, examined the verbose logs.
This tip also appears in virtually every similar message I can see
over the last month purporting to address write-error issues - or,
for that matter, any issues.

        Been there, done that, know the .procmailrc works for anything
less than about 6Meg.  I looked for "core", since I don't understand what
the "write error" is or how it should be considered acceptable.

                Tuc/TTSG Internet Services, Inc.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail