Red Hat Bugzilla – Bug 1266650
when automatic login is enabled - google-chrome takes a long time (1m) to start
Last modified: 2015-10-13 09:38:20 EDT
Description of problem:
When automatic login is enabled - google-chrome takes a long time (1m) to start
Version-Release number of selected component (if applicable):
always [reproduced on 2 different machines that are upgraded from F22 to F23]
Steps to Reproduce:
1. From account settings -> 'Users' enable 'automatic login'
2. reboot [it will automatically login user]
3. start google-chrome.
google-chrome takes a long time to start
If the 'automatic login' is disabled (and reboot/login manually)- google-chrome starts normally [quickly - in a few sec]
I understand google-chrome is not part of fedora - and this issue could be wontfix.
But since this is a regression from F22 - and the behaviour is different based on 'automatic login' enabled/disabled - perhaps there is some issue with 'automatic-login' feature - triggering this behavior.
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:
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:
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 ***