dbus-sesssion questions

[Simon McVittie]

Please send questions regarding D-Bus to dbus at packages.debian.org rather 
than only to me personally: I don't want to be the single point of 
failure for D-Bus on Debian.

Strictly speaking dbus is just the reference implementation of D-Bus 
(there can be others, like dbus-broker) but its package address seems 
like as good a coordination point as any other.

On Tue, 30 Jun 2026 at 16:21:41 +0200, Matthias Geiger wrote:
>What is the purpose of dbus-user-session? As far as I understand, this 
>is *not* the plain dbus session

It was a new concept at the time it was introduced, but is now the 
default and the setup that I would recommend. The other D-Bus session 
bus implementation with OS-level integration is dbus-x11, which only 
works for X11 sessions (not for Wayland, text consoles, ssh, etc.).

*Right now*, the dbus-user-session package only implements this design 
for systemd systems (more precisely, systems with a working `systemd 
--user`, which is a subset of systems with systemd as pid 1), but 
there's nothing to stop non-systemd system designs from doing the same, 
and I've seen that dbus-turnstile-user-session and 
runit-dbus-user-session seem to work similarly. I'd recommend the same 
"shape" that is used with systemd:

* XDG_RUNTIME_DIR set to /run/user/$(id -u) like systemd-logind does
   (some software hard-codes this, even though in principle it shouldn't,
   and the path chosen by systemd-logind is as good as any other)

* a PAM module runs on login/logout and starts or communicates with some
   sort of service manager (in systemd-world this is libpam-systemd
   and `systemd --user`, other service managers presumably have something
   fairly similar)

* the service manager arranges for a dbus-daemon (or dbus-broker or some
   other message bus implementation) to be listening on
   $XDG_RUNTIME_DIR/bus, before the startup of anything else that needs it
   (or it could listen on the socket itself, with an inetd-style arrangement
   like the LISTEN_FDS protocol and start the dbus-daemon on a
   just-in-time basis, which in fact is what systemd does)

* the PAM module sets DBUS_SESSION_BUS_ADDRESS to point to
   unix:path=$XDG_RUNTIME_DIR/bus (with URI-style quoting/escaping as per
   the D-Bus spec if necessary, but one of the reasons to reuse the path
   chosen by systemd-logind is that it happens to be one that won't need
   any quoting/escaping)

>but rather where a user session is 
>assumed to start the first time after login, and it doesn't end
>until all login sessions have ended. It also provides dbus-services 
>with XDG_RUNTIME_DIR

All of those are key features of dbus-user-session, yes.

More precisely, this is about D-Bus *session* services. D-Bus system 
services are also a thing that exists (NetworkManager, etc.) but they're 
orthogonal to all this session-level stuff.

dbus-user-session also (via /etc/X11/Xsession.d/20dbus_xdg-runtime) 
provides activatable D-Bus session services with some other key 
X11/freedesktop.org environment variables, notably $DISPLAY.

But, one thing that it *doesn't* do:

>and runs dbus-activation-enviroment --all

No, that's /etc/X11/Xsession.d/95dbus_update-activation-env in dbus-x11, 
which I see as being a backward-compatibilty thing to cope with the fact 
that older Xsession.d snippets might rely on merely doing `export FOO` 
being sufficient to have FOO in the environment of D-Bus-activated 
services like xdg-desktop-portal. (For example I think some non-Latin 
input methods might still be relying on this, via im-config?)

I think that a high-quality Xsession.d snippet should either not need to 
set environment variables at all (relying instead on components 
discovering each other via $XDG_RUNTIME_DIR, $HOME, D-Bus, X11/Wayland 
or similar), or if new environment variables are really needed, take 
responsibility for uploading them to the D-Bus/systemd/etc. activation 
environment itself.

Environment variables are not a great discovery/advertising mechanism 
because of how they inherit between processes: an environment variable 
can never be "instant-apply", because existing processes will already 
have inherited its old value and are not notified when it gets a new 
value. For example, this is why we can't have instant-apply locale 
settings: with hindsight, the POSIX environment variables used for 
locales are not a great design. Systems like $XDG_RUNTIME_DIR, 
$DBUS_SESSION_BUS_ADDRESS and even $DISPLAY solve this by adding a layer 
of indirection. The $XDG_RUNTIME_DIR doesn't need to change during a 
program run, because it doesn't do anything particularly 
human-meaningful on its own; but the sockets or files in the directory 
that it points to, the information exposed by D-Bus services or 
Xsettings, etc. are human-meaningful and *can* change at runtime.

On Tue, 30 Jun 2026 at 16:00:55 +0100, Mark Hindley wrote:
>Simon, for completeness, I am aware of at least 3 potential packages that now
>provide the systemd-style supervisor + unified dbus session:
>
> dbus-openrc-user-session (pending upload)
> dbus-turnstile-user-session
> runit-dbus-user-session
>
>Obviously they should Provides: dbus-session-bus. However should they also
>Provides/Conflicts: dbus-user-session?

The way I had originally anticipated that this would work, when I 
introduced dbus-user-session, is that dbus-user-session could have 
alternative dependencies on anything that will arrange for the desired 
semantics to exist, so perhaps like this:

     Depends:
      libpam-systemd | dbus-openrc-user-session | dbus-turnstile-user-session | runit-dbus-user-session,
      ...

(This is a bit more complicated in reality because there are several 
systemd-related dependencies, so those alternatives would need to be 
added in more than one place, but you get the idea - and perhaps 
dbus-user-session doesn't need to be so pedantic about its dependencies 
anyway, now that systemd as pid 1 has been the default for several release 
cycles and the only systems not using it will be those where a different 
init was intentionally chosen.)

Or, if one of those alternative service managers becomes a widely-used, 
cross-distro, de facto standard with a long-term-stable API and a 
systemd-unit-equivalent that is low-maintenance over time (as systemd 
itself did, and Upstart nearly did), then dbus upstream and 
dbus-user-session could absorb those systemd-unit-equivalents and 
install them alongside the systemd units that they currently ship, so 
that systemd systems would run the systemd unit, OpenRC systems would 
run whatever OpenRC's equivalent is, and so on, and everyone would be 
happy. I'm not sure that any of the alternatives have that status yet, 
though, so installing them in separate packages with an alternative 
dependency is probably better at the moment - that gives the alternative 
service managers' maintainers more control over the precise details of 
how they start a D-Bus session bus, and more ability to experiment with 
improving those details.

Having had this design in mind is why the package is called 
dbus-user-session, and not dbus-systemd-user-session or something.

If that was implemented, then I'd expect "most" system designs to have 
dbus-user-session installed: systemd users would have dbus-user-session 
and libpam-systemd, resulting in `dbus-daemon --session` being started 
as a `systemd --user` service, while OpenRC/turnstile/runit users would 
instead have dbus-user-session and their appropriate service manager 
glue, resulting in `dbus-daemon --session` being started as their 
service manager's closest equivalent of a `systemd --user` service.

The other way this could potentially work would be for these other 
implementations of a "user bus" to have a Provides for dbus-session-bus 
and dbus-user-session, meaning that systemd users would have 
dbus-user-session + libpam-systemd, but e.g. runit users would only have 
runit-dbus-user-session (and *not* dbus-user-session). However, that 
would mean that these other packages would need to duplicate what 
/etc/X11/Xsession.d/20dbus_xdg-runtime does, unless we moved that file 
into dbus-session-bus-common (which could be practically annoying, 
because it's a dpkg conffile and I'm never sure what manipulations 
are/aren't safe to be doing with conffiles).

I don't think a Conflicts with dbus-user-session is desirable or 
necessary. The only thing in dbus-user-session that could cause a 
problem for alternative service managers is its dependency on systemd, 
which could be expanded into a set of alternative dependencies that 
covers other implementations of the same "API": the actual systemd unit 
files should be inert and useless-but-harmless on non-systemd systems, 
similar to how (for example) the runit glue in openssh-server is 
useless-but-harmless on systemd systems.

>It would be good to agree a naming convention as well.

I think a good rule of thumb is that if a package "belongs to" or "is 
part of" a particular upstream, having that upstream project's name as 
a prefix makes more sense than having it as an infix. So I like the 
naming of runit-dbus-user-session better than dbus-openrc-user-session, 
for a project that is maintained by runit/openrc developers and not by 
the developers of dbus.

     smcv