Bug 1697 - spamc fails to dump message when running out of memory
Summary: spamc fails to dump message when running out of memory
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamc/spamd (show other bugs)
Version: 2.52
Hardware: Other Linux
: P3 critical
Target Milestone: 2.53
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords: backport
Depends on:
Blocks:
 
Reported: 2003-03-27 12:20 UTC by Dirk Mueller
Modified: 2003-03-27 07:23 UTC (History)
1 user (show)



Attachment Type Modified Status Actions Submitter/CLA Status
patch to ensure that message is dumped to stdout even if running out of memory. patch None Dirk Mueller [NoCLA]
reworked patch, with additional doco patch None Justin Mason [HasCLA]

Note You need to log in before you can comment on or make changes to this bug.
Description Dirk Mueller 2003-03-27 12:20:48 UTC
I'm running spamc as a mail filter. in low memory conditions, spamc fails 
to dump the message to stdout. as "fail safe" mode is default now, spamc 
exited with an error code of 0, which made the filter proceed. We've lost 
a lot of mails due to that error, as the spamc filter "deleted" the complete 
message body. Therefore raising severity to critical.  
 
Now, the cause is a small glitch in message_filter, I'll append a patch. with  
this patch, I was unable to trigger the condition that it exists without being 
able to dump the message to stdout. However, its still possible, as various 
memory allocations can fail in several places, setting the return value 
to EX_OSERR. I was unable to trigger this case after applying my patch though.  
 
Unfortunately, the "fail safe" mode is default, so in this case the message 
queue filter will continue with whatever was printed to stdout as message body, which  
can be an empty message in the worst case.  
 
It would be good if the man page would describe and recommend the currently 
undocumented parameter -x to spamc to implement the more sane error handling 
method of tempfailing the processing, instead of just continuing.  
 
Please apply the patch I append in a minute, it makes mail-filtering a lot more robust when 
spamc runs out of memory while trying to filter the message.
Comment 1 Dirk Mueller 2003-03-27 12:21:45 UTC
Created attachment 821 [details]
patch to ensure that message is dumped to stdout even if running out of memory.
Comment 2 Justin Mason 2003-03-27 13:26:41 UTC
OK, sounds reasonable.  I've rewritten your patch, since it collides with
another patch on the first chunk (which is not changed anyway, just some
formatting).
Comment 3 Justin Mason 2003-03-27 13:27:28 UTC
Created attachment 825 [details]
reworked patch, with additional doco
Comment 4 Dirk Mueller 2003-03-27 13:38:37 UTC
thanks.  
 
note the docu is slightly inaccurate. it won't always return error code 75 currently.  
instead it will return one of the EX_* constants defined. for example in our case where 
it runs into an ulimit during mail processing, it will exit with EX_OSERR, code 71.  
 
maybe it should say "non-zero exit code" and list the possible cases, as quoted from 
spamd.raw: 
 
  EX_USAGE       => 64, # command line usage error 
  EX_DATAERR     => 65, # data format error 
  EX_NOINPUT     => 66, # cannot open input 
  EX_NOUSER      => 67, # addressee unknown 
  EX_NOHOST      => 68, # host name unknown 
  EX_UNAVAILABLE => 69, # service unavailable 
  EX_SOFTWARE    => 70, # internal software error 
  EX_OSERR       => 71, # system error (e.g., can't fork) 
  EX_OSFILE      => 72, # critical OS file missing 
  EX_CANTCREAT   => 73, # can't create (user) output file 
  EX_IOERR       => 74, # input/output error 
  EX_TEMPFAIL    => 75, # temp failure; user is invited to retry 
  EX_PROTOCOL    => 76, # remote error in protocol 
  EX_NOPERM      => 77, # permission denied 
  EX_CONFIG      => 78, # configuration error 
 
Comment 5 Theo Van Dinter 2003-03-27 13:48:34 UTC
OKAY: new patch looks good
Comment 6 Justin Mason 2003-03-27 16:15:37 UTC
ok -- applied -- and I included those constants in the doco too.
Comment 7 Dirk Mueller 2003-03-27 16:23:49 UTC
thx!