xfce4-session fails to spawn gnome-keyring-daemon

Proposed solution is to re-apply this patch (see bug #316222):

xfce4-session (4.4.3-0ubuntu2) jaunty; urgency=low

  * Add 09_gnome_keyring_daemon_2_25_compat.patch which prevents
    xfce4-session from spawning gnome-keyring-daemon on it's own.
    It gets spawned by PAM during login, so it shouldn't be started
    again by XFCE. (LP: #316222)

From package gnome-keyring - 2.26.1-0ubuntu1 (13 Apr 2009):
  "DBus now automatically starts the gnome-keyring service properly."

xfce4-session should not try to do the same on session opening.

This bug was fixed in the package xfce4-session - 4.6.1-1ubuntu3

---------------
xfce4-session (4.6.1-1ubuntu3) lucid; urgency=low

  * debian/control: refresh Vcs-* fields for lucid.
  * debian/patches/xubuntu_gnome-keyring-daemon-compat.patch: don't spawn
    gnome-keyring-daemon manually. lp: #357346
  * debian/patches/series: include it.
 -- Lionel Le Folgoc <email address hidden> Sat, 20 Feb 2010 20:35:05 +0100

I believe this bug was closed prematurely. It is important to realize the unusual details of gnome-keyring-daemon, the services it provides, and its two-stage startup. Take a look at the documentation:

http://live.gnome.org/GnomeKeyring/RunningDaemon

If you still think it should not be run twice, go back and read the documentation again.

Contrary to comment #2, it is spawned by PAM only when the user logs in by typing in a password. When GDM is configured for automatic or timed login, gnome-keyring-daemon does not get spawned. That means auto-login users will be left with no keyring service unless it gets started elsewhere.

When gnome-keyring-daemon is spawned by PAM, it is strictly to capture the user's password for automatic unlocking of the login keyring. From the docs: "When run with the --login option, gnome-keyring-daemon does not fully initialize. It expects to be initialized later by calling another gnome-keyring-daemon with the --start option." Yes, it does need to be run a second time, partly to finish initializing, and partly so it can print the environment variables that some programs use to find it.

Keep in mind that gnome-keyring-daemon acts not only as a place to store secrets, but also as an SSH agent. Many people prefer it because it provides better keyring integration and better UI than the classic ssh-agent program. In order for ssh and other programs to use it, the X session startup procedure must capture and export the environment variables it prints.

For example, running gnome-keyring-daemon --start will finish initializing and print something like this:

  GNOME_KEYRING_CONTROL=/tmp/keyring-0vbOKZ
  GNOME_KEYRING_PID=1234
  SH_AUTH_SOCK=/tmp/keyring-0vbOKZ/ssh

In order to get full functionality, one of the X session startup scripts should therefore do something like this: export `gnome-keyring-daemon --start`

Quoting from the documentation again:
"""
gnome-keyring-daemon has certain environment variables that must be set in the user's session:
    * Each of the above ways of starting gnome-keyring prints out appropriate environment variables to stdout.
    * In the case of --login only a few environment variables will be printed. A later call to --start will print the remaining environment variables.
    * When used with a modern DBus capable session manager (like gnome-session 2.24.x and later) gnome-keyring-daemon will register environment variables directly with the session manager.
"""

Under GNOME, I believe gnome-keyring-daemon gets its second run via the *.desktop scripts in /etc/xdg/autostart. This completes initialization without capturing the printed environment variables, but since GNOME's session manager allows those environment variables to be set via D-Bus, they get exported anyway. Under Xfce, the session manager lacks the D-Bus environment variable feature, so running gnome-keyring-daemon a second time via .desktop files fails to export the environment variables. For now, on Xubuntu, it looks like it really does have to be done in one of the session startup scripts.

When I was using Xubuntu 9.10 (Karmic), I worked around the problem by putting this in a ~/.xprofile file:

  export ...

P.S. Of course, /usr/bin/xfce4-session could also do the necessary work (as an alternative to doing it in the scripts I suggested). And, now that I look at the source code, I see that the upstream xfce4-session does exactly that. Sigh... it looks like this patch removed the call to gnome_keyring_daemon_startup(), effectively disabling the correct behavior:

xubuntu_gnome-keyring-daemon-compat.patch

That patch ought to be reverted. Instead of fixing the original problem, it lobotomized xfce4-session.

In light of the discovery of the bad patch, I have just re-opened the bug against xfce4-session. Apologies if I should have created a new bug instead.

See also: bug 564831

Hi,

Thanks for your work, but I don't want to reopen this old bug (it's one year old, was for jaunty or karmic, and gnome-keyring has been rewritten for 2.30). Let's continue in the newer bug report (Bug #564831).

Since it took me quite a while to unravel the order in which xubuntu session startup scripts are executed, I think I'll write it down here. Perhaps this will help someone else in the future.

gdm
/usr/share/xsessions/xubuntu.desktop
...
/etc/gdm/Xsession command=/usr/share/xubuntu/session.sh
    /etc/profile
    ~/.profile
    /etc/xprofile
    ~/.xprofile
    /etc/X11/Xsession.d/*
        20x11-common_process-args
            STARTUP=/usr/share/xubuntu/session.sh
        74dbus_dbus-launch
            STARTUP=/usr/bin/dbus-launch --exit-with-session /usr/share/xubuntu/session.sh
        99x11-common_start
            exec $STARTUP
    [/etc/gdm/Xsession does not continue]
...
/usr/share/xubuntu/session.sh
    exec startxfce4
...
/usr/bin/startxfce4
~/.config/xfce4/xinitrc OR /etc/xdg/xfce4/xinitrc
/usr/bin/xfce4-session