GNOME Bugzilla – Bug 671826
Login hangs if ~/.pki/nssdb exists
Last modified: 2012-03-14 21:28:35 UTC
If the ~/.pki/nssdb directory (the shared NSS database) exists on filesystem – even if it is empty – the GNOME login process hangs before having started the Shell or any application. This appears to be caused by the following startup item: File: /etc/xdg/autostart/gnome-keyring-pkcs11.desktop Name: Certificate and Key Storage Cmnd: /usr/bin/gnome-keyring-daemon --start --components=pkcs11 If the above item is disabled via `gnome-session-properties`, the login proceeds normally. Strangely, running the above command in a terminal, after logging in, works just fine -- the command exits immediately, outputting a few environment variables. gnome-keyring 3.3.91-1 libgnome-keyring 3.3.91-1 gcr 3.3.90-1 Arch Linux
Any chance you could attach to gnome-keyring-daemon and get a backtrace to see what it's blocking on?
See https://live.gnome.org/GettingTraces/Details#Obtaining_a_stack_trace_using_GDB_with_a_running_program for a how-to.
Oh, I forgot to mention: I can't reproduce on my machines (Fedora, Ubuntu). I have that a ~/.pki/nssdb directory, and gnome-keyring-daemon starts fine. So that's why I'm interested in the backtrace from someone who sees this.
I have no idea, honestly. All threads in gnome-keyring seem to be stuck on read() or poll(): <<EOF (gdb) thread apply all bt
+ Trace 229877
Thread 7 (Thread 0x7fb0a0e36700 (LWP 70342))
EOF I will try a fresh user account again.
Hmmm, looks like this is where gnome-shell is blocking:
+ Trace 229878
Thread 1 (Thread 0x7ff142a12900 (LWP 70386))
Could you post the contents of ~/.pki/nssdb/pkcs11.txt and the list of files in ~/.pki/nssdb ?
The files are: /home/grawity/.pki/nssdb ├── [-rw------- grawity grawity 10K] cert9.db ├── [-rw------- grawity grawity 13K] key4.db └── [-rw------- grawity grawity 598] pkcs11.txt pkcs11.txt is: <<EOF library= name=NSS Internal PKCS #11 Module parameters=configdir='sql:/home/grawity/.pki/nssdb' certPrefix='' keyPrefix='' secmod='secmod.db' flags= updatedir='/home/grawity/.local/share/evolution' updateCertPrefix='' updateKeyPrefix='' updateid='/home/grawity/.local/share/evolution' updateTokenDescription='Evolution S/MIME' NSS=Flags=internal,critical trustOrder=75 cipherOrder=100 slotParams=(1={slotFlags=[RSA,DSA,DH,RC2,RC4,DES,RANDOM,SHA1,MD5,MD2,SSL,TLS,AES,Camellia,SEED,SHA256,SHA512] askpw=any timeout=30}) library=/usr/lib/libnssckbi.so name=Mozilla Root Certs NSS=trustOrder=100 EOF A completely empty ~/.pki/nssdb/ has the same problem. Strangely enough, I could not reproduce this with a different account.
Really strange, and interesting. Could you install the debug info for NetworkManager-glib and gnome-shell and do the gnome-shell backtrace again?
Well, crap. After some more browsing, it turns out that this is my own fault. :( I had a ~/.pkcs11/modules/nss, pointing to the shared NSS database. Apparently, I used to have p11-kit-proxy.so installed as a PKCS#11 module in Thunderbird & Firefox, to access the shared database directly and avoid duplication of certificates between several programs. Removing the ~/.pkcs11 configuration fixes this...
So NSS was loading p11-kit-proxy which was in turn loading NSS? Yeah, that'll do it. Although it's strange that p11-kit-proxy.so didn't show up in your nssdb/pkcs11.txt config.
It didn't because Firefox and Thunderbird use their own private NSS databases and configuration, ignoring ~/.pki/nssdb. Firefox NSS would load p11-kit which would load NSS again, this time for ~/.pki/nssdb.
Ah I see. So let's close this bug. BTW, thanks for trying out p11-kit and putting it through its paces. If you do see further bugs or problems, I'd love to hear about them.