Bug 1266650 - when automatic login is enabled - google-chrome takes a long time (1m) to start
when automatic login is enabled - google-chrome takes a long time (1m) to start
Status: CLOSED DUPLICATE of bug 1269581
Product: Fedora
Classification: Fedora
Component: gnome-keyring (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Matthias Clasen
Fedora Extras Quality Assurance
Depends On:
Blocks: F23FinalBlocker F23FinalFreezeException
  Show dependency treegraph
Reported: 2015-09-26 00:15 EDT by Satish Balay
Modified: 2015-10-13 09:38 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-10-13 08:06:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Satish Balay 2015-09-26 00:15:24 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):


How reproducible:

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.

Actual results:

google-chrome takes a long time to start

Expected results:

start quickly

Additional info:

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.
Comment 1 Owen Taylor 2015-09-28 16:37:52 EDT
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.
Comment 2 Ray Strode [halfline] 2015-09-28 20:35:05 EDT
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:

Comment 3 Owen Taylor 2015-09-29 08:19:46 EDT
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]
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.
Comment 4 Ray Strode [halfline] 2015-10-13 08:03:32 EDT
*** Bug 1269581 has been marked as a duplicate of this bug. ***
Comment 5 Ray Strode [halfline] 2015-10-13 08:06:38 EDT
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 ***

Note You need to log in before you can comment on or make changes to this bug.