dbus-sesssion questions

Tue Jul 14 11:29:05 BST 2026

[ sorry for the late reply, was busy $irl]

On Mon, 06 Jul 2026 13:09, Simon McVittie <smcv at debian.org> wrote:
>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.
Right, will do so in the future.
>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)
>
Thanks for clarifying. Afaik the pam bits are done by pam-openrc, and 
the other bits are (mostly) done by the yet-to-be-uploaded 
dbus-user-session-openrc package.
>>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.
>
Ah, right.
>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.
>
I agree that for the time being, especially since this is new, we want 
to keep the alternative provides until we have a more polished openrc 
experience. This dbus package is also essential if users want to start 
openrc user services.
>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.
>
Right, that makes sense, too. So it'd be openrc-dbus-user-session.

Thanks for all the insights!

@Mark: Do you agree with the naming and Provides:?

best,

werdahias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: Digital signature
URL: <http://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/attachments/20260714/52d16b30/attachment.sig>