[prev in list] [next in list] [prev in thread] [next in thread] 

List:       amavis-user
Subject:    Re: [AMaViS-user] slow SA checks, sa_timeout
From:       "Alexander 'Leo' Bergolth" <leo () strike ! wu-wien ! ac ! at>
Date:       2007-03-28 15:37:53
Message-ID: 460A8BD1.60404 () strike ! wu-wien ! ac ! at
[Download RAW message or body]

On 03/28/2007 04:51 PM, Mark Martinec wrote:
>> I've noticed that in my postfix before-queue (smtpd_proxy_filter) setup,
>> some connections to amavis terminate after 100 seconds with timeouts
>> (according to postfix' smtpd_proxy_timeout), even though amavisd's
>> sa_timeout should be at the default value of 30 seconds. (It's not set
>> in the config-file.) See the attached log for an example.
>> Any idea why sa_timeout doesn't work sometimes?
>> P.S.: I'm using amavisd-new 2.5.0-pre3.
> 
> Since 2.4.0 it is no longer a simple 30 seconds default:

Oh - looks like I missed that...

> amavisd-new-2.4.0 release notes
> 
> - [...] allowed time is calculated as 2/3 of the remaining time
>   (initially at $child_timeout), but at least 10 seconds;
> 
> - use the same timeout calculation as above for calls to SA, taking
>   $sa_timeout instead if that value is bigger than the calculated time,
>   thus making $sa_timeout pretty much redundant;

Hmm - that's bad.
I have $child_timeout set to 20 min (20*60) because in a before-queue
setup, it may take quite a long time till all the data is transferred
over the net.

But smtpd_proxy_timeout is at the default 100 sec, so after all data is
transferred, amavisd has 100 seconds to complete.
http://thread.gmane.org/gmane.mail.postfix.user/97919/focus=98038

So it sometimes would make sense to set $sa_timeout _lower_ than that
calculated time.

>> Does Spamassassin reset the SIGALRM timeout for it's own purposes?
> 
> Yes, sometimes it does, so the timeout as prepared by amavisd
> is not necessarily enforced.
> 
> You may try:
>   $sa_spawned = 1;
>     # true: run SA in a subprocess;  false: call SA directly
> 
> this will decouple timeouts between amavisd and SA,
> amavisd will kill a forked SA after its timeout expires.

OK, thanks.

>> Do you have a hint how to debug where Spamassassin hangs?
> 
> If a hang can be repeated by passing the same message through
> a command-line spamassassin, that is the best method:
>   su vscan -c 'spamassassin -D -t <0.msg'
> 
> Otherwise I can only recommend to run with $sa_debug turned on
> (or: amavisd debug-sa), perhaps redirecting its logging to a file.
> 
> Adding timestamps to each line may be useful:
> 
>   amavisd debug-sa 2>&1 | timestamp
> 
> 
> where timestamp is a function in my .bashrc :
> 
>   function timestamp()
>   { perl -MPOSIX -MTime::HiRes -n -e '
>       BEGIN {$|=1; $dp=0; $t0=Time::HiRes::time};
>       $t=Time::HiRes::time; $dt=$t-$t0; printf("%s%06.3f %4.3f %4.3f %s",
>         POSIX::strftime("%H:%M:",localtime($t)), $t-int($t/60)*60,
>         $dt, $dt-$dp, $_); $dp=$dt' $*
>   }

Good hint, thanks!

--leo
-- 
-----------------------------------------------------------------------
Alexander.Bergolth@wu-wien.ac.at                Fax: +43-1-31336-906050
Zentrum fuer Informatikdienste - Wirtschaftsuniversitaet Wien - Austria


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
AMaViS-user mailing list
AMaViS-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/
[prev in list] [next in list] [prev in thread] [next in thread]