GNOME Bugzilla – Bug 628302
Drop --start and --foreground option when autostarted via dbus activation
Last modified: 2012-03-15 09:38:41 UTC
I guess that after https://bugzilla.gnome.org/show_bug.cgi?id=611002 was fixed, the behavior of the combination of --start and --foreground had changed.
Created attachment 169043 [details] [review] Drop --start and --foreground option when autostarted via dbus activation Otherwise this will be a no-op as g-k-d will enter into an infinite sleep loop after noticing that another daemon is running in another session.
About --foreground: Doesn't dbus activation expect the process not to exit? Secondly why would we drop --start. The whole concept is to start it in an already running daemon if possible.
Well, what dbus activation expects is that after it starts the executable specified in .service, it will start listening in the bus indicated by the environment variables. What happens right now (AFAICS) is that a process starts and is kept in an infinite sleep loop. That process is not listening in the bus at all so activation has failed. If those flags should be working in accordance with what dbus activation expects, then I could come with a patch in that direction.
Created attachment 169342 [details] test case To reproduce this issue, launch this script inside a new dbus session bus: dbus-launch --exit-with-session ./activate_keyring.py You will see how the call times out because gnome-keyring-daemon doesn't initializes itself in the bus.
Created attachment 169343 [details] [review] Initialize the dbus service (even if a daemon is already running) if the --start and --foreground flags were passed
(In reply to comment #5) > Created an attachment (id=169343) [details] [review] > Initialize the dbus service (even if a daemon is already running) if the > --start and --foreground flags were passed This (and also the original patch) has the downside that the service will have to ask the user to unlock the keyring. Any ideas about how to start a new dbus service but with the keyring unlocked if a service is already running in another session bus?
What are you trying to accomplish? It's unlikely that one gnome-keyring-daemon process can share the unlocked state of various keyrings and keys with another gnome-keyring-process.
(In reply to comment #7) > What are you trying to accomplish? In some cases there's value in having more than one session bus in the same session. The particular case I'm behind is running a Sugar session inside a GNOME one. > It's unlikely that one gnome-keyring-daemon process can share the unlocked > state of various keyrings and keys with another gnome-keyring-process. I understand it, guess that asking for the password during dbus activation is correct then.
Are you sharing all the other environment variables between the main GNOME session and the sugar one? Obviously not the DBUS_SESSION_BUS_ADDRESS. In order for gnome-keyring to work for you you need to clear all gnome-keyring related environment variables in the child session: GPG_AGENT_INFO SSH_AUTH_SOCK GNOME_KEYRING_CONTROL GNOME_KEYRING_PID If you share these environment variables with your sub-session (sugar) then all sorts of things won't work as expected. The gnome-keyring startup process is rather complex, because it brings together many components in the system. You can read details about it here: http://live.gnome.org/GnomeKeyring/RunningDaemon
Any progress on this bug? Is Tomeus patch ready to go in?
The patch doesn't actually fix the core issue. Running a gnome-keyring-daemon under an alternate dbus session needs more than just --start removed. It needs a new environment, in particular the above mentioned environment variables cleared.
No further response on this. Closing the bug.