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
