[Exim] Exim 3.34 assertion failure--LDAP related [followup]

Pàgina inicial
Delete this message
Reply to this message
Autor: Tommy Lacroix
Data:  
A: exim-users
Assumpte: [Exim] Exim 3.34 assertion failure--LDAP related [followup]
Hi,

I'm following up on that problem. It doesn't seem to have the same
undetermined cause (duh), but still, the error message is the same.

I am able to reproduce the same problem with the same config on Exim 3.34,
3.35 and 3.36.

It seems to happen after direction, and before or during transport. Here's
the "exim -q -v" output".

    == something@??? T=remote_smtp defer (-44): retry time not
reached for any host
  delivering message 17Aynk-0007py-00 (queue run pid 1114 fd 6)
  LOG: 0 MAIN
    => runtime <runtime@???> D=ldapuser T=quota_delivery
  exim: error.c:221: ldap_parse_result: Assertion `r != ((void *)0)' failed.
  LOG: 0 MAIN PANIC
    queue run: process 1127 crashed with signal 6 while delivering
17Aynk-0007py-00
  delivering message 17AvDk-000822-00 (queue run pid 1114 fd 6)


The quota_delivery transport is configured as:
ldap_default_servers = server1:server2
...
quota_delivery:
driver = appendfile
maildir_format = true
directory = ${lookup ldap {user="binduser" pass="bindpass"
ldap:///basedn?mailMessageStore?sub?(uid=${quote_ldap:$local_part})}{$value}
fail}
delivery_date_add
envelope_to_add
maildir_tag = ,S=$message_size
quota_size_regex = S=(\d+)$
directory = ${lookup ldap {user="binduser" pass="bindpass"
ldap:///basedn?uidNumber?sub?(uid=${quote_ldap:$local_part})}{$value}fail}
group = users
mode = 0600
quota = 20M
quota_warn_threshold = 16M

There is 2 LDAP lookups. One for the maildir, and one for the UID (nssldap
isn't installed). Statisticaly, 100% of the logged accounts triggering the
error have both fields defined and valid in the LDAP DB. Moreover, the error
seems to be quite random but happens very often. Issuing
"exim -qf -Rruntime@??? -v" will end up working after a couple of tries.

The director's is doing an LDAP lookup as well (in the "search_type/query"
form) but never fails.

Below's the end of the original thread for a similar problem.

Wed, 13 Mar 2002 11:07:32 +0000 (GMT)
JWB>> Let's assume that
JWB>> Some exim process (perhaps 13321, perhaps not) made the LDAP query

which
JWB>> caused the LDAP library to emit the assertion. That leaves Exim

merely as
JWB>> the trigger mechanism, and not the problem.


PH> Indeed, but of course something wrong in Exim could be making it pull
PH> the trigger. However, unless it happens again, I guess it has to go into
PH> the "unresolved mysteries" pile.



Any idea?

Regards,
__
Tommy Lacroix ( runtime@??? )
Unix/Linux System Administrator, CAM Internet
Web: http://www.cam.org
Tel: +1 514 529-3000 ext 247
Fax: +1 514 529-3300