On Wed, 08 Apr 2020 at 11:02:36 +0200, Jonas Ådahl wrote: > With that being said, it is possible to run multiple D-Bus sessions, > where session busses are separate - it's just that noone actually does > it as even if you have separate D-Bus sessions, separate > $XDG_RUNTIME_DIRs, the sessions still share fundamental resources such > as $HOME, and it is very likely that many applications you attempt to > run will run into issues where they, running on separate "sessions" on > the same user, will try to manage the same set of files in > the users home directory.
We tried this: for about the first decade of D-Bus' existence, the most common model was one session bus per X11 display (with dbus-launch, sometimes packaged as dbus-x11). In practice, it didn't work very well except in the trivial case where there is exactly one X11 session at a time, and I now recommend doing something else. The Mozilla family of browsers, which want to have a single instance per home directory, are a common pain point. Because we have been careful to keep backwards compatibility, recent versions of the reference implementation of D-Bus expect an OS integrator to decide what "session" means to them (or perhaps delegate that decision to the sysadmin). If the semantics they choose result in two instances of an application overwriting each other's files, D-Bus does not have an answer to that, other than "perhaps you should have chosen differently". These models are ready-made and already work: - one D-Bus session bus per "user-session", using $XDG_RUNTIME_DIR/bus (my recommendation; dbus-user-session package in Debian) - one D-Bus session bus per X11 display, by setting a separate $DBUS_SESSION_BUS_ADDRESS and some magic root window properties for each one (historical behaviour; dbus-x11 package in Debian; expect to see applications overwriting each other's changes) and these are something you could put together from pieces by arranging for $DBUS_SESSION_BUS_ADDRESS to be set appropriately, for example by using dbus-run-session(1) or starting a dbus-daemon(1) yourself, if they're what you want: - one D-Bus session bus per Wayland display - one D-Bus session bus per (PAM) login session - one D-Bus session bus per just about anything else with a defined lifetime See https://lists.freedesktop.org/archives/dbus/2015-January/016522.html for what I mean by "user-session" - I'm using it as a jargon term here because I'm not aware of any other name for this concept. Non-reference implementations of D-Bus, like dbus-broker, might have a more opinionated definition of what a session means, and decline to operate in situations that they were not designed for. That's their maintainers' design choice. > even if you have [...] separate $XDG_RUNTIME_DIRs Note that (unlike D-Bus) the freedesktop.org Base Directory specification specifically defines XDG_RUNTIME_DIR to be one per what I call a "user-session" above. For example, if you are concurrently logged in with uid 1000 using gdm on tty1, getty on tty2, a ssh session and a remote desktop, according to the specification they must all share a XDG_RUNTIME_DIR. If you have more than one distinct XDG_RUNTIME_DIR for the same uid, then you are not implementing the Base Directory specification, and you might find that libraries and applications that were expecting XDG_RUNTIME_DIR to be an interoperable Base Directory implementation (including D-Bus implementations!) don't work as intended. In this case you get to keep both pieces. This is presumably why Wayland has $WAYLAND_DISPLAY, so that in the common case you have a single Wayland compositor "wayland-0" per XDG_RUNTIME_DIR, but in rarer cases (like debugging in a nested compositor), you can have more than one compositor and tell your application to choose a non-default one. smcv _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
