GNOME Bugzilla – Bug 336237
Make gnome-session launch dbus-daemon --session
Last modified: 2007-03-30 23:21:16 UTC
It is a fact that GNOME is using dbus more and more every day that passes. Some applications now even fail to start if dbus is not present (see epiphany). Unfortunately, things do not work out of the box if you install GNOME from sources (or from an "uncustomized" OS; see below) because there is nothing in GNOME that launches a dbus-daemon session at startup. Therefore, the user is forced to either 1) change his ~/.xinitrc to do 'dbus-launch gnome-session' or 2) edit his gdm configuration files to launch dbus-daemon before gnome-session. Of course many Linux distributions such as Ubuntu or Fedora Core include customized X startup scripts that launch dbus-daemon during a session setup. Other systems could ship customized gdm packages to avoid this problem, but still users could hit a problem when using the traditional 'startx'. Not to mention that some systems will not ever include that in their standard X11 scripts (I'm facing NetBSD now, but is applicable to several other systems I guess.) What I suggest is to change gnome-session to launch a 'dbus-daemon --session' at startup, just as it launches other daemons such as gconf or gnome-keyring. This way the user is not forced to change his current scripts nor practices and things Just Work (TM) without problems. However, gnome-session has to be careful to not launch a second dbus-daemon, because the user might have launched, for whatever reasons, one by himself. (E.g. to use some console utility that needs dbus or because his system X11 scripts already launch a dbus-daemon instance.) In this regard, my patches should be backwards-compatible with previous practices. Summarizing, this is what the attached files do. Using the patch and the two new files I am able to simply use gnome-session and get a dbus-enabled GNOME desktop.
Created attachment 62144 [details] [review] Patch to enable gsm-dbus.* build.
Created attachment 62145 [details] Header for new dbus-daemon management functions.
Created attachment 62146 [details] Code to launch a dbus-daemon child process.
Comments from IRC: <vuntz> jmmv: in gsm_dbus_daemon_stop(), the g_assert() is nasty <vuntz> * Stops the running dbus-daemon. Can only be called if we own the process; <vuntz> * i.e., if gsm_dbus_daemon_start returned true. <vuntz> and gsm_dbus_daemon_start() can return true if dbus was launched before gnome-session too, can't it? <jmmv> uh oh <jmmv> you are right <jmmv> aren't assertions enabled by default? because I do not recall seeing the failures here <vuntz> yes, they're nearly always enabled <jmmv> guess I'll have to review that <vuntz> jmmv: also, in have_dbus_daemon(), "return file_name != NULL;" is correct, but I usually don't like to use a pointer after having freed it ;-) <vuntz> I'd use a temp variable for the return value <jmmv> yep, that's better Some other comments: + in read_line(): for (i = 0; i < bytes; i++) if (buf[i] == '\n') discard = TRUE; no need to do this if discard is already TRUE + in read_line(): if (bytes > 0 && buf[bytes - 1] == '\n') buf[bytes - 1] = '\0'; This should be done in the loop when trying to see if discard should be set Other than that, it looks okay to me. But someone else should review it :-)
Created attachment 62589 [details] Code to launch a dbus-daemon child process. This new gsm-dbus.c file fixes all issues reported by Vincent Untz.
There are still some issues with this patch. In have_dbus_daemon, you can potentially free a NULL pointer. And instead of closing the file descriptors, would it not be better to use fcntl to set FD_CLOEXEC?
Nevermind the NULL free. I keep forgetting that g_free() can handle NULL.
Created attachment 74287 [details] [review] Updated patch that includes all This patch includes all work done above and adds something extra: Startup order has been changed so dbus applications get the keyring socket exported. This fixes the regression in evolution with keyring support where evolution doesn't know where the keyring daemon is located when launched via keyboard shortcuts.
(In reply to comment #8) > Created an attachment (id=74287) [edit] > Updated patch that includes all > > This patch includes all work done above and adds something extra: > Startup order has been changed so dbus applications get the keyring socket > exported. This fixes the regression in evolution with keyring support where > evolution doesn't know where the keyring daemon is located when launched via > keyboard shortcuts. > This patch fails with gnome-session-2.16.1 I untared the gnome-session-2.16.1.tar.bz2 file, cd into it then apply patch patch -Np1 -i ../gnome-session-dbus.patch successfully run ./configure --prefix=/opt/gnome-2.16.1 --sysconfdir=/etc/gnome/2.16.1 --mandir=/opt/gnome-2.16.1/share/man successfully make gives this error gcc -g -O2 -o gnome-session manager.o ice.o main.o prop.o save.o command.o remote.o logout.o splash-widget.o gsm-xrandr.o gsm-keyring.o gsm-gsd.o gsm-protocol.o gsm-remote-desktop.o gsm-sound.o gsm-at-startup.o gsm-multiscreen.o gsm-typebuiltins.o gdm-logout-action.o util.o -pthread /usr/X11R6/lib/libXrandr.so -L/usr/X11R6/lib /usr/X11R6/lib/libXext.so -L/opt/gnome-2.16.1/lib -L/usr/lib /opt/gnome-2.16.1/lib/libgnome-desktop-2.so /opt/gnome-2.16.1/lib/libgnomeui-2.so /usr/lib/libjpeg.so /usr/lib/libstartup-notification-1.so /opt/gnome-2.16.1/lib/libbonoboui-2.so /usr/X11R6/lib/libSM.so /usr/X11R6/lib/libICE.so /opt/gnome-2.16.1/lib/libgnomecanvas-2.so /opt/gnome-2.16.1/lib/libgnome-2.so /usr/lib/libesd.so /usr/lib/libasound.so /usr/lib/libaudiofile.so /usr/lib/libpopt.so /usr/lib/libart_lgpl_2.so /usr/lib/libgtk-x11-2.0.so /usr/lib/libgdk-x11-2.0.so /usr/lib/libatk-1.0.so /usr/lib/libgdk_pixbuf-2.0.so /usr/lib/libpangocairo-1.0.so /usr/lib/libpangoft2-1.0.so /usr/lib/libpango-1.0.so /usr/lib/libcairo.so /usr/lib/libfontconfig.so /usr/lib/libfreetype.so /usr/lib/libexpat.so /usr/lib/libpng12.so /usr/X11R6/lib/libXrender.so /usr/X11R6/lib/libX11.so /usr/X11R6/lib/libXau.so /usr/X11R6/lib/libXdmcp.so /opt/gnome-2.16.1/lib/libbonobo-2.so /opt/gnome-2.16.1/lib/libgnomevfs-2.so /usr/lib/libxml2.so -lz -lssl -lcrypto /usr/lib/libavahi-glib.so /usr/lib/libavahi-client.so /usr/lib/libavahi-common.so -lresolv -lutil /opt/gnome-2.16.1/lib/libbonobo-activation.so /opt/gnome-2.16.1/lib/libORBitCosNaming-2.so /opt/gnome-2.16.1/lib/libgconf-2.so /opt/gnome-2.16.1/lib/libORBit-2.so -lm /usr/lib/libgmodule-2.0.so -ldl /usr/lib/libgthread-2.0.so -lpthread /usr/lib/libdbus-glib-1.so /usr/lib/libgobject-2.0.so /usr/lib/libdbus-1.so -lnsl /opt/gnome-2.16.1/lib/libgnome-keyring.so /usr/lib/libglib-2.0.so -lrt -lwrap main.o: In function `main': /usr/src/blfs/compile/gnome-session-2.16.1/gnome-session/main.c:436: undefined reference to `gsm_dbus_daemon_start' /usr/src/blfs/compile/gnome-session-2.16.1/gnome-session/main.c:510: undefined reference to `gsm_dbus_daemon_stop' collect2: ld returned 1 exit status make[3]: *** [gnome-session] Error 1 make[3]: Leaving directory `/usr/src/blfs/compile/gnome-session-2.16.1/gnome-session' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/src/blfs/compile/gnome-session-2.16.1/gnome-session' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/blfs/compile/gnome-session-2.16.1' make: *** [all] Error 2 any ideas ????
Committed, at last. Thanks!
Created attachment 85258 [details] [review] Difference between proposed patch and applied patch The code in gnome-session 2.18.0 that has been committed to SVN is different from the suggested patch. With the code in 2.18.0, some of our users get errors connecting to the dbus session bus. It seems multiple versions are started inside gnome-session, but I'm not sure about that as I could only reproduce it once. Changing the code with this patch resolves all issues.
Jan: is this related to bug 395488?
Yes it is. Instead of just applying this patch as a workaround, I guess a better solution should be made in 395488. In the meanwhile distributions could use this patch as quickfix. Marking as duplicate, as this one was originally closed and the new problem is described a lot better in 395488. *** This bug has been marked as a duplicate of 395488 ***