Hmmm, I see the same behaviour. I think it's due to the fact that seahorse-agent is started after gnome-keyring-daemon. I'll look further into it.

This is a gnome-keyring bug. It's due to the fact that seahorse is started in the session before gnome-keyring-daemon and doesn't see the gnome-keyring environment variables. 

Having libgnome-keyring use environment variables to discover gnome-keyring-daemon is suboptimal. I've built up a patch which fixes the problem, by using DBus for discovery. 

Created attachment 82306 [details] [review]
Use DBus for discover of daemon

One sidenote on this patch:
+	dbus_connection_setup_with_g_main (dbus_conn, NULL);

Please add this after that call:

dbus_connection_set_exit_on_disconnect (dbus_g_connection_get_connection(dbus_conn), FALSE);

This will prevent the program from exiting when the dbus connection becomes broken. It's not nice to have a base library exiting your application when a lookup for a keyring daemon is the only reason to keep the connection to dbus.

My comments in a mail to nate:

In some cases gnome-keyring will be running before both dbus and
seahorse-agent, such as a typical pam-keyring setup. In that case we
must communicate via an environment variable. 

I guess we could additionally use dbus to find the daemon, but this must
be done after looking at the env var. 

I don't like using dbus-glib-1. That is an ABI unstable library that we
don't want to use at this level of the stack. (It would make all gnome
apps depend on an unstable library...) The way I solve this in gvfs is
to have a copy-paste of the mainloop integration (actually I made my own
version).

Also, avoid c++ style comments.

---------

Jan: 
That changes the properties of the shared dbus connection! Thats hardly something a library should do!

About the properties changed for a shared connection: take a look at the dbus-glib code, that's the one that changes the connection. The suggestion I made is to revert it. When not using dbus-glib, this is not an issue, since dbus itself doesn't set that property on the mainloop integration property.

Committed:

2007-02-12  Nate Nielsen  <nielsen@memberwebs.com>

	* Makefile.am: 
	* README:
	* configure.in: 
	* gnome-keyring-daemon-dbus.c: (added)
	* gnome-keyring-daemon.c: (main): 
	* gnome-keyring-daemon.h:
	* gnome-keyring-private.h: 
	* gnome-keyring.c: (connect_to_daemon): 
	Added secondary method for daemon discover: via DBus. Added dependency
	on DBus. Fixes bug #400956


Comments: 

 - Now tries Dbus after environment variable. 

 - Added gnarly glib integration code into gnome-keyring-daemon-dbus.c. 
   Library does not need main loop integration.

 - Added call to dbus_connection_set_exit_on_disconnect() from daemon. 
   Thanks Jan for catching that. Obviously this call is not made from 
   the library. 

It isn't clear to me what the code in the final patch did, but the library should NOT change the default for exit on disconnect. Almost all apps SHOULD exit on disconnect (that's why it's the default) because the dbus session daemon defines the session - when it exits, the session is exiting, and the apps should exit. Xlib exits on disconnect from the X server for the same reason, libdbus however also works for nongraphical apps.

If an app does not want to exit on disconnect, it can call set_exit_on_disconnect() itself. But only a very few very special apps have any reason to remain running after the user logs out. In general sysadmins get pissed off about apps/daemons that do this, because it breaks any multiuser system badly. Plus it just doesn't make any sense.

In case it isn't clear, there is *no* case in which the connection to the session bus should disconnect other than the session bus exiting. And the session bus will only exit if the user logs out.

It is not encouraged to try and "recover" from the session bus exiting; the session bus is the "grounding point" that allows recovering when anything *else* exits. There's no "grounding point" for the bus itself, so trying to recover just results in incoherent and broken behavior. The session is toast if the bus exits, and the right app behavior is to exit.

Roger... Please read the last lines of comment #7. 

Once again, the library makes no such call. Nor does it need to since its usage of DBus is transient and used only for initialization.

The final patch: http://svn.gnome.org/viewcvs/gnome-keyring?diff_format=h&rev=545&view=rev

I think it depends on what you use dbus for. If dbus is solely used to discover on what socket the keyring daemon is listening, that application should not integrate dbus with the mainloop and should not exit when dbus becomes broken.

If dbus is used for interprocess communication, like gnome-settings-daemon does (it's even launched by a call into dbus!), then it's very logical that gnome-settings-daemon exits as soon as dbus is away: there's no other way to communicate via this settings daemon without dbus, so it's useless to keep running, so the application should exit in this case.

One very nice example is gnome-session. It integrates dbus in the mainloop to be able to start gnome-settings-daemon. So what happens when dbus crashes? Yes, it's right! you're thrown out of gnome without any question about asking anything. Your screen simply flashes and you're back at the gdm login prompt, where you can login again, after which you'll notice that none of your open applications can be recovered.

A crashing dbus daemon isn't rare. It's the normal procedure when you have dbus compiled with dnotify support and it decides to reload in the middle of a write operation to a config file dbus was monitoring. It will fail to parse the file, reload it anyways and call exit, after which your whole desktop is thrown out. This has been resolved in git though, but besides archlinux, I haven't seen any distribution backporting it to 1.0.2.