I have found something close to a root cause, and I observe this hang 100% of the time under the following conditions:
1. Packages libnss-ldap_264-2.2ubuntu4.14.04.1 and accountsservice_0.6.35-0ubuntu7.1 are installed.
2. /etc/nsswitch.conf contains "passwd: files ldap"
3. An LDAP user has logged in recently, as recorded in /var/log/wtmp.
4. dbus and lightdm are started on boot.
In lightdm_10.10.5-0ubuntu1, user-list.c makes a DBus call for the method org.freedesktop.Accounts.ListCachedUsers.[1] This call times out. You can confirm that ListCachedUsers fails by running `/usr/sbin/dbus-send --system --print-reply --dest=org.freedesktop.Accounts /org/freedesktop/Accounts org.freedesktop.Accounts.ListCachedUsers`.
DBus tries to dispatch the message to accounts-daemon. However, accounts-daemon isn't listening for requests because it hasn't fully started up yet. Rather, it is stuck in the user_locale_validate() function, waiting for the /usr/share/language-tools/language-validate shell script to complete.[2] Note that the language-validate mechanism is an Ubuntu customization, not present in the upstream accountsservice 0.6.35.
The language-validate shell script runs not as root, but as an LDAP user. Bash never gets a chance to execute its first command, since it gets stuck during initialization with a getpwuid() call for that LDAP user that never returns. (To see that, I suggest hacking user_language_validate() to insert an ltrace or strace.) There is a race condition: this early in the boot process, libnss-ldap lookups just hang.
On the other hand, libnss-ldapd, which bills itself as the successor fork to libnss-ldap,[3] does not suffer from such a problem. Unfortunately, if you install ldap-auth-config_0.5.3, it will tend to pull in libnss-ldap as an automatic dependency rather than libnss-ldapd.[4]
In summary, executing `killall language-validate` after boot serves as a workaround, as it lets accounts-daemon continue its initialization. Running `service dbus restart` is a more forceful workaround, as it lets accounts-daemon launch after conditions are ready for LDAP lookups. The problem occurs with libnss-ldap_264-2.2ubuntu4.14.04.1, and it goes away when libnss-ldapd_0.8.13-3 is installed instead. That, to me, is the most sensible solution.
I have found something close to a root cause, and I observe this hang 100% of the time under the following conditions:
1. Packages libnss- ldap_264- 2.2ubuntu4. 14.04.1 and accountsservice _0.6.35- 0ubuntu7. 1 are installed.
2. /etc/nsswitch.conf contains "passwd: files ldap"
3. An LDAP user has logged in recently, as recorded in /var/log/wtmp.
4. dbus and lightdm are started on boot.
In lightdm_ 10.10.5- 0ubuntu1, user-list.c makes a DBus call for the method org.freedesktop .Accounts. ListCachedUsers .[1] This call times out. You can confirm that ListCachedUsers fails by running `/usr/sbin/ dbus-send --system --print-reply --dest= org.freedesktop .Accounts /org/freedeskto p/Accounts org.freedesktop .Accounts. ListCachedUsers `.
DBus tries to dispatch the message to accounts-daemon. However, accounts-daemon isn't listening for requests because it hasn't fully started up yet. Rather, it is stuck in the user_locale_ validate( ) function, waiting for the /usr/share/ language- tools/language- validate shell script to complete.[2] Note that the language-validate mechanism is an Ubuntu customization, not present in the upstream accountsservice 0.6.35.
The language-validate shell script runs not as root, but as an LDAP user. Bash never gets a chance to execute its first command, since it gets stuck during initialization with a getpwuid() call for that LDAP user that never returns. (To see that, I suggest hacking user_language_ validate( ) to insert an ltrace or strace.) There is a race condition: this early in the boot process, libnss-ldap lookups just hang.
On the other hand, libnss-ldapd, which bills itself as the successor fork to libnss-ldap,[3] does not suffer from such a problem. Unfortunately, if you install ldap-auth- config_ 0.5.3, it will tend to pull in libnss-ldap as an automatic dependency rather than libnss-ldapd.[4]
In summary, executing `killall language-validate` after boot serves as a workaround, as it lets accounts-daemon continue its initialization. Running `service dbus restart` is a more forceful workaround, as it lets accounts-daemon launch after conditions are ready for LDAP lookups. The problem occurs with libnss- ldap_264- 2.2ubuntu4. 14.04.1, and it goes away when libnss- ldapd_0. 8.13-3 is installed instead. That, to me, is the most sensible solution.
[1]: http:// bazaar. launchpad. net/~lightdm- team/lightdm/ 1.10/view/ 1995/common/ user-list. c#L887 bazaar. launchpad. net/~robert- ancell/ accountsservice /lp1290785/ view/head: /debian/ patches/ 0010-set- language. patch#L60 arthurdejong. org/nss- pam-ldapd/ packages. ubuntu. com/trusty/ ldap-auth- client
[2]: http://
[3]: http://
[4]: http://