Amavisd routinely fails to correctly tag Spam via SpamAssassin calls

[Mark Martinec via amavis-users]

Quanah,

>>> *ANY* insight into how to debug why Amavis is utterly failing to scan
>>> obvious spam would be much appreciated.
>> 
>> Some interesting bits from the Amavis logs.  There is nothing from:
> 
> This seems to happen with any email where Amavis logs:
> 
> Mar 24 15:53:32 edge01 amavis[41408]: (41408-16) p001 1 Content-Type:
> text/html, size: 6284 B, name:
> 
> Mar 24 15:53:32 edge01 amavis[45326]: (45326-08) p001 1 Content-Type:
> text/html, size: 6293 B, name:
> 
> I.e., it happens specifically on text/html messages with no text/plain 
> part.


> Mar 14 13:31:37 edge02 amavis[35017]: (35017-12) prolong_timer 
> ask_daemon_internal_scan: timer 336, was 10, deadline in 480.0 s
> Mar 14 13:31:37 edge02 amavis[35017]: (35017-12) rw_loop: needline=0, 
> flush=0, wr=0, timeout=335.997
> Mar 14 13:31:37 edge02 amavis[35017]: (35017-12) rw_loop: receiving
> Mar 14 13:31:37 edge02 postfix/smtpd[32533]: disconnect from 
> mx3-in.elmodd.com[208.123.118.136]
> Mar 14 13:31:37 edge02 amavis[38239]: (35017-12) SA dbg: util: setuid: 
> ruid=496 euid=496

This is most weird. Notice the PID change from 35017 to 38239 while 
processing
the 35017-12 task. Looks like an uncontrolled fork has happened.

Are you seeing any crashed perl processes in /var/log/messages - check
for 'exited on signal' there.

Do you have a
   $sa_spawned = 1;
in amavisd.conf?
If not, try turning it on: it makes SpamAssassin run in a forked 
subprocess,
which takes more memory, but isolates catastrophic failures in 
SpamAssassin
from taking down the amavisd process.

What version of SpamAssassin and perl was this?
Is your perl compiled with threads support? ( perl -V | fgrep --color 
ithreads )

   Mark