(In reply to comment #0)
> For this change
> to be effective, gdm will have to stop wrapping gnome-session in a dbus-launch

Sorry, wrong bug number. This is Bug #693668.

Review of attachment 237209 [details] [review]:

Looks good!

Review of attachment 237209 [details] [review]:

hmm, so why can't we just change the dbus client libraries to do this automatically?

::: gnome-session/main.c
@@ +229,3 @@
+        /* Are we in a systemd user session, or something
+         * remarkably similar? */
+        xdg_runtime_dir = g_getenv ("XDG_RUNTIME_DIR");

why not g_get_user_runtime_dir() ?

(In reply to comment #3)
> hmm, so why can't we just change the dbus client libraries to do this
> automatically?

I tried that approach too (<https://bugs.freedesktop.org/show_bug.cgi?id=61303>) but nobody has reviewed it. Comments on that welcome...

> ::: gnome-session/main.c
> @@ +229,3 @@
> +        /* Are we in a systemd user session, or something
> +         * remarkably similar? */
> +        xdg_runtime_dir = g_getenv ("XDG_RUNTIME_DIR");
> 
> why not g_get_user_runtime_dir() ?

A fair point.

(In reply to comment #4)
> (In reply to comment #3)
> > hmm, so why can't we just change the dbus client libraries to do this
> > automatically?
> 
> I tried that approach too
> (<https://bugs.freedesktop.org/show_bug.cgi?id=61303>) but nobody has reviewed
> it. Comments on that welcome...

It's hard to review just that in a vacuum; like you said in https://bugs.freedesktop.org/show_bug.cgi?id=61129#c8 we really need the full plan in place.

Simon, what do you think about trying to set aside a block of time (say 3 days) for a "virtual hackfest" or something?  

Alternatively (or together with the above), let's figure out what the real blocking issues are, and focus on that.  

From my perspective:

* How PAM works
* GDM's greeter sessions

Review of attachment 237209 [details] [review]:

I have now (dbus 1.9.14) managed to land patches to make libdbus default to XDG_RUNTIME_DIR/bus if DBUS_SESSION_BUS_ADDRESS is unset, and I'm testing the equivalent for GDBus now.

dbus 1.9.14's dbus-launch also returns XDG_RUNTIME_DIR/bus if it exists and is suitable; but it would still be one less process if gnome-session could skip running dbus-launch entirely when there is a suitable XDG_RUNTIME_DIR/bus.

::: gnome-session/main.c
@@ +235,3 @@
+                GStatBuf buf;
+
+                path = g_strdup_printf ("%s/dbus/user_bus_socket", xdg_runtime_dir);

This should be "%s/bus" now, because that has been the sd-bus default for a while, and it's the dbus default since 1.9.14.

@@ +238,3 @@
+
+                if (g_stat (path, &buf) == 0 &&
+                    S_ISSOCK (buf.st_mode)) {

We probably also want to check that it's owned by geteuid().

(In reply to Ray Strode [halfline] from comment #3)
> hmm, so why can't we just change the dbus client libraries to do this
> automatically?

In progress, but I do not control every dbus client library.

> +        xdg_runtime_dir = g_getenv ("XDG_RUNTIME_DIR");
> 
> why not g_get_user_runtime_dir() ?

If gnome-session is Unix-specific, that would be fine too.

(In reply to Simon McVittie from comment #6)
> I have now (dbus 1.9.14) managed to land patches to make libdbus default to
> XDG_RUNTIME_DIR/bus if DBUS_SESSION_BUS_ADDRESS is unset, and I'm testing
> the equivalent for GDBus now.

This work was released in a stable dbus version (1.10) a year ago, and in a stable GLib version (2.46) shortly after.

(In reply to Ray Strode [halfline] from comment #3)
> hmm, so why can't we just change the dbus client libraries to do this
> automatically?

If you only care about libdbus, sd-bus and GDBus, then it would now be OK to detect a suitable XDG_RUNTIME_DIR/bus, and do the early "return TRUE" in that situation, avoiding running dbus-launch. However, at that point you've done 95% of the necessary work to be able to set DBUS_SESSION_BUS_ADDRESS, so it seems reasonable to do the g_setenv() to be nice to dbus-java, ndesk-dbus and other more minor D-Bus implementations.

I would definitely like gnome-session to stop trying to run dbus-launch when an XDG_RUNTIME_DIR/bus is available, because I want to make it possible to remove dbus-x11 from systems where dbus configured with --enable-user-session is available, which will mean there is no dbus-launch to run.

I'm in the process of moving house so I don't know when I'll be able to make/test a revised patch, but the things that need changing in my original patch are:

* use XDG_RUNTIME_DIR/bus instead of XDG_RUNTIME_DIR/dbus/user_bus_socket
* check that the socket is owned by getuid() (or perhaps geteuid(), in practice there should never be any difference for gnome-session)
* optionally, use g_get_user_runtime_dir() instead of getenv()

Review of attachment 237209 [details] [review]:

i think i'd like to gut this how function, and instead just try to get a connection to the bus. If it can great, done, else start one.

::: gnome-session/main.c
@@ +246,3 @@
+                         * dbus-daemon, but this is how we make that
+                         * possible. */
+                        g_setenv ("DBUS_SESSION_BUS_ADDRESS", address, TRUE);

g_setenv is a no-no in multithread programs. it can lead to crashes if the glib worker thread is processing a gettext message or something.  it shouldn't be necessary anyway, pam_systemd make sure DBUS_SESSION_BUS_ADDRESS is set for backward compat, it's not our concern.

(In reply to Ray Strode [halfline] from comment #9)
> i think i'd like to gut this how function, and instead just try to get a
> connection to the bus. If it can great, done, else start one.

I think that works. I would hope that in any competent distribution, gnome-session's dependencies are such that a dbus-daemon gets started before gnome-session somehow, either from systemd --user, or dbus-launch in the Xsession.d (or xinitrc.d or equivalent) tower of shell scripts. As a last resort, if dbus-launch is installed and there's no DBUS_SESSION_BUS_ADDRESS, X11 autolaunch works.

(In reply to Ray Strode [halfline] from comment #9)
> g_setenv is a no-no in multithread programs.

Is gnome-session multi-threaded at this point? If so, that's a valid concern.

oh i guess we don't end up going spawning threads until the initialize_gio() call a few lines down.

Hey,

Any progress on this bug?

nope, no one is working on this atm afaik.

it's a bit of a shame we have so many layers of starting dbus..

systemd --user, gdm-wayland-session, gnome-session, the client libraries...

would be nice if we could figure out a point where it's supposed to be started, and just require it be started there, rather than having so much failover code.

(In reply to Ray Strode [halfline] from comment #13)
> it's a bit of a shame we have so many layers of starting dbus..
> 
> systemd --user, gdm-wayland-session, gnome-session, the client libraries...

It is a shame, but this is what we get when the lower levels of the stack are optional.

systemd --user is a good place for this to happen, but only if the OS distribution has chosen the user-sessions model[1], and that doesn't/can't support some things that do work in the traditional one-D-Bus-per-login-session model (multiple parallel X11 sessions per uid per machine, each with its own dbus-daemon), so dbus isn't *necessarily* configured with --enable-user-sessions. On Fedora, Arch and probably others, dbus is always configured like this, but on Debian derivatives, it's controlled by the presence or absence of the dbus-user-session package, and there are probably distros where dbus is always started the way it traditionally was. If GNOME upstream want to say that the user-session model is the only supported configuration, then gnome-session in Debian could gain a hard dependency on dbus-user-session, but I don't know how popular that would be. (There's also the usual issue of a vocal minority of users who refuse to use systemd and will interpret other projects' dependencies on it as a conspiracy against them.)

I don't really know about gdm-wayland-session. Does it support being used on non-systemd systems? Does it support being used without the user-session (one dbus-daemon per uid) model? Does GNOME support gnome-session as a standalone X11 session under a different *dm (xdm or lightdm or whatever), or as a standalone Wayland session?

gnome-session needs to support both Wayland and X11. Distributions have historically had their own integration glue for X11 (like /etc/X11/Xsession.d and the dbus-x11 package in Debian), so any particular distribution can make sure this works, but GNOME as an upstream can't; the next best thing would be to have some clear statement that gnome-session under X11 is only designed to work in OS distributions that set up D-Bus themselves (via something resembling /etc/X11/Xsession.d). For Wayland, there's no precedent of distro-specific integration layers, so the providers of Wayland compositors (GNOME, KDE, etc.) each get to define how theirs works, if they want to.

Client libraries will probably have to fall back to X11 dbus-launch (the "autolaunch:" pseudo-transport) for the foreseeable future, but ideally it's best avoided, because it makes the dbus-daemon's execution environment unpredictable (we can't know whose child process it is, what environment variables and rlimits it will inherit and so on).

However, having gnome-session accidentally trigger a dbus-daemon via GDBus' fallback to "autolaunch:" would be better than the current situation, where gnome-session second-guesses GDBus' behaviour (and gets it wrong, hence the patch I proposed here). If the fallback dbus-daemon was (in practice) a child of gnome-session, then that would make the situation a bit more predictable.

Perhaps what we need is an API in GDBus to connect to the session bus (autolaunching if appropriate), then return the address for subsequent apps to use, such that gnome-session can put it in $DBUS_SESSION_BUS_ADDRESS for its children?

[1] see https://lists.freedesktop.org/archives/dbus/2015-January/016522.html
    aka https://lists.freedesktop.org/archives/systemd-devel/2015-January/027711.html

(In reply to Ray Strode [halfline] from comment #9)
> i think i'd like to gut this how function, and instead just try to get a
> connection to the bus. If it can great, done, else start one.

Sadly...

As you noted, you can't set environment variables for the gnome-session process after you're multi-threaded. (You can set them for its children, but only if there's some strv of environment variables that will be used for all children, which might require some refactoring.)

Things that make you multi-threaded include, er, connecting a GDBus connection.

(In reply to Simon McVittie from comment #15)
> As you noted, you can't set environment variables for the gnome-session
> process after you're multi-threaded. (You can set them for its children, but
> only if there's some strv of environment variables that will be used for all
> children, which might require some refactoring.)
sure, but we already have a groaty shell script wrapper around gnome-session, so we could just brush another layer of groat on it.

Alternatively, there is a thread safe way to modify the current environment… putenv() up front (not setenv) when there are no threads, with a sufficiently sized string and then modify that string later.

GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version of gnome-session, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-session/-/issues/

Thank you for your understanding and your help.