Bug 162910 - sendmail and nss_ldap hangs during getpwent
sendmail and nss_ldap hangs during getpwent
Product: Fedora
Classification: Fedora
Component: nss_ldap (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Depends On:
  Show dependency treegraph
Reported: 2005-07-11 12:23 EDT by Alain RICHARD
Modified: 2008-02-17 21:33 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-17 21:33:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alain RICHARD 2005-07-11 12:23:05 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; fr-fr) AppleWebKit/412 (KHTML, like Gecko) Safari/412

Description of problem:
On my setup (sendmail + nss_ldap + cyrus-imapd), I am experiencing hangs during sendmail delivery 
to the cyrus agent.

After tracing, I have discovered that sendmail is hung during a getpwent during the MatchGECOS. In 
fact sendmail is hung just after looking at the local /etc/passwd information and just before getting the 
first ldap entry from nss_ldap (it waits forever for results from ldap server).

killing the sendmail process and restarting it deliver correctly the email from  the mailqueue to cyrus-

The ldap servers are on other servers (two ldap servers).

The nscd process is disabled because running it seams to hang saslauthd process needed by cyrus-
imapd. The same problem is present if nscd is running.

Looking at the gdb stacktrace, I have found that the process is hung in nss do_result waiting without 
timeout to results from the server. 

A simple workaround for me is to add "timelimit 30" to the /etc/ldap.conf file.

Version-Release number of selected component (if applicable):
sendmail-8.13.4-2 nss_ldap-234-4 glibc-2.3.5-10

How reproducible:

Steps to Reproduce:
1.mail -s test somelocaluser@thelocaldomain.com

Actual Results:  sendmail delivers the mail to cyrus-imap by putting it in the mailqueue and triggering a new sendmail 
process to deliver it. This new sendmail process hangs and never delivers the email to cyrus-imapd and 
waits forever on nss_ldap for results.

Expected Results:  the email should be delivered to cyrus-imapd.

Additional info:

bt of the hung process :

(gdb) bt
#0  0x00111402 in ?? ()
#1  0x0034f47d in ?? () from /lib/libc.so.6
#2  0x00ef1014 in ldap_int_select () from /lib/libnss_ldap.so.2
#3  0x00ee33ff in ldap_result () from /lib/libnss_ldap.so.2
#4  0x00ed76a6 in do_result (ctx=0xa007940, all=0) at ldap-nss.c:2154
#5  0x00ed78e0 in _nss_ldap_ent_context_init_locked (pctx=0x1142920) at ldap-nss.c:1836
#6  0x00ed9176 in _nss_ldap_ent_context_init (pctx=0xfffffdfe) at ldap-nss.c:1792
#7  0x00ed9632 in _nss_ldap_setpwent () at ldap-pwd.c:244
#8  0x0036802a in __nss_getent_r (getent_func_name=0x3a5c2a "getpwent_r", 
setent_func_name=0x3a5c18 "setpwent", 
    lookup_fct=0x368c04 <*__GI___nss_passwd_lookup>, nip=0x3b40c8, startp=0x3b40c0, 
last_nip=0x3b40c4, stayopen_tmp=0x0, res=0, resbuf=0x3b4050, 
    buffer=0xa0069c8 "nut", buflen=1024, result=0xbf84d0cc, h_errnop=0x0) at getnssent_r.c:203
#9  0x00317c77 in __getpwent_r (resbuf=0xfffffdfe, buffer=0xfffffdfe <Address 0xfffffdfe out of 
bounds>, buflen=4294966782, result=0xfffffdfe)
    at ../nss/getXXent_r.c:161
#10 0x00367cea in __nss_getent (func=0x317bd0 <__getpwent_r>, resbuf=0x3b4050, 
buffer=0x3b30a8, buflen=1024, buffer_size=0x3b406c, h_errnop=0x0)
    at getnssent.c:36
#11 0x003177af in getpwent () at ../nss/getXXent.c:84
#12 0x00500b6f in finduser (name=0xbf84f4c7 "alain richard", fuzzyp=0xbf84f5c8, 
user=0xbf84d2bc) at recipient.c:1212
#13 0x00502375 in recipient (new=0x9ff2954, sendq=0xbf851020, aliaslevel=0, e=0xbf850fa0) at 
#14 0x004f49b8 in readqf (e=0xbf850fa0, openonly=0) at queue.c:4387
#15 0x004f7009 in doworklist (el=0x554cc0, forkflag=1, requeueflag=1) at queue.c:3834
#16 0x00510638 in smtp (nullserver=0x0, d_flags=0x55c2b0, e=0x554cc0) at srvrsmtp.c:3510
#17 0x004a6fff in main (argc=3, argv=0xbf854c4c, envp=0xfffffdfe) at main.c:2587
Comment 1 Peter Svensson 2006-04-15 06:25:46 EDT
The ldap client in nss_ldap seems to share the socket across forks. This can
cause one client process to steal the answer from another, thus leaving it
waiting forever for an answer that will never be received.

This bug is probably related to one of the bugs concering nss_ldap across forks.
The ldap socket is supposed to be closed on fork. It is evident from the output
of lsof that this is not always done.
Comment 2 Christian Iseli 2007-01-22 05:18:16 EST
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Comment 3 petrosyan 2008-02-17 21:33:39 EST
Fedora Core 4 is no longer maintained.

Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the
current Fedora release, please reopen this bug and assign it to the
corresponding Fedora version.

Note You need to log in before you can comment on or make changes to this bug.