6

I hardly had any success using a dbus-dependent tool over ssh (for example pactl -- pulseaudio command line interface -- that selects audio output).

I know how to manually export the session's DBUS address to DBUS_SESSION_BUS_ADDRESS, but still almost any application fails with messages like connection refused at pa_context_new().

This, sadly, fits well all the reservations against dbus, kdbus (and systemd)...

So what steps are actually required to make any application depending on DBUS run over ssh just as it would from the desktop session?
Is there any non flaky, non error-prone way to get the bus address without relying on screen-long scripts?
What else is required -- appart from the address -- to allow connection?

Thibault Lemaire
  • 103
dronus
  • 1,978

2 Answers2

7

pactl does not depend on D-Bus – it's just one of the various methods it might use for locating the control socket. Which is now always at the same location – $XDG_RUNTIME_DIR/pulse/native (as of pulseaudio v3.0). So the original complaint just plain doesn't make sense. I'm sure that strace -e connect pactl info would reveal that the "Connection refused" error comes from trying to connect to pulseaudio itself, not to D-Bus.

  • One possible cause: If strace shows pactl trying to use /var/run/pulse/native instead of the per-user path, then $XDG_RUNTIME_DIR might not be set. You may set it manually (to /run/user/$UID), however, it would be better to figure out why it isn't being set automatically.

    The $XDG_RUNTIME_DIR variable is set by pam_systemd.so; ensure that your /etc/pam.d/sshd config file eventually lists that module (sometimes directly, but more often by including a sub-config such as system-login or common-session).

That said, when you need to use other programs over SSH – programs which do depend on a session bus – there are three common options:

  • To attach to the 'new' user bus:

    Some systems/distros might have already moved to the "user bus" model, where instead of some number of session buses there's only one for each UID. Its address is unix:path=/run/user/$UID/bus with dbus-daemon, or kernel:path=/sys/fs/kdbus/$UID-user/bus with kdbus.

    Latest versions of sd-bus, libdbus, gdbus will automatically try this address in case neither $DBUS_SESSION_BUS_ADDRESS nor $DISPLAY are set. This makes "user bus" model the most reliable answer to your 1st question, since all you need to know is your own UID. (Most approaches involving traditional "session bus" model cannot be reliable, since there may be any number of those, not exactly one...)

  • To attach to a 'traditional' session bus:

    The session bus address is usually picked at random, to avoid conflicts. However, for various purposes (primarily for the "bus autolaunch" function), the address is stored in ~/.dbus/session-bus/$MACHINE_ID-$DISPLAY (approx.).

    So you may manually set $DBUS_SESSION_BUS_ADDRESS as before, but you can also set $DISPLAY instead, and the program will find the matching session bus based on the X11 display.

  • To start a new (dedicated) session bus:

    dbus-launch --exit-with-session /bin/bash
grawity
  • 501,077
0

More practical way is to use ssh with X forwarding. And it works for me just fine.

ssh -X alt-user@localhost

Of cause, one has to setup ssh properly for this to work. But it is described very well on many places and this configuration details may be of interest as well. It works locally without performance degradation and doesn't require manual interference. Be advised pulseaudio requires special configuration to share among multiple users.

Dmytro
  • 101