After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 662528 - Need signal matching Setenv dbus method so apps in initialization phase can update their env too
Need signal matching Setenv dbus method so apps in initialization phase can u...
Status: RESOLVED FIXED
Product: gnome-settings-daemon
Classification: Core
Component: media-keys
3.4.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-settings-daemon-maint
gnome-settings-daemon-maint
: 582436 661642 674053 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-10-23 15:07 UTC by dan
Modified: 2014-10-19 19:08 UTC
See Also:
GNOME target: 3.4
GNOME version: ---


Attachments
manager: add the EnvironmentSet signal (3.89 KB, patch)
2012-01-11 19:48 UTC, Cosimo Cecchi
none Details | Review
main: rename on_session_over to on_session_proxy_signal (1.76 KB, patch)
2012-01-11 19:51 UTC, Cosimo Cecchi
none Details | Review
main: update environment on EnvironmentSet (1.53 KB, patch)
2012-01-11 19:51 UTC, Cosimo Cecchi
none Details | Review
main: move the env vars we set in a static array (1.66 KB, patch)
2012-01-11 19:51 UTC, Cosimo Cecchi
none Details | Review
main: don't update environment for the variables we set ourselves (1.20 KB, patch)
2012-01-11 19:51 UTC, Cosimo Cecchi
none Details | Review
media-keys: Get the environment from gnome-keyring (3.09 KB, patch)
2012-03-30 09:40 UTC, Bastien Nocera
committed Details | Review

Description dan 2011-10-23 15:07:46 UTC
Last few days i observed that i have to enter the password of my ssh key manually each time i connect to a remote machine. "Normally" this is handled by, i believe, gnome-keyring. Since 3.2.1 this feature is (for me) not working anymore

Running ubuntu 11.10
gnome-keyring: 3.2.1

Not sure if thats the correct package to file the bug against.
Comment 1 Stef Walter 2011-10-24 08:37:25 UTC
Could you provide the output of the following commands?

$ ps -xa | grep gnome-keyring
$ set | grep SSH
Comment 2 dan 2011-10-24 14:13:21 UTC
here you go

dan@Greyskull:~$ ps -xa | grep gnome-keyring
Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html
 1814 ?        SLl    0:00 /usr/bin/gnome-keyring-daemon --daemonize --login
 1939 ?        S      0:00 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets



dan@Greyskull:~$ set | grep SSH
SSH_AGENT_PID=1863
SSH_AUTH_SOCK=/tmp/ssh-ouRXjGix1824/agent.1824
Comment 3 Stef Walter 2011-10-28 15:55:17 UTC
It seems that gnome-keyring-daemon is not being initialized properly. On startup. Could you look at /var/log/auth.log and see if there are messages from gnome-keyring-daemon?

Additionally could you make sure that the "SSH Key Agent" is checked and enabled in the dialog that appears when you run "gnome-session-properties".
Comment 4 dan 2011-10-28 16:00:13 UTC
In gnome-session-properties there is no ssh key agent entry, just one for the gnome-keyring, but it was never needed before.

Next time the problem occurs ill check auth.log and report back, its not reproduceable for me on every boot. 50:50 chance atm.
Comment 5 Stef Walter 2011-10-28 16:03:28 UTC
That's strange (in addition to being started from pam), gnome-keyring is started by the session, and if it's not listed in gnome-session-properties then something seems broken. It should be checked there by default.
Comment 6 dan 2011-10-28 16:06:28 UTC
gnome-keyring is listed in the session-properties, ssh agent is not tho.
"Gnome Secret Storage Service" is the entry (/usr/bin/gnome-keyring-daemon --start --components=secrets )
Comment 7 Stef Walter 2011-10-28 16:12:19 UTC
What does this give you:

$ ls /etc/xdg/autostart/gnome-keyring-*
Comment 8 dan 2011-10-28 16:14:34 UTC
dan@Greyskull:~$ ls /etc/xdg/autostart/gnome-keyring-*
/etc/xdg/autostart/gnome-keyring-gpg.desktop
/etc/xdg/autostart/gnome-keyring-pkcs11.desktop
/etc/xdg/autostart/gnome-keyring-secrets.desktop
/etc/xdg/autostart/gnome-keyring-ssh.desktop
Comment 9 Stef Walter 2011-10-28 16:17:57 UTC
That's really wierd. I don't understand why those listed in the startup applications? At this point I'm looking suspiciously at Ubuntu, but let's see if we can get to the bottom of this. Are you on gimp.net irc? Can you join me at #keyring?
Comment 10 dan 2011-11-04 21:20:22 UTC
Took a while to resurface but here we go:


dan@Greyskull:~$ ps aux|grep keyring
dan       1852  0.0  0.1 168028  5724 ?        SLl  21:54   0:00 /usr/bin/gnome-keyring-daemon --daemonize --login
dan       1989  0.0  0.0  58256  1972 ?        S    21:54   0:00 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets

dan@Greyskull:~$ ps aux|grep ssh-agent
dan       1919  0.0  0.0  12264   272 ?        Ss   21:54   0:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session /usr/bin/gnome-session --session=gnome-classic



dan@Greyskull:~$ echo $GNOME_KEYRING_PID
1852
dan@Greyskull:~$ ps aux|grep 1852
dan       1852  0.0  0.1 168028  5724 ?        SLl  21:54   0:00 /usr/bin/gnome-keyring-daemon --daemonize --login
dan       3163  0.0  0.0  16160   916 pts/4    D+   22:16   0:00 grep --color=auto 1852
dan@Greyskull:~$ echo $SSH_AUTH_SOCK
/tmp/ssh-FGvruYIC1867/agent.1867

(that one is different)

d-feet -> secrets says -> keyring-daemon --daemonize --login


hope that helps
Comment 11 Stef Walter 2012-01-02 13:10:27 UTC
Sorry took a while to get to this.

From the processes and SSH_AUTH_SOCK it appears that gnome-keyring-daemon isn't getting the chance to set its environment variables correctly. Here's how it should work in your situation:

 1. gnome-keyring-daemon initially started (but not initialized) by pam.
 2. later during the startup of gnome-session, the autostart files are run
    and gnome-keyring-daemon initializes itself using the current environment.
 3. during initialization gnome-keyring-daemon sets session environment variables
    in the gnome-session-daemon using the SetEnv() dbus interface.

So two things could be failing (intermittently). Either in step 2, the autostart files aren't being run, or in step 3 the session isn't accepting the environment variables.

If the failure is in step 3 then there should be log output in your /var/log/auth.log, could you include relevant lines from there next time this happens?

Other than that I'm not really able to troubleshoot this further without actually hands on. Have other Ubuntu users reported this to Ubuntu's bug tracker?
Comment 12 mark 2012-01-09 18:25:09 UTC
This is a terrible show-stopping bug for ssh-agent users in gnome3, but I don't think it is related to gnome-keyring.

The best explanation I have found is in the Ubuntu bug https://bugs.launchpad.net/debian/+source/gnome-session/+bug/839444

Apparently there are two separate ssh-agent invocations when you log in, so you give one key for things you do from the shell explicitly, but if you do a custom keybinding those keys don't apply and it asks you for a passphrase every time.

Apparently the custom keybinding is started before the ssh-agent for the rest of the session, so there are separate SSH_AUTH_SOCK variables.
Comment 13 Stef Walter 2012-01-10 16:37:24 UTC
Aha, that makes sense. Reassigning to gnome-session.
Comment 14 Vincent Untz 2012-01-10 16:53:19 UTC
Good catch.
Comment 15 Cosimo Cecchi 2012-01-11 19:48:01 UTC
Created attachment 205040 [details] [review]
manager: add the EnvironmentSet signal

gnome-session patch
Comment 16 Cosimo Cecchi 2012-01-11 19:51:21 UTC
Created attachment 205041 [details] [review]
main: rename on_session_over to on_session_proxy_signal
Comment 17 Cosimo Cecchi 2012-01-11 19:51:28 UTC
Created attachment 205042 [details] [review]
main: update environment on EnvironmentSet
Comment 18 Cosimo Cecchi 2012-01-11 19:51:34 UTC
Created attachment 205043 [details] [review]
main: move the env vars we set in a static array
Comment 19 Cosimo Cecchi 2012-01-11 19:51:39 UTC
Created attachment 205044 [details] [review]
main: don't update environment for the variables we set ourselves
Comment 20 Cosimo Cecchi 2012-01-11 20:01:31 UTC
[ last four patches against gnome-settings-daemon ]

After talking with Vincent and Stefan on IRC it looks like this should be the approach.
It looks like it's not enough though; gnome-settings-daemon will not receive any signal in response the calls made to Setenv(), probably because those are made just between the time gnome-settings-daemon is spawned and the time it connects to the gnome-session DBus proxy signals (I verified that the Setenv() calls are received correctly on the gnome-session side).
I don't have enough knowledge of the interactions here, so I will wait for someone else to chip in, but my first thought would involve adding a Getenv() call, that would return all the variables set with Setenv() (which in turn would have to be cached by gnome-session).
Comment 21 Matthias Clasen 2012-01-12 01:52:47 UTC
Setenv was not a great idea to begin with...this is just making matters worse, 
imo. Calling setenv is not threadsafe.

At least for the LC_ variables that g-s-d is setting from gsettings, we should just make gnome-session read those directly out of gsettings.
Comment 22 Cosimo Cecchi 2012-01-12 15:41:15 UTC
(In reply to comment #21)
> Setenv was not a great idea to begin with...this is just making matters worse, 
> imo. Calling setenv is not threadsafe.
> 
> At least for the LC_ variables that g-s-d is setting from gsettings, we should
> just make gnome-session read those directly out of gsettings.

I agree on both points.
As far as I can understand from gnome-session's README, the real problem is the current session startup design kind of assumes things started in the initialization phase will not need the environment variables as set with SetEnv() (it's inherently racy) which is bad if you have to spawn processes for e.g. keybindings. This was not a problem in the past because keybindings were handled entirely by the window manager, which is started only in the next phase.

I think an approach to solve this problem could be to make gnome-session's environment handling stateful; e.g. gnome-session could export a org.gnome.SessionManager.GetEnv(), and gnome-settings-daemon could query for the current environment and regenerate envp before spawning its children, or something. One problem with this approach is gnome-settings-daemon itself has UI to display, so it would need to set the environment for itself as well.

Another longer-term fix would involve moving all the process spawning to a separate component (systemd anyone?) and make that ensure the environment is always up-to-date.

Probably though, a better shorter term fix is to
- move gnome-settings-daemon locale handling to gnome-session as suggested by Matthias
- have gnome-settings-daemon read the keyring environment directly out of gnome-keyring after it appeared on the bus
Comment 23 Cosimo Cecchi 2012-01-16 18:11:12 UTC
Other unintended breakage caused by this (well, a combination of this and broken assumptions elsewhere): I use a keybinding to spawn my terminals and hack on projects. gnome-shell sets some environment variables which cause gjs to display printf messages to stderr by default [1].
Since now terminals do not inherit those env vars anymore, calling log() in gjs from a terminal spawned with a keybinding don't yield any output.

[1] http://git.gnome.org/browse/gnome-shell/tree/src/main.c#n311
Comment 24 Ray Strode [halfline] 2012-01-16 23:42:55 UTC
arguably gjs should do that by default, but I don't think gnome-shell's intention was to fix gjs output for other programs. So, in some ways, this breakage is actually more technically right.
Comment 25 Cosimo Cecchi 2012-01-17 00:11:31 UTC
(In reply to comment #24)
> arguably gjs should do that by default, but I don't think gnome-shell's
> intention was to fix gjs output for other programs. So, in some ways, this
> breakage is actually more technically right.

I completely agree (I fixed gnome-documents to set the same gjs variables like the shell does)...this was more a point for myself and others that might stump in the same issue while this is fixed.
Comment 26 dan 2012-01-31 06:17:41 UTC
After some pause the bug occured again. Any more information i can provide?
Comment 27 Bastien Nocera 2012-03-29 11:11:30 UTC
*** Bug 661642 has been marked as a duplicate of this bug. ***
Comment 28 Bastien Nocera 2012-03-29 11:19:01 UTC
I'd personally go with:
- make gnome-session read (and update) the LC_* envvars itself from GSettings (and remove that code from gnome-settings-daemon)
- have gnome-settings-daemon read the interesting envvars directly from gnome-keyring (ssh, GPG, others?)

Opinions?

In the meanwhile, restarting gnome-settings-daemon by hand would make it pick up the new environment.
Comment 29 Bastien Nocera 2012-03-29 11:40:35 UTC
*** Bug 582436 has been marked as a duplicate of this bug. ***
Comment 30 Cosimo Cecchi 2012-03-29 13:01:02 UTC
(In reply to comment #28)

> In the meanwhile, restarting gnome-settings-daemon by hand would make it pick
> up the new environment.

Yeah this would makes sense to me, and is basically the same conclusion I got to in comment 22.
Comment 31 Matthias Clasen 2012-03-29 22:31:14 UTC
I agree too. Who writes the patch(es) ?
Comment 32 Stef Walter 2012-03-30 06:18:11 UTC
gnome-keyring-daemon exposes its environment variables via DBus.

[stef@stef-desktop ~]$ dbus-send --session --dest=org.gnome.keyring --print-reply /org/gnome/keyring/daemon org.gnome.keyring.Daemon.GetEnvironment
method return sender=:1.33 -> dest=:1.532 reply_serial=2
   array [
      dict entry(
         string "GNOME_KEYRING_CONTROL"
         string "/data/.cache/keyring-z7dTVa"
      )
      dict entry(
         string "GPG_AGENT_INFO"
         string "/data/.cache/keyring-z7dTVa/gpg:0:1"
      )
      dict entry(
         string "SSH_AUTH_SOCK"
         string "/data/.cache/keyring-z7dTVa/ssh"
      )
   ]

These are only valid after the gnome-keyring-daemon autostart stuff has run. The gnome-keyring autostart files complete the initialization of the gnome-keyring-daemon that was started by PAM. There are multiple autostart files so people can disable the SSH, GPG and PKCS#11 agents independently.

Won't it difficult to figure out when gnome-keyring-daemon components have been initialized these environment variables are available?
Comment 33 Bastien Nocera 2012-03-30 09:40:17 UTC
Created attachment 210934 [details] [review]
media-keys: Get the environment from gnome-keyring

When launching custom applications.
Comment 34 Bastien Nocera 2012-03-30 09:42:29 UTC
(In reply to comment #33)
> Created an attachment (id=210934) [details] [review]
> media-keys: Get the environment from gnome-keyring
> 
> When launching custom applications.

That works for me for the purpose of launching custom applications. If there are any other program launched by g-s-d which need this done as well, it should be a quick fix. Does this fix the whole bug, or do we need a broader solution?
Comment 35 Mantas Mikulėnas (grawity) 2012-03-30 11:12:18 UTC
Although I'm only a user, the fix in #33 seems a bit too specific, even if it works.

For a long time I was wondering, wouldn't it be possible for gnome-session to allow calling SetEnv at any time, and send an "environment changed" signal for gnome-settings-daemon to pick up?

(In Windows, programs can broadcast a WM_SETTINGCHANGE message, causing the shell (Explorer) to refresh its own environment from the updated "master copy" kept in Registry.)
Comment 36 Bastien Nocera 2012-03-30 11:21:54 UTC
(In reply to comment #35)
> Although I'm only a user, the fix in #33 seems a bit too specific, even if it
> works.

What's the use case which would break? I want to fix "terminals launched via shortcuts don't know about the gnome ssh agent", not "passing envvars to programs sucks"

> For a long time I was wondering, wouldn't it be possible for gnome-session to
> allow calling SetEnv at any time, and send an "environment changed" signal for
> gnome-settings-daemon to pick up?

gnome-session's environment only changes during the startup phase.

> (In Windows, programs can broadcast a WM_SETTINGCHANGE message, causing the
> shell (Explorer) to refresh its own environment from the updated "master copy"
> kept in Registry.)

We have GSettings for non-legacy applications. Makes no sense to me to try and fix environment passing sucking on Unix systems.
Comment 37 Stef Walter 2012-03-30 13:02:55 UTC
Review of attachment 210934 [details] [review]:

I haven't tested it, but this seems like a decent quick fix.

We really want long term is to send patches to ssh and gpg to look for ssh and gpg agents in XDG_RUNTIME_DIR. Or some better solution than passing around environment variables...
Comment 38 Cosimo Cecchi 2012-03-31 00:41:39 UTC
Review of attachment 210934 [details] [review]:

I also think this would be a good fix for 3.4; just a minor comment on the code.

::: plugins/media-keys/gsd-media-keys-manager.c
@@ +260,3 @@
+	envp = g_get_environ ();
+
+					       NULL,

I think you're supposed to free the iterator with g_variant_iter_free()
Comment 39 Bastien Nocera 2012-04-02 16:11:50 UTC
commit a9388f70abc975da31c90867d9ab9bd7253b1d30
Author: Bastien Nocera <hadess@hadess.net>
Date:   Fri Mar 30 11:36:58 2012 +0200

    media-keys: Get the environment from gnome-keyring
    
    When launching custom applications.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=662528
Comment 40 Bastien Nocera 2012-04-02 16:13:41 UTC
Let's consider this done (committed to master, so GNOME 3.4 too). File new bugs if you have particular use cases which weren't covered (unbreaking the unholy mess that is envvar using in Unix isn't a use case).
Comment 41 Sam Morris 2012-04-02 16:31:28 UTC
Thanks all, I really appreciate the fix!
Comment 42 Stef Walter 2012-04-16 13:16:11 UTC
*** Bug 674053 has been marked as a duplicate of this bug. ***
Comment 43 m.spring 2012-04-22 12:00:53 UTC
After manually adding /usr/bin/gnome-keyring --start --components=secrets to gnome-session-properties the old behaviour of saving ssh-keywords in a session is restored.
Comment 44 Pierre-Yves Luyten 2014-10-19 18:55:27 UTC
Not sure if 1. my setup is wrong 2. i should reopen this one 3. fill in a new one..., but


$ ssh-add -L
Could not open a connection to your authentication agent.

$ ps -aux | grep keyring
buddho    1661  0.0  0.2 536484  8004 ?        Sl   15:57   0:00 /usr/bin/gnome-keyring-daemon --daemonize --login

$ dbus-send --session --dest=org.gnome.keyring --print-reply /org/gnome/keyring/daemon org.gnome.keyring.Daemon.GetEnvironment
method return sender=:1.29 -> dest=:1.123 reply_serial=2
   array [
      dict entry(
         string "GPG_AGENT_INFO"
         string "/run/user/1000/keyring/gpg:0:1"
      )
      dict entry(
         string "SSH_AUTH_SOCK"
         string "/run/user/1000/keyring/ssh"
      )
   ]

in case this helps:

$ echo $SSH_AUTH_SOCK


(i mean this is empty)
Comment 45 Pierre-Yves Luyten 2014-10-19 18:56:54 UTC
forgot the important part

$ gnome-keyring-daemon -V
gnome-keyring-daemon: 3.14.0
testing: enabled
Comment 46 Pierre-Yves Luyten 2014-10-19 19:08:53 UTC
(In reply to comment #45)
> forgot the important part
> 
> $ gnome-keyring-daemon -V
> gnome-keyring-daemon: 3.14.0
> testing: enabled

sorry this is https://bugzilla.gnome.org/show_bug.cgi?id=738205