Jason Haar <Jason(_dot_)Haar(_at_)trimble(_dot_)co(_dot_)nz> writes:
...
Is this considered a bug? What would /bin/mail have done with the message?
As /bin/mail wouldn't had to process anything, I'd say it may just start
writing to /var/spool/.... Procmail by definition does more than that so
you've got to be careful.
All the versions of /bin/mail (or mail.local) that I've seen the source
for either read the entire message into memory first or use a temp
file. Depending on where temp files are located, a 90MB temp file may
be just as bad as holding it in memory.
Did the MTA do a bounce of any kind?
Nope - I invoke procmail with the "-Y" option, so the message was just
The -Y flag has nothing to do with the lack of a bounce. Since procmail
never returned an error code to sendmail, sendmail didn't have a chance
to remove the message from the queue.
requeued - so after the reboot I manually stopped sendmail and moved the
message out of the queue - and dealt to it with vi.
I guess that's my point, a human plus vi could do more efficiently than
procmail could (wow, a human's more useful than a program ;-))
If you total up the total amount of time procmail has saved you, and
subtract the reboot+vi time, is it positive or negative?
Anyway, I would say the problem is that your OS/libc has a bad failure
mode during low-memory operation. I can think of one way procmail
could have helped things*, but the step after that is to use a temp
file. If you want that, you'll need to switch mailers, as I would
guess that procmail will never directly support tempfile operation.
There are ways to automate the calling of procmail on non-gargantuan
message, but at some point you have to ask whether you're using the
wrong tool for the problem.
* procmail's memory allocation technique appears to non-optimal for
some OS/libc combos (FreeBSD has been reported). It's _conceivable_
that the configuration process could be enhanced to detect this system
limitation to use a strategy more efficient on them. Don't hold your
breath.
Philip Guenther