X-Windows Logins Very Slow

Symptom:

When you try to log in to the graphical console, i.e. XDM, GDM, KDM, LightDM, everything moves at the pace of an arthritic snail.

What's happening:

There are probably a variety of causes of slow logins, including using a nonresponsive network service for user data (such as LDAP or NIS), but one common issue is that polkitd (PolicyKit) fails to start. console-kit-daemon (ConsoleKit) relies on it to make judgments whether the user should be able to do various actions, and the display manager calls ConsoleKit while setting up the greeter GUI, so user interface menu items for those actions can be shown in grey or normally active.

LightDM creates an actual console session of its special user, to run the greeter. I believe that GDM does the same thing. XDM doesn't, and I don't know about KDM. With PolicyKit or ConsoleKit inoperative, this session has to wait for a timeout on each PolicyKit call, and so displaying the greeter takes a long time. Similarly, of course, logging on the user goes very slowly and may fail at the end for no reason obvious to the user.

The root of the problem is a botched installation (or no installation) of the polkit package, preventing the daemon from starting.

How to fix:

For the installation to succeed, the polkitd special user and group need to appear in /etc/passwd and /etc/group. rpm is going to run a pre-install script which executes each of useradd, usermod and groupmod. They authenticate using PAM, so verify that the scripts /etc/pam.d/useradd, /etc/pam.d/usermod, /etc/pam.d/groupadd have appropriate content; specifically, that the auth section begins with

auth sufficient pam_rootok.so

This lets root on without a password, which the script can't give. This was the issue that bit me: the PAM scripts were the wrong ones. For complete paranoia you could try running each of these scripts (as root) to add or modify a user or group just for testing. Hand-edit /etc/passwd and /etc/group to remove your test user afterward.

The polkit package also provides a PAM script /etc/pam.d/polkit-1 for when the user has to give a password to gain access to some feature. Make sure it's correct also.

First check that both polkit and ConsoleKit are actually installed. Install them if not. If you want particular numbers for the UID and GID, pre-edit /etc/passwd and /etc/group before installing.

Verify that the polkitd special user and group are in /etc/passwd and /etc/group. These have to be available early, so relying on a network user directory like LDAP is probably not a good idea. An entry in /etc/shadow is optional and will never be used. The entries on my system (openSUSE 12.3) are like this; the automatically generated numbers vary across systems, and I like to use the same number for the UID and GID and to make them the same on all my machines.

polkitd:x:105:105:PolicyKit special user:/var/lib/polkit:/bin/false
polkitd:!:105:polkitd

For some reason, probably leftovers from the previous version, I got /var/run/polkit as the home directory; nothing creates this directory, preventing the daemon from starting. At least for polkit-0.110 on openSUSE 12.3, /var/lib/polkit is the correct home directory and the package provides it.

If you had to add or modify the polkit user or group by hand in /etc/passwd or /etc/group, you will need to fix permissions, and the easiest way to make that happen is to reinstall the package. To do that:

zypper install --force polkit

--force is important; otherwise it will say the highest version is already installed and refuse to do anything.

By this point you should have all the needed directories and permissions, but just for paranoia check these items:

• /etc/polkit-1/rules.d/ mode 700 owned by polkitd:root
• /usr/share/polkit-1/rules.d/ mode 700 owned by polkitd:root
• /var/lib/polkit/ mode 755 owned by root:root

Reboot the machine to make sure all defective daemon instances are killed. Your display manager should start right up and let you on promptly.