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.
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.