User bus conclusion

Ryan Lortie desrt at desrt.ca
Tue Nov 9 14:06:42 PST 2010


Hi,

At the Boston summit I had a chance to sit down with Lennart and discuss
the mess we've been going over for the past while.  We came to a strong
conclusion on all points.

We also discussed the conclusion we reached with some others in
attendence and got some rather positive feedback.  I'm going to attempt
to document the conclusion here, but I may get some things wrong or
leave some things out.

The most significant take away is that we will add a "user" bus to DBus.
This bus will be defined as scoped to one user on one machine.  Multiple
logins of the user to the same machine will share the same bus.  systemd
will be managing this.

The bus will listen at a well-known path relative to the user's runtime
directory.  See:

http://lists.freedesktop.org/archives/xdg-list/2010-November/011681.html

The path will be "$XDG_RUNTIME_DIR/dbus/user_bus_socket".

In systemd style, the user bus won't be started until someone actually
tries to the connect to the socket.  If you ssh in, for example,
probably DBus won't be started, but if you try to use it then it will.

DBus client libraries should add knowledge of this new bus type.


That's it in terms of changes to DBus.  What follows is a list of
changes that we recommend will occur to the system as a result.  Of
course, that's up to vendors and distributors.

 - we recommend the session bus will no longer be started

 - we recommend that the DBUS_SESSION_BUS_ADDRESS environment variable
   be set to the socket of the user bus (to support old DBus client
   libraries and/or applications)

 - maybe eventually DBus client libraries can issue deprecation warnings
   to stderr about session bus use by applications

 - the DISPLAY environment variable will be unset

   It needs to be this way when you consider that X may not be running
   at all when the user dbus first starts (in response to an ssh
   session, for example).

 - libX11 (and xcb?) will be modified so that an unset DISPLAY
   environment variable means that the client opens the socket
   "$XDG_RUNTIME_DIR/X11/socket" or such.

   This has the nice effect that we can use systemd to autostart a
   rootless X server on-demand in our post-wayland existence.

 - on login (for now) this will be a symlink to the one in /tmp

 - we are against people doing tricks like "org.domain.MyApp1",
   "org.domain.MyApp2", etc. to support app uniqueness on multiple
   displays.

All of this means that there is only one graphical login per user.

I think Lennart is planning to do most of the work and I'm going to be
helping with some small details; I've already made a couple of
glib/GDBus patches, for example.

Cheers



More information about the dbus mailing list