although it manifested itself at login or when switching network with nm-applet, rather than at boot-up.
The problem basically seems to be that dbus is trying to get user/group information on a system configured to use a LDAP user database.
When the network is entirely disconnected, dbus/nss-ldap fail quickly, and everything works normally.
When the network is connected, but the LDAP server is unavailable, dbus/nss-ldap perform large numbers of lookups, which all time-out, causing many operations (login, switching network) to take seemingly forever.
I solved the problem by simply removing ldap from nsswitch.conf. This is possible for me, because I am also using nss-updatedb to cache the ldap users/groups in a local database, and pam_ccreds to authenticate against this database when ldap is unavailable.
I do think dbus/nss-ldap should handle a missing ldap server more gracefully. Think of laptop users.
Hi!
I'd like to say I've 'solved' my problem - I'm not sure this bug is the right one for what I was experiencing.
I think my problem was more related to:
https:/ /bugs.launchpad .net/ubuntu/ +source/ libnss- ldap/+bug/ 51315
although it manifested itself at login or when switching network with nm-applet, rather than at boot-up.
The problem basically seems to be that dbus is trying to get user/group information on a system configured to use a LDAP user database.
When the network is entirely disconnected, dbus/nss-ldap fail quickly, and everything works normally.
When the network is connected, but the LDAP server is unavailable, dbus/nss-ldap perform large numbers of lookups, which all time-out, causing many operations (login, switching network) to take seemingly forever.
I solved the problem by simply removing ldap from nsswitch.conf. This is possible for me, because I am also using nss-updatedb to cache the ldap users/groups in a local database, and pam_ccreds to authenticate against this database when ldap is unavailable.
I do think dbus/nss-ldap should handle a missing ldap server more gracefully. Think of laptop users.
Regards from Vienna,
Richard Unger