Launching dbus from gnome-session would be the fix for this issue.

http://bugzilla.gnome.org/show_bug.cgi?id=336237 contains patches to fix the problem. The last patch that I uploaded is what we use on archlinux and fixes most regressions we found while upgrading to gnome 2.16.

Ubuntu bug about that: https://launchpad.net/products/control-center/+bug/62163

Since the patches in bug 336237 have been committed, this should be fixed now, right?

(In reply to comment #3)
> Since the patches in bug 336237 have been committed, this should be fixed now,
> right?

There's a simple check: Does the "log out" keyboard shortcut work?

Well, it doesn't...

*** Bug 413723 has been marked as a duplicate of this bug. ***

This bug is fixed partially, but it requires action from the user/distribution side: dbus must be started from within gnome-session. Most distributions start dbus from an xinit script to make sure it is running. Gnome-session only starts a dbus session bus when none is running yet. When dbus is launched before gnome-session, variables like SESSION_MANAGER, GNOME_KEYRING_SOCKET and other environment options set from gnome-session are not available to programs launched from dbus.

That doesn't seem to work properly, either, then. If I don't start the session bus myself, g-s-d cannot connect to dbus (and crashes, but that's another bug). Anything else that needs to be done?

That is with control-center and gnome-session both at 2.17.92.

Works for me, since moving session dbus to g-s-d. My session was dbus starting in an xinit script. It works now that I removed it. I had a crash, too, which I fixed somehow by blowing away my gnome conf and starting over (by removing ~/.gconf*,~/.gnome*, anything gnome related). I suggest adding a new user to try a fresh gnome configuration before you go through that work.

Also, I still have a system dbus started by rc-scripts (dbus-daemon --system). I'm not sure if that's what you need.

Not sure what the problem is yet, but when I remove the start of the session bus from my login script, the machine-id file somehow gets removed, making session startup fail.

Should not be related to GNOME in any way, though, so closing as fixed.

*** Bug 353157 has been marked as a duplicate of this bug. ***

*** Bug 393869 has been marked as a duplicate of this bug. ***

*** Bug 448659 has been marked as a duplicate of this bug. ***

Hey guys, this is causing bug 540537.  Since the session is scoped to the session bus, the session bus has to be started before programs in the session.

We probably need to fix dbus to have a SetActivationEnvironment method or some such that lets things like SESSION_MANAGER get added to activated clients.

Barring fixing dbus, we should make sure that dbus daemon is started earlier before bonobo-activation-server could be activated.  So maybe just after getting SESSION_MANAGER and starting keyring daemon.

So I looked into this a bit.

I think the reporter in bug 540537 is still using gnome-session 2.22 (I asked so we'll find out shortly). 2.23 actually starts dbus very early, so bug 540537 shouldn't be manifesting itself the way described if the reporter were using 2.23.

That does mean that 2.23 regressed the fix in this report though.  While SESSION_MANAGER gets set before dbus is started, GTK_MODULES and the previously mentioned GNOME_KEYRING_SOCKET won't be.

Those don't get started until later.  We could add another phase before starting dbus to the new gnome-session, say PRESTARTUP or something and set, GTK_MODULES and start keyring then. Since PRESTARTUP would be before the session bus is started, it couldn't use the session bus to set environment.  It'd have to be a dbus peer-to-peer connection or some other ipc mechanism (maybe just print the variables and read them).

But it's really the wrong approach, I think, because dbus should be started before gnome-session.  That's how it was designed.  We should just fix the bug where you can't adjust the activation environment.  I'll look into doing that.

(In reply to comment #16)
> But it's really the wrong approach, I think, because dbus should be started
> before gnome-session.  That's how it was designed.

(Which, IMHO, was a design error; we already had two processes competing over who was the root of the session (gnome-session and bonobo-activation-server). We really didn't need a third. In a perfect world, gnome-session would be like Apple's launchd, except with loadable modules, and dbus-daemon and b-a-s would be libraries that it would load in to handle those kinds of apps...)

> We should just fix the bug
> where you can't adjust the activation environment.

FWIW, that still doesn't fix the problem :-}. If you set the "Run a terminal" keybinding in gnome-keybinding-properties, and then use it, that terminal might not have $SSH_AUTH_SOCK set, because it will be started by gnome-settings-daemon, which might have been started before gnome-keyring-manager was, and so it doesn't matter whether or not gnome-keyring-manager tells dbus-daemon about the variable or not because it's already too late at that point.

IIRC, KDE solves this by having all launching be done by a central launching service. (Eg, when you pressed the "Run a terminal" key, g-s-d would not launch gnome-terminal directly, it would ask gnome-session or dbus-daemon to do it, and they would have the correct environment set up, and so you'd win.) Although they also have a DCOP/D-Bus call to fetch the value of $SESSION_MANAGER from ksmserver for when apps get started without that being set, so apparently the central launcher doesn't solve everything.

bonobo-activation-server was never trying to be the root of the session.  Up until the patch from bug 530615 that tied it to the session (via the session bus which led to bug 540537) it was per user, not per session.

I agree we don't need 3 processes competing to try to define the session scope, but I think it needs to be the session bus.  Note some things run in the user session before gnome-session is ever started.  gnome-session is too late in the process to start the session bus.

Why do you think it's a design error to start dbus first?

Your scenario doesn't invalidate the need for adding the session bus interface to adjust the activation environment.  It just means the session manager needs to be careful when ordering what services get started.  That's true anyway, though.  I mean it's true regardless of if the session manager starts dbus or dbus gets started first.

The dbus intent was to be the session root and lifecycle "grounding point" for the desktop. When it (or the X server) exits, everything else is supposed to exit.

Can be changed of course, but one advantage is that programs could then set environment variables and launch services in a cross-desktop way.

The other rationale is that environment variables are simply wrong, except for legacy purposes. The main reason they are wrong is that they depend on process inheritance and can't be changed without logging out and back in. 

Dan made the same point in http://lists.freedesktop.org/archives/dbus/2008-May/009759.html

Not that legacy stuff can be summarily dropped, but I would argue that the system design should revolve around the proper way to do things now, which is with bus names not env variables. If using bus names instead of env variables, you need dbus to be the root.

In the end it probably doesn't matter that much, in practice the SM and dbus-daemon have to work as a unified whole and together start up the session.

There was an older thread and I thought a bug about this on the dbus list and bugzilla respectively, but I can't find either one, so maybe my imagination. Not sure there were any big insights anyway other than "yeah, there should be some type of AddEnvVariable thing in the bus API"

The dbus patch should be trivial, afaik.

There's also a possible hack without modifying dbus which is to put a launch helper in the config file like the one the system bus uses to set privileges, but, I don't know why you'd do it that way - it's harder than just putting an AddToEnvironment thing in the bus itself.

> (Which, IMHO, was a design error; we already had two processes competing over
> who was the root of the session (gnome-session and bonobo-activation-server).
> We really didn't need a third. In a perfect world, gnome-session would be like
> Apple's launchd, except with loadable modules, and dbus-daemon and b-a-s would
> be libraries that it would load in to handle those kinds of apps...)

Just reading this more slowly, fwiw the historical goal was not to be a third but to replace those two and also dcop and ICE in this role. There was a plan. ;-)

An arbitrary old mail that mentions it offhand:
http://osdir.com/ml/freedesktop.dbus/2004-07/msg00079.html

Hmm, same google search also turned up 2005 discussion of setting env variables:
http://mail.gnome.org/archives/desktop-devel-list/2005-August/msg00024.html

b-a-s was the most broken of the pre-existing ones since it was per-user instead of per-session, while gnome-session didn't have the service-discovery capability.
So at the time the existing stuff did not really solve the problem, and certainly not in a cross-desktop way.

(In reply to comment #18)
> Your scenario doesn't invalidate the need for adding the session bus interface
> to adjust the activation environment.  It just means the session manager needs
> to be careful when ordering what services get started.

My point was that as long as you have arbitrary processes setting environment variables, and arbitrary processes launching child processes, then you can't just "be careful", because there will always be a scenario that will break whatever ordering you chose. (And then from there to "environment variables suck", as Havoc said.)

Anyway, originally I wrote something explicitly agreeing with you that we should still do the dbus Setenv thing anyway, but I guess I deleted that while rewriting the comment. Oops. Anyway, yes, you should write the Setenv thing.

> Why do you think it's a design error to start dbus first?

It's not "starting dbus first" that's the design error, it's the fact that dbus-daemon assumes and requires that it is the session root, but it doesn't actually replace the *other* process in the system that assumes and requires that it is the session root, and so to make things work at all you end up needing a *third* session root (dbus-launch) that does nothing except manage the two other session roots...

I've posted the dbus patch here:

http://lists.freedesktop.org/archives/dbus/2008-July/010059.html

We only care about the ordering the few well known legacy environment variables that are causing us problems I think.

We don't need to solve this problem for arbitrary processes and environment variables.

Created attachment 114467 [details] [review]
gnome-session patch to use new dbus api

The discussed dbus api is in dbus git master now.  The above patch changes gnome-session to use the api.

some comment on the patch : 

-could you merge the ChangeLog (or just drop it), otherwise it doesn't apply directly
-could you remove the warning in gnome-session " WARNING **: dbus-daemon is already running: processes launched by D-Bus won't have access to $SESSION_MANAGER!" since it is becoming false (when dbus supports the new api) ?

I honestly think we shouldn't be starting dbus manually at all anyway.

If you call dbus_bus_get () and dbus isn't running, it will get started.  So we should either

1) drop the dbus starting code entirely and rely on distros to start the message bus daemon as it was originally designed

or

2) drop the dbus starting code entirely and set DBUS_SESSION_BUS_ADDRESS to the autolaunched bus address after the dbus_bus_get () call if DBUS_SESSION_BUS_ADDRESS isn't already set (it's a property on the root window iirc)

Either way, I think we should drop the dbus starting code, including the warning you mention.

Should do 1) so there's only one codepath, the one in dbus-launch, imo

Plus it's a tiny bit more efficient

The autolaunch stuff is kind of a rube goldberg device, it's a ton of complex code and it's simpler to just say "the daemon should always already be launched"

with my distro hat, I concur with Ray and Havoc : one code path is way better to debug dbus stuff :)

(In reply to comment #25)
> I honestly think we shouldn't be starting dbus manually at all anyway.
> 
> If you call dbus_bus_get () and dbus isn't running, it will get started.  So we
> should either
> 
> 1) drop the dbus starting code entirely and rely on distros to start the
> message bus daemon as it was originally designed

IIRC, the dbus launching code was added at the request of some distributor (don't remember if it's freebsd or debian). So relying on distros who don't want to do this is... weird :-)

in that case, it should be disable at compile time.

(In reply to comment #28)
> IIRC, the dbus launching code was added at the request of some distributor
> (don't remember if it's freebsd or debian).

NetBSD. bug 336237.

It seems like an easy solution to the problem there would be to provide a "gnome-dbus-session" wrapper script:

    #!/bin/sh

    exec dbus-launch --exit-with-session gnome-session "$@"

and then OSes/distros that don't want to do any session-startup-wrapping can just use that script as the GNOME session launcher rather than using gnome-session directly.

(Or we could just throw the real gnome-session into $libexecdir and have $bindir/gnome-session be a script, that checks if dbus is already running, and starts it if it isn't, and then everyone could just always use gnome-session, regardless of whether or not their session startup was dbusified or not.)

Ray's option 1 it is.  Fixed in trunk.  Thanks.