How to configure D-Bus and SSH X-Forwarding to prevent SSH from hanging on exit?

I am attempting to run various Gnome applications via X11 Forwarding and SSH. Some applications will cause the 'dbus-launch' application to be spawned first. The problem is that dbus-launch doesn't close when the X application is exited, and therefore must be killed before the SSH session can be closed properly.

I assume the problem is that the X/Gnome applications can't connect with the main message bus daemon and therefore must launch their own copy? How can I fix this? Or what am I missing?

Here is an example. I have X11 Forwarding enabled, all seems to work fine.

[me@host ~]$ gnome-calculator &
[1] 4803

(here the gcalctool program launches and is displayed to my remove X server (Xming))

[me@host ~]$ ps
  PID TTY          TIME CMD
 4706 pts/0    00:00:00 bash
 4803 pts/0    00:00:00 gnome-calculator
 4807 pts/0    00:00:00 dbus-launch
 4870 pts/0    00:00:00 ps

(now, after closing the gcalctool app in the remote session)

[me@host ~]$ ps
  PID TTY          TIME CMD
 4706 pts/0    00:00:00 bash
 4807 pts/0    00:00:00 dbus-launch
 4898 pts/0    00:00:00 ps

Note that dbus-launch is still active. And the worst part, this prevents the SSH connection from closing properly until it is killed.

Note that the system wide message daemon is running, as can be seen here:

[me@host ~]$ ps ax
 4696 ?     Ssl   0:00 dbus-daemon --system

What am I missing here? I have never seen this behavior before. Presumably, I've only ever seen applications that can connect to the message bus daemon unhindered? I have looked in /etc/dbus-1 for answers, but don't know what to look for.

Thanks in advance for the help.

[EDIT]

OK, I'm realizing that I'm experiencing a common problem. It seems this is a fairly common behavior, but without a good solution. I'm experiencing the SSH hang because dbus-launch is still active in the tty. But there's seemingly no good way to get the dbus-launch to happen quietly.

Looking at /etc/X11/xinit/xinitrc.d/00-start-message-bus.sh gives some clue as to what is supposed to happen with a "normal" X session. This of course doesn't work when just invoking an X application to a remote X Server.

As a temporary workaround, I've added this to my .bash_logout:

# ~/.bash_logout
pkill -u $USER -t `tty | cut -d '/' -f 3,4` dbus-launch

This will allow the SSH session to close out, but it feels kludgy. Are there any better solutions out there? What's the proper way to run remote X11 applications without dbus getting in the way?

Solution 1:

Per dbus-launch(1):

If DBUS_SESSION_BUS_ADDRESS is not set for a process that tries to use D-Bus, by default the process will attempt to invoke dbus-launch with the --autolaunch option to start up a new session bus or find the existing bus address on the X display or in a file in ~/.dbus/session-bus/

Whenever an autolaunch occurs, the application that had to start a new bus will be in its own little world; it can effectively end up starting a whole new session if it tries to use a lot of bus services. This can be suboptimal or even totally broken, depending on the app and what it tries to do.

There are two common reasons for autolaunch. One is ssh to a remote machine.

So it seems the trick is to start dbus-daemon preemptively, in such a way that programs can find it. I use:

[me@host ~]$ dbus-launch --exit-with-session gnome-terminal

which, aside from gnome-terminal, starts dbus-daemon and sets $DBUS_SESSION_BUS_ADDRESS within gnome-terminal.

Any X programs run from gnome-terminal then behave nicely, and dbus-launch cleans up after itself when gnome-terminal exits.

Solution 2:

I wonder if the problem doesn't come because of an unknown or inexiting dbus session.

Indeed when an SSH session is open, it doesn't launch a dbus session. Some programs may launch it, but then the session doesn't know about it (hence can't close it).

Not knowing about the dbus session also means that programs thzat use dbus but don't launch it themselves will have problems.

dbus sections are per machine and per X11 display. Their info is stored in $HOME/.dbus/session-bus/- however, the process referenced there may be closed, so an extra check is needed to determine if launching dbus is needed or not. Then, the variables there are to ber exported to the session.

Then it works like a charm :)

I put the following in my .bash_profile file:

# set dbus for remote SSH connections
if [ -n "$SSH_CLIENT" -a -n "$DISPLAY" ]; then
    machine_id=$(LANGUAGE=C hostnamectl|grep 'Machine ID:'| sed 's/^.*: //')
    x_display=$(echo $DISPLAY|sed 's/^.*:\([0-9]\+\)\(\.[0-9]\+\)*$/\1/')
    dbus_session_file="$HOME/.dbus/session-bus/${machine_id}-${x_display}"
    if [ -r "$dbus_session_file" ]; then
            export $(grep '^DBUS.*=' "$dbus_session_file")
            # check if PID still running, if not launch dbus
            ps $DBUS_SESSION_BUS_PID | tail -1 | grep dbus-daemon >& /dev/null
            [ "$?" != "0" ] && export $(dbus-launch) >& /dev/null
    else
            export $(dbus-launch) >& /dev/null
    fi
fi

notes: hostnamectl is part of systemd and allows to retrieve the machine-id the dbus-launch displays the variables we want; by using export $(dbus-launch) we retrieve the output of dbus-launch and export the variables

if you want it to be done on non-interactive sessio (eg when running a command from ssh) try putting it in .bashrc instead (but beware that bashrc is executed at EVEERY opened shell)

Solution 3:

I had the same problem when trying to run a remote X command, and make the session exit after the X tool had exited.

So I wanted to run

ssh -X user@remotehost "firefox -no-remote"

But had to use:

ssh -X user@remotehost 'export \`dbus-launch\`; dbus-launch firefox -no-remote; kill -TERM $DBUS_SESSION_BUS_PID'

After closing firefox this would also close the ssh session.

Update:

This seems to leave a load of dbus-daemon processes running on the server, so this is not optimal, adding --exit-with-session on both accounts doesn't help, because this reverts the original behaviour

update 2: this does work when I use single quotes, (as suggested by @lobo) and adding kill -TERM $DBUS_SESSION_BUS_PID to kill the leftover dbus-daemon processes, as proposed by Holgr Joukl from https://blog.dhampir.no/content/how-to-prevent-ssh-x-from-hanging-on-exit-when-dbus-is-used)