Amavisd routinely fails to correctly tag Spam via SpamAssassin calls

[Mark Martinec via amavis-users]

>> 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.

Actually the change of PID in the 'SA dbg: util: setuid:' is normal,
it happens in Mail::SpamAssassin::Util::helper_app_pipe_open_unix
when preparing to launch (exec) some external program (like dcc, pyzor),
just after a fork.

What is strange is the missing log entries of task 35017-12 before
and after that SA dbg log entry.

> 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.

Worth a try.

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

   Mark