touch-packages team mailing list archive

[Derek Poon <1350393@xxxxxxxxxxxxxxxxxx>]

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.

 [1]: http://bazaar.launchpad.net/~lightdm-team/lightdm/1.10/view/1995/common/user-list.c#L887
 [2]: http://bazaar.launchpad.net/~robert-ancell/accountsservice/lp1290785/view/head:/debian/patches/0010-set-language.patch#L60
 [3]: http://arthurdejong.org/nss-pam-ldapd/
 [4]: http://packages.ubuntu.com/trusty/ldap-auth-client

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to accountsservice in Ubuntu.
https://bugs.launchpad.net/bugs/1350393

Title:
  Recent accountsservice update causes login window to hang

Status in Light Display Manager:
  New
Status in accountsservice package in Ubuntu:
  Confirmed

Bug description:
  Hi,

  The recent 0.6.35-0ubuntu7.1 update (see
  https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1290785)
  seems to have removed the UID_MAX check, which could be used to hide
  users from the login window. In a large organization where many
  thousands of users are present on our systems, we relied on the
  UID_MAX setting in /etc/login.defs to prevent accounts-daemon from
  trying to frob all our accounts. accounts-daemon's performance is so
  poor, that not having the UID_MAX check causes lightdm to hang for
  5-10mins while accounts-daemon tries to look for something in every
  users home folder.

  I've already done things like set the login window to require the user
  to enter their username and password rather than list all users, but
  the login window still hangs while accounts-daemon is doing its thing.

  The behavior I see, is:

  1) just after boot, there's a black screen, right after the plymouth splash disappears, for 2-3 minutes before lightdm appears
  2) You type a username into the username field and press 'Tab'
  3) lightdm appears to hang for 5-10mins before the cursor moves to the password field. During this time, I see an accounts-daemon spawn for each user on the system, sequentially (in alphabetical order). Once the last user's accounts-daemon process finishes, the cursor moves to the password field.

  This not only happens on first boot, but every time a user logs out
  and the system returns to the login window.

  Any chance we can have the UID_MAX check back? Or some equivalent?
  This is causing a serious problem for us!

  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/lightdm/+bug/1350393/+subscriptions