GNOME Bugzilla – Bug 500216
Starting gnome-settings-daemon through dbus is inappropriate
Last modified: 2009-01-08 02:00:46 UTC
This report follows discussions in bug#360475 and especially http://bugs.debian.org/339785 The problem is that programs started by gnome-settings-daemon (through the multimedia keys) don't inherit some environment variables, causing usability issues, e.g. for variables set by seahorse. This is because g-s-d is started through DBus, which in turn is started earlier than gnome-session or seahorse, and in turn doesn't know of the environment variables they set. The control-center developers claim this is not a bug because gnome-session itself is able to start DBus, which then inherits from all relevant environment variables. However, the Debian DBus maintainers are not going to remove the DBus startup from the X session init scripts, and they consider using DBus for launching programs a clear abuse of the API; it is meant to start services, not programs. I have looked at the code, and I still have no idea of why g-s-d is started through DBus. It isn't used for communicating between g-s and g-s-d, only for startup and respawn; things that we have much better APIs than DBus to handle. Therefore I have rewritten the g-s-d spawning code with Glib, and the result is: - 81 less lines of code, - no more dependency on libdbus, - this environment bug fixed once and for all.
Created attachment 99777 [details] [review] Spawn gnome-settings-daemon through g_spawn This patch requires the .pc fix from bug#500174, in order to know the path to gnome-settings-daemon.
g-s-d is started through dbus because it provides an interface for media keys bindings. Well, it "uses" dbus because of that, but there's no reason it can't be started by hand in gnome-session.
Dbus is certainly appropriate for the media keys interface, but gnome-session doesn't use this interface. Using Dbus just for starting the daemon sounds a bit overkill.
Created attachment 105383 [details] [review] Spawn g-s-d through g_spawn but wait for it I have to correct myself: because some applications need g-s-d to be actually running before being started, it is necessary to use dbus to wait for g-s-d to be ready. This new version of the patch spawns g-s-d using g_spawn but waits for it to be enabled before proceeding with the rest of the session. As a side note, org.gnome.SettingsDaemon.service should stop being shipped, to prevent the settings daemon from being spawned by dbus through other applications.
Some comments for last patch: -#include <gtk/gtkmessagedialog.h> +#include <gtk/gtk.h> including gtk.h is slow, so could yuou just please change it to add the needed gtk* files? + DBusGProxy *dbusService; just a minor detail, but could you please call variables what_ever (dbus_service) ? the rest looks ok to me. Any other comment? should we get this in for 2.21.92 ?
Created attachment 105530 [details] [review] Spawn g-s-d through g_spawn but wait for it Here is the patch with the two cosmetic issues fixed. BTW, I don’t know enough the DBUS API to be sure, but I fear this code (with or without my patch) may be leaking DBusGProxy and DBusGConnection objects.
Two quick comments: the patch looks mostly good. There are two issues: + IMHO, the pkg-config binary variable should be a path to the binary, and not the parent of the binary + the while (gsd.activating) can be bad if g-s-d has a bug that doesn't make it crash but blocks it before it registers on the bus. I'll add a timeout to kill it after a few seconds, I guess.
(In reply to comment #7) + Currently it is already a path to the binary. What do you think is wrong here? + Indeed it would be better with a timeout, I’ll try to add that to the patch.
Oh, I misread the patch for the binary, sorry. And I have a version of the patch with the timeout. It's blocked by another bug in gnome-session right now, but I'll get to this soon.
Vincent, any news?
dbus 1.2.4 has an api to inject env variables into the activation environment, and gnome-session uses it to fix this problem. I don't think there is an issue anymore.
I'm closing this one as this doesn't appear to be an issue anymore (see comment #11). Feel free to reopen if the problem persists on latest version of gnome-session.