Some Configuration Mistakes Can Prevent Gnome Logins

Posted by JD 10/27/2011 at 03:00

Today I needed to reboot my main desktop to prevent a stupid setup of processes from running. I'm working on a presentation about a backup tool and had kicked off a snapshot. A large number of processes were running, so rather than hunt them all down, I decided that a reboot would be the easiest answer. I don't reboot this desktop very often – perhaps once a month – so changes made last week or earlier don't always sit in my mind as being all that important, especially changes made to a daemon used for authentication to other systems. Should something like that really prevent a local GDM-based login from working? Before 30 minutes ago, I didn't think so.

gpg-agent

I’ve been doing more and more encrypted email, making a real effort to make it my default. After all with real mail I almost never use a postcard, opting for a letter to keep the correspondence with family, friends and businesses private. The same thought process makes sense for email traffic. If you do not encrypt using S/MIME or OpenPGP standards, we are sending email postcards. Is that really what you want?

Anyway, retyping the gpg passphrase was getting old, really old, so I figured it was time to alter the default cache setting for that in the ~/.gnupg/gpg-agent.conf file. The man page for gpg-agent doesn’t really describe the config file or exactly how to enter those, so I took a guess and tried

default-cache-ttl=3600

Seemed reasonable to me. Then I -HUP’ed the process and left it alone. I didn’t recall any errors and it didn’t seem to work too different from before, so I guess it worked. It was not broken.

Login via GDM

After rebooting today, the login prompt came up and I entered my credentials. Pressed the login button and was taken back to the login screen again. Fine, sometimes I mistype the password – try again. Same result – I’m staring at the login screen again. 3rd time, slowly, carefully, type in the password. Same result. Something bad is happening.

I walk over to a different machine on the network and ssh into the desktop. No issues. I check the top processes – it isn’t doing anything. Hummm. Check the /var/log/auth.log and see 

gdm-session-worker2937: pam_ck_connector(gdm:session): nox11 mode, ignoring PAM_TTY :0

polkitd(authority=local): Registered Authentication Agent for session /org/freedesktop/ConsoleKit/Session11 (system bus name :1.56 [/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1], object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.utf8)

gnome-keyring-daemon3475: couldn’t set environment variable in session: The name org.gnome.SessionManager was not provided by any .service files

Huh?

Something is wrong with gnome. I don’t recall changing anything about Gnome in the last few weeks. This desktop runs LXDE. Some google-fu found someone else who had bad settings someplace and they were directed to the 

~/.xsession-errors
file, so I looked inside mine. Sure enough, the error said something about the gpg-agent.conf file having bogus settings. A little research discovered that the = was causing my login issues. Replaced it with a space and logins worked again.

Before I forget about this, I wanted to post it here. This is the type of issue that can drive someone nuts. I’m glad it only took a few minutes of my time. Nothing too fantastic, just some sample troubleshooting that might help someone else with an issue even if it is a little different.