You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by William Staudenheimer <bs...@sysgu.com> on 2007/03/15 07:31:30 UTC
spamassassin or amavisd : perl gets stuck at/after SA check?
The perl process(es) initiated by amavisd + spamassassin
to handle email(s) are very often running up to 100 percent
of both CPUs, and staying there until killed. Then amavisd (master)
spawns another one or two, which each handle perhaps 10 to 20 emails
before
getting stuck once again.
A perl process gets stuck even when the emails are small, under 3K.
An identical text message sent twice from outside will have one get
stuck,
but the other passes correctly. Similar emails can also take a
long time in the SA Check, but eventually
finish, often showing an SA check of around 30,000 ms, (99%).
Typical last entries in the amavis.log read as:
Mar 12 20:58:58 ns1.xxx.com /usr/bin/amavisd[19428]: (19428-05)
Checking for banned types and filenames
Mar 12 20:58:58 ns1.xxx.com /usr/bin/amavisd[19428]: (19428-05)
p.path: "P=p001,L=1,M=text/plain,T=asc"
and then nothing more, till the process is killed.
It seems that $child_timeout in amavis.conf
is not effective.
This is a lightly loaded machine, OS X Server, 2-CPU's 1 Ghz, 1.25 GB
of ram,
at most 1000 emails per hour.
The programs are nearly vanilla unmodified, as installed by Apple.
What suggestions for where to look next?
Bill
#######################################
Mac OS X Server, 10.4.8
perl 5.8.6
amavisd-new-2.2.0 (20041102) :
spamassassin 3.0.1
clamav is shut off.
Part of amavisd.conf:
$max_servers = 2;
$max_requests = 5;
$child_timeout=2*60;
$sa_mail_body_size_limit = 16*1024;
Part of postfix/master.cf:
smtp inet n - n - 2 smtpd
-o content_filter=smtp-amavis:[127.0.0.1]:10024
#
127.0.0.1:10025 inet n - y - - smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o smtpd_enforce_tls=no
-o strict_rfc821_envelopes=yes
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o receive_override_options=no_header_body_checks
smtp-amavis unix - - y - 2 smtp
-o smtp_data_done_timeout=1200
-o smtp_send_xforward_command=yes
-o disable_dns_lookups=yes
#######################################
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
William L. Staudenheimer bstaud@sysgu.com
System Guides 530-272-4892
www.sysgu.com www.goldcountrysystems.com
Re: spamassassin or amavisd : perl gets stuck at/after SA check?
Posted by William Staudenheimer <bs...@sysgu.com>.
On Mar 15, 2007, at 4:13 AM, Mark Martinec wrote:
>> amavisd-new-2.2.0 (20041102) :
>> spamassassin 3.0.1
>
> That is terribly old, both of them.
To reduce uncertainty, I started by upgrading to current versions
of both of these, with a detour to install
new CPAN.pm version (v1.8802),
and another detour to learn a proper stop and startup:
launchctl load -w /System/Library/LaunchDaemons/
org.amavis.amavisd.plist
launchctl load -w /System/Library/LaunchDaemons/
org.amavis.amavisd.plist
Then, back to work:
amavisd-new-2.4.5 (20070130)
spamassassin version 3.1.8
running on Perl version 5.8.6
But the problem persisted.
Eventually, with the help of your suggestions, I zeroed in on
/var/clamav/.spamassassin/bayes_toks
/var/clamav/.spamassassin/bayes_seen
Unfortunately, the world seems to have moved beyond the
Berkeley DB 1.85 that OS X Server uses, as I was unable
to find and use any related utilities for repairing the bayes_* files,
and upgrading to a new Berkeley DB was getting way out of scope.
So I nuked the bayes_* and started over with an empty corpus.
Things work now, thanks.
Bill
> William,
>
>> The perl process(es) initiated by amavisd + spamassassin
>> to handle email(s) are very often running up to 100 percent
>> of both CPUs, and staying there until killed. Then amavisd (master)
>> spawns another one or two, which each handle perhaps 10 to 20 emails
>> before getting stuck once again.
>>
>> A perl process gets stuck even when the emails are small, under 3K.
>> An identical text message sent twice from outside will have one get
>> stuck, but the other passes correctly. Similar emails can also take
>> a long time in the SA Check, but eventually
>> finish, often showing an SA check of around 30,000 ms, (99%).
>
> Bayes auto-expiry? What version of SA? Any unusual add-on rules?
>
> Turning on SA logging may show where the processing stalls:
> # amavisd debug-sa
>
> Or perhaps running command line spamassassin utility during such
> times may show the same stall in the interactive session:
> # su vscan -c 'spamassassin -t -D <0.msg'
>
>> Typical last entries in the amavis.log read as:
>>
>> Mar 12 20:58:58 ns1.xxx.com /usr/bin/amavisd[19428]: (19428-05)
>> Checking for banned types and filenames
>> Mar 12 20:58:58 ns1.xxx.com /usr/bin/amavisd[19428]: (19428-05)
>> p.path: "P=p001,L=1,M=text/plain,T=asc"
>
> At what log level? At log level 4 the following
> log entry preceeds a call to SA:
> CALLING SA check
>
> so you can tell to what stage the processing has reached.
>
>> and then nothing more, till the process is killed.
>> It seems that $child_timeout in amavis.conf
>> is not effective.
>
> True, $child_timeout is not always effective. There is only one
> alarm timer in Perl, and SA uses it sometimes for its own purposes.
>
>> This is a lightly loaded machine, OS X Server, 2-CPU's 1 Ghz, 1.25 GB
>> of ram, at most 1000 emails per hour.
>> The programs are nearly vanilla unmodified, as installed by Apple.
>>
>> What suggestions for where to look next?
>
>> amavisd-new-2.2.0 (20041102) :
>> spamassassin 3.0.1
>
> That is terribly old, both of them.
>
> Mark
>
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
William L. Staudenheimer bstaud@sysgu.com
System Guides 530-272-4892
www.sysgu.com www.goldcountrysystems.com
Re: spamassassin or amavisd : perl gets stuck at/after SA check?
Posted by Mark Martinec <Ma...@ijs.si>.
William,
> The perl process(es) initiated by amavisd + spamassassin
> to handle email(s) are very often running up to 100 percent
> of both CPUs, and staying there until killed. Then amavisd (master)
> spawns another one or two, which each handle perhaps 10 to 20 emails
> before getting stuck once again.
>
> A perl process gets stuck even when the emails are small, under 3K.
> An identical text message sent twice from outside will have one get
> stuck, but the other passes correctly. Similar emails can also take
> a long time in the SA Check, but eventually
> finish, often showing an SA check of around 30,000 ms, (99%).
Bayes auto-expiry? What version of SA? Any unusual add-on rules?
Turning on SA logging may show where the processing stalls:
# amavisd debug-sa
Or perhaps running command line spamassassin utility during such
times may show the same stall in the interactive session:
# su vscan -c 'spamassassin -t -D <0.msg'
> Typical last entries in the amavis.log read as:
>
> Mar 12 20:58:58 ns1.xxx.com /usr/bin/amavisd[19428]: (19428-05)
> Checking for banned types and filenames
> Mar 12 20:58:58 ns1.xxx.com /usr/bin/amavisd[19428]: (19428-05)
> p.path: "P=p001,L=1,M=text/plain,T=asc"
At what log level? At log level 4 the following
log entry preceeds a call to SA:
CALLING SA check
so you can tell to what stage the processing has reached.
> and then nothing more, till the process is killed.
> It seems that $child_timeout in amavis.conf
> is not effective.
True, $child_timeout is not always effective. There is only one
alarm timer in Perl, and SA uses it sometimes for its own purposes.
> This is a lightly loaded machine, OS X Server, 2-CPU's 1 Ghz, 1.25 GB
> of ram, at most 1000 emails per hour.
> The programs are nearly vanilla unmodified, as installed by Apple.
>
> What suggestions for where to look next?
> amavisd-new-2.2.0 (20041102) :
> spamassassin 3.0.1
That is terribly old, both of them.
Mark