libnss-ldap create troubles in gnome session when ldap server is unreacheable

[Id2ndR]

Binary package hint: libnss-ldap

System : Maverick RC

Steps to reproduce:
- Install libnss-ldap and set it up correctly
=> Gnome sessions should work normally for a local user
- Plug the computer in an other network or unplug it
=> the ldap server should be unreacheable
- Click on the full name of a local user in GDM
=> The password prompt doesn't appears immediately. This isn't the expected result
- Enter the password and login
=> Startup sound start about 15 seconds later. 20 seconds after logged in, the gnome-panel and the sound menu appears, but the sound is considered as mute an the sound menu doesn't appears when clicking on it.

Expected results:
- "getent passwd" may give a result immediately (the is a delay of 1 second)
- gdm should prompt for the password immediately
- the sound menu should work normally

Workaround: install libnss-ldapd that use nscd with some cache mechanisms that provide the expected results above.

[C de-Avillez (hggdh2)]

Thank you for reporting this bug and helping make Ubuntu better -- and thank you very much for the research on the workaround. I have added a GDM task, and opened a Gnome bug on for it (and linked it here). This does not sound as much as a libnss-ldap issue as a GDM issue.

[C de-Avillez (hggdh2)]

I am marking the libnss-ldap task Incomplete/Low, waiting for feedback from the desktop folks. I expect it to be eventually set to invalid, though.

[C de-Avillez (hggdh2)]

@Id2ndR: can you please attach here the contents of you ~/.xsession-errors and /var/log/gdm/* when you try to login disconnected? Thank you.

[Id2ndR (id2ndr)]

$ egrep -v "^(#|$)" /etc/ldap.conf | cat
base dc=local
uri ldap://ldap.tlse.lng/
ldap_version 3
rootbinddn cn=manager,dc=example,dc=net
timelimit 2
bind_timelimit 1
bind_policy soft
idle_timelimit 1
pam_password md5
nss_initgroups_ignoreusers avahi,avahi-autoipd,backup,bin,couchdb,daemon,games,gdm,gnats,haldaemon,hplip,irc,kernoops,libuuid,libvirt-qemu,list,lp,mail,man,messagebus,news,nslcd,proxy,pulse,root,rtkit,saned,speech-dispatcher,sshd,sshkey,statd,sync,sys,syslog,uml-net,usbmux,uucp,www-data

[Etienne Goyer (etienne-goyer-outlands)]

By design, the NSS library is expecting the database to be available and fast to query. When the NSS database become unresponsive (as is the case when using libnss-ldap and the the LDAP directory become unavailable), this assumption breaks and functions such as getpwnam() blocks, which can cause any kinds of funny symptoms in the calling application. This is not really a bug, more like a design flaw in NSS, so there really isn't a good solution for that. If it was my call, I would close this bug as Invalid, even though it is a very real problem, because it is not strictly speaking a "bug", or at least not one we can solve in the context of one specific package or library.

ld2ndR: the solution to your problem is to use a NSS backend that can work offline, such as SSSD, libnss-ldapd or winbind. Using nscd may help. You can also alleviate the symptoms somewhat by setting bindpolicy to soft, and timelimit and bind_timelimit to low value in /etc/ldap.conf.

[Id2ndR (id2ndr)]

@Etienne Goyer: I changed the timelimit and bind policy, installed libnss-ldapd and now I don't get trouble with the gnome-session. However I got other trouble like bug #672521.

I aggree with your analysis but I'm still looking for a paintless solution. I'll probably write a shell script that change my nsswitch.conf file when the avability of the ldap directory changes.

[Clint Byrum (clint-fewbar)]

This does indeed look to be Invalid in libnss-ldap. Its worth taking a look at in glibc though as perhaps there is some work to resolve this in NSS's design, so opening a bug task against eglibc.