amavis ldap trouble in process_request do_search

Quanah Gibson-Mount quanah at zimbra.com
Thu Apr 4 19:29:40 CEST 2013


--On Thursday, April 04, 2013 3:02 PM +0200 frank.kaiser at ewetel.net wrote:

>
>
>> The client side - amavis - doesn't give enough information. Have you
>> had a look at the LDAP server > log? It _could_ be a query size
>> limit, just to add some speculation ;)
>
> Hm in the cases when amavis failed i cant find eny logentries in ldap.log.
>
> here are the LDAP limits
>
> dn: cn=config
> changetype: modify
> replace: olcSizeLimit
> olcSizeLimit: size.unchecked=1000
> -
> replace: olcSockbufMaxIncoming
> olcSockbufMaxIncoming: 500000
> -
> replace: olcThreads
> olcThreads: 25
> -
> replace: olcTimeLimit
> olcTimeLimit: 120
> -
> replace: olcSockbufMaxIncomingAuth
> olcSockbufMaxIncomingAuth: 5000000

I think before you randomly change settings, you should have a clue as to 
what they do.

olcThreads -- The threads setting in OpenLDAP should never be more than 4x 
the number of real cores.  It should always be an even number.  The default 
is 8.  25/4 is not even.  I've rarely seen a case to go higher than 16, and 
that is only on servers that server thousands of clients simultaneously. 
If you have a threads setting that is not compatible with the number of 
cores your system actually has, then you can case severe deadlock issues.

olcSockbufMaxIncoming -- You should not be changing this from the default.

olcSockbufMaxIncomingAuth -- You should not be changing this from the 
default.

olcTimeLimit -- Unless you see *clear* evidence from slapd (via 
olcLogLevel: 256) that the server is terminating connections due to 
timelimits, you should not be changing from the default.

olcSizeLimit -- Unless you see *clear* evidence from slapd (via 
olcLogLevel: 256) that the server is terminating connections due to 
sizelimits, you should not be changing the default.

Randomly changing settings without understanding the effect that will have 
is never, ever a good idea.


I would also note that there is a bug in Amavis on how it handles failure 
in the case that the connection between it and the LDAP server is 
terminated by a packet shaper or firewall.  If you have one of those 
between your MTA and the LDAP server, this is likely the cause of the 
issue.  In any case, as Patrick already noted, you need to get logs from 
the LDAP *server* as to why the connections between amavis and the LDAP 
server are being terminated.

Hope that helps,
Quanah




--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration


More information about the amavis-users mailing list