Thanks for the report!

I was able to reproduce this easily, and partially have this tracked own now. The basic problem is multiple different attempts to start the gnome-keyring daemon interfering with each other. When pam_gnome_keyring is used (for normal with-password login), gnome-keyring is started differently and the issue doesn't occur.

What happens, as I see it, is that there are two processes of gnome-keyring-daemon --secrets running. (Caveat emptor in the below... it's something *sort of* like this.)

 Copy A) - run by D-Bus activation from the service file, D-Bus thinks it has the service name, but it *doesn't*, and because of the --foreground option passed in the service file, it is waiting in a blocking sleep forever.

 Copy B) - run by the desktop file in /etc/xdg/autostart

For GNOME alone, what might work is to make the service files in /etc/xdg/autostart DBusActivatable=true so everything is launched via D-Bus in a race-free fashion. But the autostart files are also used by Unity and MATE - so perhaps what would be better is to do:

 Exec=gdbus introspect --session --dest org.freedesktop.secrets --object-path /org/freedesktop/secrets

Or have starting by activation be part of an executable shipped with gnome-keyring.

so gnome-keyring is normally started in the initialization phase of start up.  gnome-session doesn't exit the initialization phase until all things started in the initialization phase register with the session manager (or daemonize which we treat to mean the same thing). Chrome won't get started until after the initialization phase is complete.  probably gnome-keyring is exiting the parent before it takes a name on the bus.  if so, we could probably fix it like g-s-d was fixed a few years ago:

https://bugzilla.gnome.org/show_bug.cgi?id=559168

Google Chrome is not involved here - gnome-keyring is simply entirely wedged and unresponsive when the session starts. I'm not sure if some other session component and is involved, or whether the three separate gnome-keyring daemons that are autostarted in the no-pam_gnome_keyring case themselves trigger the problem.

It's possible that unsplitting the autostart and starting only a single gnome-keyring to handle secrets/ssh/pkcs11 would hide the issue. It seems that is how things end up working when pam_gnome_keyring is in effect. (And the autostart jobs just exit immediately?)

But I do think the setup is conceptually problematical - the service file has:

[D-BUS Service]
Name=org.freedesktop.secrets
Exec=/usr/bin/gnome-keyring-daemon --start --foreground --components=secrets

But the Exec line does *not* necessarily* provide the service - it can look on the bus, see the name already there, and just sleep forever. I think this inherently runs afoul of the race-free singleton handling in the DBus server.

*** Bug 1269581 has been marked as a duplicate of this bug. ***

actually let me dupe that the other way since the other bug as all the blocker goo etc

*** This bug has been marked as a duplicate of bug 1269581 ***