Created attachment 59311 [details] [review]
Patch to Xsession.in to add desired functionality.

The patch I'm currently using. Should apply to pretty much any gdm version, since I've been using it unchanged since 2.8.0.5.

I'll have to think about this.  It might be better if gnome-session started dbus rather than GDM because people who use GDM for starting other types of sessions (KDE or CDE or whatever) do not want to run D-BUS.  Since D-BUS is session specific (only certain desktops use it), it might not be appropriate for GDM to start it up.

I understand editing the GDM startup is a good way to start such things when they aren't started by gnome-session, so I understand why you did this to get what you need.  

Hi,

Note dbus isn't in anyway GNOME specific.  It doesn't even link against any GNOME libraries (not even glib).  

There are glib bindings to the dbus client libraries, but then there are Qt bindings also (which are maintained by developers at trolltech.)

If adding dbus makes sense for all types of sessions that the user might want
to launch (including if they aren't using GNOME or KDE), then the GDM Xsession
might be the right place instead of gnome-session.

I notice the code first checks to see if dbus-launch is on the systems and only tries to start it if it is present.

I just want to make sure that GDM is the right place to launch this before I add it to GDM.  Can you confirm?

I think so. On a highlevel, the dbus session bus is just a means for apps to talk to and start services.  Apps do that by asking for a service that has a specified interface.  What components in the desktop environment that provide those interfaces isn't necessarily important to the application.

To give a concrete (but theoretical) example.  Two different screensaver programs could provide a standardized interface with a method for temporarily disabling themselves.  A movie player could call that method while it's playing a movie for instance.

If the user is logged into gnome, gnome-screensaver could provide the interface.  If the user is logged into a different environment, the screensaver provided by that environment could provide the interface.  The movie player wouldn't need to know or care what screensaver it was disabling.

Fedora Core already does something like attachment 59311 [details] [review] and has since either FC2 or FC3, I think (we are now nearing the end of the development cycle for FC5).

Ray - yes, the patch I attached was based on a script fragment I found elsewhere, although memory suggests that the code using it was someone's personal .xsession  rather than a global default.


As a note, here's a mailing list post from late last year that seems to have covered the same issue, with a slightly different approach from the one I used.

http://mail.gnome.org/archives/gdm-list/2005-November/msg00013.html

Rather than using dbus-launch to start the desired session, they're simply running it and having it print out the necessary environment variables for Xsession to export.

Thanks Ray.  I think running dbus-launch is a bit cleaner, so I added this to CVS head.

I've just read the commit message about that. Debian and Ubuntu by example already ship a /etc/X11/Xsession.d/75dbus_dbus-launch to start dbus, will that conflict with gdm running dbus too? Starting that kind of service should be an xorg feature, not specific to the login manager you use

Hmmm, sounds like I should backout this patch.  Thoughts?  Ray?

Well, the patch should be harmless because it has a

&& [ -z "$DBUS_SESSION_BUS_ADDRESS" ]

clause (DBUS_SESSION_BUS_ADDRESS gets set by dbus-launch).  Can you confirm, Sebastien? 

The patch doesn't really matter either way in the Fedora case, because we use our own Xsession file (for gdm, xdm and kdm).

On the other hand, the patch is useful for those who build from source (such as your the original reporter).

I disagree, and backed out ths patch.  Even if people build from source, people should be using a modern enough version of the source to get this from Xorg.  Users should upgrade their Xorg rather than putting the launching in multiple places.  

We can talk further, and if there is a compelling reason to put this in GDM, I'll put it back.

Brian - can you explain that in a bit more detail? I'm running Xorg 7.0, so it's not a matter of upgrading. However, I've no idea what you're talking about as far as a replacement for this patch is concerned. Is the Xsession.d directory referred to by Sebastien a standard feature of newer X versions?

As a note, I assume the same point applies to ssh-agent, since that's also launched from gdm's Xsession? Should that also be being started by some other mechanism?

Sure.  My point is that D-BUS is really a system service and should be started like other services.  GDM should probably not be responsible for starting services like this because users may be using different login programs and you don't really want to try to maintain the interfaces for starting the service in multiple places (GDM, XDM, CDE, etc.).  The system already should have mechanisms for starting services, and these should be used so they get started all the time for everybody and are just in 1 place.

This doesn't apply to ssh-agent because it isn't a service.  It is a part of the command used to start the user's session.

Just to be clear what I mean by "service", a service is something that runs in the background like a daemon.

I'm not sure if the Xsession.d directory referred to by Sebastien is a standard Xserver interface.  I'm not sure what the right/best interface for starting D-Bus should be, I'm just pretty sure it isn't right to try and maintain this in all possible display managers people could be using.  I could be wrong, and if the discussion shows that GDM and other display managers are the right place, I'll add this patch back.

Note there really isn't much difference between ssh-agent and dbus-launch in this respect.  They both support a sort of pass through mode where they are part of the command to start the user's session, and they both support a "eval me" mode where you can run them before you start your session.

Xsession.d is a distribution specific directory, I think. E.g., it's one way that some distributions are solving the "start dbus" problem.  

I agree that maintaining something like this in the login manager isn't the best way to do it. What's the alternative though?

Looking at the Xsession script, it appears to have some hooks for running scripts from /etc/X11/xinit/xinitrc.d - possibly both dbus-launch and ssh-agent should be setup their, using the 'eval' mode rather than wrapping the user's session. Thoughts on this?

Brian - on ssh-agent, what is it, if not a daemon? It's a program run in the background that other programs can access given the right settings (the SSH_AUTH_SOCK environment variable). How is that different from dbus?

services should be started with xorg by a standard way and not be coded to every login manager, most of distro probably provides a way to do that so there is no point to that gdm hack

Ok, *is* there a standard way then? Or does every distro improvise their own?