© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
@stgraber
That's oversimplifying things a bit. :)
As the OP, our servers have several interfaces which gives a server access to various subnets. One of these holds the ldap auth servers. If this interface is downed first, resolvconf will hang for ldap.conf TIMEOUT time for every other interface downed. When they're all down (or any default or matching subnet routes), resolvconf/getent passwd returns immediately.
So... In my case, reducing the /etc/ldap.conf /etc/ldap/ldap.conf timeouts or adding a blackhole route with a high metric value matching the ldap subnets would work around this.
As such it can't be categorized as a bug. When I initially chimed in, the problem was masking the infamous scsi kernel softlockup bug.
I'm still puzzled over the nss query resolvconf is triggering. I cannot reproduce it with getent password or similar lookups. For whatever reason resolvconf triggers a query looking for a posixaccount with uid=\2a (uid="*"), which returns 0 results.