https://bugzilla.novell.com/show_bug.cgi?id=742843 https://bugzilla.novell.com/show_bug.cgi?id=742843#c Dirk Mueller <dmueller@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bnc-team-screening@forge.pr |aj@suse.com |ovo.novell.com | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=742843 https://bugzilla.novell.com/show_bug.cgi?id=742843#c2 Joerg Steffens <joerg.steffens@dass-it.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|joerg.steffens@dass-it.de | --- Comment #2 from Joerg Steffens <joerg.steffens@dass-it.de> 2012-01-24 21:11:19 UTC --- We reproduced it here today with a freshly, default installed openSUSE 12.1. The problem does not occur, if nss_ldap is not installed. As soon as nss_ldap is installed, a newly executed "getent --service=ldap passwd" hangs. Please ignore the typos from my first message. I know, its "--service" -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=742843 https://bugzilla.novell.com/show_bug.cgi?id=742843#c4 Ralf Haferkamp <rhafer@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #4 from Ralf Haferkamp <rhafer@suse.com> 2012-01-31 16:19:59 CET --- (In reply to comment #3)

Ralf, is nss_ldap not noticing that there is no ldap server running and just never timeout? No. This is a well known "problem".

When --service=ldap is used getent will also try to resolve the hostname of the ldap server via LDAP (because nss_ldap supports the NSS "hosts" database as well). In the end nss_ldap runs into a deadlock because every call into nss_ldap is protected by a lock to avoid threading issues (libldap isn't really thread-safe). When trying to resolve the hostname the process tries to aquire the lock it already holds and ends up in a deadlock. Here's a backtrace of what happens: #0 __lll_lock_wait () at ./nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:132 #1 0x00007f2247b231c5 in _L_lock_883 () from /lib64/libpthread.so.0 #2 0x00007f2247b2301a in __pthread_mutex_lock (mutex=0x7f2249f43580) at pthread_mutex_lock.c:61 #3 0x00007f2249d33fa8 in _nss_ldap_enter () at ldap-nss.c:580 #4 0x00007f2249d35b4f in _nss_ldap_getbyname (args=0x7fffa8617830, result=0x7fffa86179c0, buffer=0x614720 "", buflen=992, errnop=0x7f224a4e06a8, filterprot=<optimized out>, sel=LM_HOSTS, parser=0x7f2249d38570 <_nss_ldap_parse_hostv4>) at ldap-nss.c:3512 #5 0x00007f2249d3861a in _nss_ldap_gethostbyname2_r (name=<optimized out>, af=<optimized out>, result=<optimized out>, buffer=<optimized out>, buflen=<optimized out>, errnop=<optimized out>, h_errnop=0x7fffa86179fc) at ldap-hosts.c:287 #6 0x00007f2249d386c6 in _nss_ldap_gethostbyname_r (name=0x7fffa8617a00 "marvin", result=0x7fffa86179c0, buffer=0x614720 "", buflen=992, errnop=0x7f224a4e06a8, h_errnop=0x7fffa86179fc) at ldap-hosts.c:310 #7 0x00007f224a03ff8d in __gethostbyname_r (name=0x7fffa8617a00 "marvin", resbuf=0x7fffa86179c0, buffer=0x614720 "", buflen=992, result=0x7fffa86179f0, h_errnop=0x7fffa86179fc) at ../nss/getXXbyYY_r.c:256 #8 0x00007f2249b100c2 in ldap_pvt_gethostbyname_a () from /usr/lib64/libldap-2.4.so.2 #9 0x00007f2249b1022d in ldap_pvt_get_fqdn () from /usr/lib64/libldap-2.4.so.2 #10 0x00007f2249b0e64b in ldap_int_initialize () from /usr/lib64/libldap-2.4.so.2 #11 0x00007f2249b0f1c9 in ldap_set_option () from /usr/lib64/libldap-2.4.so.2 #12 0x00007f2249d32a35 in do_init () at ldap-nss.c:1322 #13 0x00007f2249d347ff in _nss_ldap_search (args=0x0, filterprot=0x7f2249f4ddc0 "(objectClass=posixAccount)", sel=<optimized out>, user_attrs=0x0, sizelimit=0, msgid=0x7fffa861945c, csd=0x612ef8) at ldap-nss.c:3193 #14 0x00007f2249d34b58 in _nss_ldap_getent_ex (args=0x0, ctx=0x7f2249f44688, result=0x7f224a2dae40, buffer=0x612f20 "\030\237-J\"\177", buflen=1024, errnop=0x7f224a4e06a8, filterprot=0x7f2249f4ddc0 "(objectClass=posixAccount)", sel=LM_PASSWD, user_attrs=0x0, parser=0x7f2249d35f20 <_nss_ldap_parse_pw>) at ldap-nss.c:3433 #15 0x00007f2249d34c9e in _nss_ldap_getent (ctx=0x7f2249f44688, result=0x7f224a2dae40, buffer=0x612f20 "\030\237-J\"\177", buflen=1024, errnop=0x7f224a4e06a8, filterprot=0x7f2249f4ddc0 "(objectClass=posixAccount)", sel=LM_PASSWD, parser=0x7f2249d35f20 <_nss_ldap_parse_pw>) at ldap-nss.c:3380 #16 0x00007f2249d36376 in _nss_ldap_getpwent_r (result=<optimized out>, buffer=<optimized out>, buflen=<optimized out>, errnop=<optimized out>) at ldap-pwd.c:327 #17 0x00007f224a039b62 in __nss_getent_r (getent_func_name=0x7f224a09afa6 "getpwent_r", setent_func_name=0x7f224a09af94 "setpwent", lookup_fct=<optimized out>, nip=0x7f224a2daf38, startp=<optimized out>, last_nip=0x7f224a2daf48, stayopen_tmp=0x0, res=0, resbuf=0x7f224a2dae40, buffer=0x612f20 "\030\237-J\"\177", buflen=1024, result=0x7fffa8619628, h_errnop=0x0) at getnssent_r.c:164 #18 0x00007f2249ff5c96 in __getpwent_r (resbuf=<optimized out>, buffer=<optimized out>, buflen=<optimized out>, result=<optimized out>) at ../nss/getXXent_r.c:162 #19 0x00007f224a03973b in __nss_getent (func=0x7f2249ff5c00 <__getpwent_r>, resbuf=0x7f224a2dae40, buffer=0x7f224a2d8e38, buflen=<optimized out>, buffer_size=0x7f224a2dae70, h_errnop=0x0) at getnssent.c:37 #20 0x00007f2249ff5702 in getpwent () at ../nss/getXXent.c:84 If you really need this functionality I suggest you to switch to sssd (nss-ldapd) which I think doesn't have this problem. Fixing this in nss_ldap is IMO not worth it (if possible at all). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.