Prev: recipient_bcc_maps
Next: clamav with master.cf/main.cf
From: Charles Account on 29 Apr 2010 09:53

Hi,
We have a situation where LDAP query is resulting in a LDAP 80 level errorduring a domain lookup. Yes I understand we need to fix this problem.
However, the side effect we see is the client's SMTP session hangs. Over a period of time all SMTPD sessions are consumed and no mail is processed.The only solution was to stop postfix and restart to free up the processes.
I was able to track it down to resolve_clnt.c for loop were it continuouslykeeps trying until a non LDAP level error is returned. Even if the client MTA connection has been closed, the smtpd process continues toretry after 1 second sleep, thus, consuming LDAP resources. I suspect it continues until the process time to live has exceeded but I didn't let itrun to see if the smtpd process would die.
I have looked for a patch but I have not found one. Does one exist?
Any help is greatly appreciated,
Charles
_________________________________________________________________
Hotmail is redefining busy with tools for the New Busy. Get more from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2
From: Kenneth Marshall on 29 Apr 2010 10:00
On Thu, Apr 29, 2010 at 01:53:37PM +0000, Charles Account wrote:
>
> Hi,
> We have a situation where LDAP query is resulting in a LDAP 80 level errorduring a domain lookup. Yes I understand we need to fix this problem.
> However, the side effect we see is the client's SMTP session hangs. Over a period of time all SMTPD sessions are consumed and no mail is processed.The only solution was to stop postfix and restart to free up the processes.
> I was able to track it down to resolve_clnt.c for loop were it continuouslykeeps trying until a non LDAP level error is returned. Even if the client MTA connection has been closed, the smtpd process continues toretry after 1 second sleep, thus, consuming LDAP resources. I suspect it continues until the process time to live has exceeded but I didn't let itrun to see if the smtpd process would die.
> I have looked for a patch but I have not found one. Does one exist?
> Any help is greatly appreciated,
> Charles

You LDAP service is broken. Until that is fixed, I would recommend a
nanny script to restart postfix until that happens. Otherwise you will
need to front the broken server with another service that will clean-up
for you on the LDAP side. Good luck. It is much easier to fix the broken
directory service than re-start properly functioning software.

Regards,
Ken

From: Victor Duchovni on 30 Apr 2010 01:04
On Thu, Apr 29, 2010 at 01:53:37PM +0000, Charles Account wrote:

> We have a situation where LDAP query is resulting in a LDAP 80 level
> errorduring a domain lookup. Yes I understand we need to fix this problem.

I've mentioned a number of times on this list that it is unwise to
make the trivial-rewrite service dependent on LDAP or other services
that may not always be reliable.

Postfix cannot continue to function when

address -> (transport, nexthop, normalized-address)

lookups fail, there is no sensible recovery path. The lookups must
loop until the transport table works again.

DO NOT use potentially unreliable LDAP sources for the following tables:

- transport_maps
- mydestination
- relay_domains
- virtual_mailbox_domains
- virtual_alias_domains
- relocated_maps
- sender_dependent_relayhost_maps
- sender_dependent_default_transport_maps

> However, the side effect we see is the client's SMTP session hangs.
> Over a period of time all SMTPD sessions are consumed and no mail is
> processed.The only solution was to stop postfix and restart to free up
> the processes.

No mail can be processed anyway, as the queue manager is completely
unable to function when transport resolution is down.

> I have looked for a patch but I have not found one. Does one exist?

No patch exists, as this is not a bug. Transport lookups MUST work.
If LDAP is not reliable, don't use LDAP.

--
Viktor.

P.S. Morgan Stanley is looking for a New York City based, Senior Unix
system/email administrator to architect and sustain our perimeter email
environment. If you are interested, please drop me a note.

 | 
Pages: 1
Prev: recipient_bcc_maps
Next: clamav with master.cf/main.cf