Comment 11 for bug 328575

Created an attachment (id=19543)
See comment.

I realize that the best way to fix this is probably to add the uid to the DBUS_SESSION_BUS_ADDRESS environment variable, as has been suggested. However, we need to fix this issue in the short-term or else we will get a lot of people complaining about the regressions, and we only have a few days to get some sort of fix into the next release.

So, I patched GConf so that if the call to gconf_activate_server failed it would unset DBUS_SESSION_BUS_ADDRESS and try again. However, this still failed with GConf complaining that it couldn't connect to the same temp file as specified by the environment variable before it was unset. This confused me for a while.

I figured out that this is because D-Bus caches the bus_connection_addresses, and there doesn't seem to be any interface to uninitialize D-Bus so you can try again like I was trying to do in GConf.

The attached patch modifies internal_bus_get in dbus-bus.c so that if dbus_connection_open fails *and* if bus_connection-addresses was not initialized when the function was called, then it will uninitialize the bus_connection_addresses by calling addresses_shutdown_func. This is, I'm sure, a hacky way to workaround the problem. However, it does seem that D-Bus shouldn't cache the connection information if it fails to startup. Otherwise, how can the calling program try again with different connection info?

Or, it might be better if D-Bus just offered a public interface to tell D-Bus that the calling program wants to try to start up D-Bus again a second time but with different connection information (e.g. by messing with unsetting DBUS_SESSION_BUS_ADDRESS or something), and that would just uninitialize things.
Then GConf could call that function before trying again.

While this doesn't really fix the problem as elegantly as fixing the environment variable to contain uid information, it does seem that D-Bus should offer an interface to allow calling programs to try again if they want (either by D-Bus automatically not caching on initial failure as this patch tries to do, or by providing a public interface to clear the cache). So I think this issue should also be fixed regardless of how we fix the long-term issue of how to run programs which require GConf to run via su.

Thoughts? Any suggestions on a better way to do this?