Как настроить D-Bus и SSH X-Forwarding, чтобы SSH не зависал при выходе?

На запуск dbus (1):

Если DBUS_SESSION_BUS_ADDRESS не установлен для процесса, который пытается использовать D-Bus, по умолчанию процесс будет пытаться вызвать dbus-launch с параметром --autolaunch, чтобы запустить новую шину сеанса или найти существующий адрес шины на дисплее X или в файле в ~ / .dbus / session-bus /

Каждый раз, когда происходит автозапуск, приложение, которое должно было запустить новую шину, оказывается в своем собственном маленьком мире; он может эффективно начать новый сеанс, если попытается использовать много шинных служб. Это может быть неоптимальным или даже полностью нарушенным, в зависимости от приложения и того, что оно пытается делать.

Есть две распространенные причины автозапуска. Один из них - ssh на удаленную машину.

Кажется, уловка состоит в том, чтобы заранее запустить dbus-daemon, чтобы программы могли его найти. Я использую:

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

который, помимо gnome-terminal, запускает dbus-daemon и устанавливает $ DBUS_SESSION_BUS_ADDRESS внутри gnome-terminal.

Любые X-программы, запускаемые из gnome-terminal, затем ведут себя нормально, а dbus-launch очищает себя после выхода из gnome-terminal.

У меня была такая же проблема при попытке запустить удаленную команду X и завершить сеанс после выхода из инструмента X.

Итак, я хотел бежать

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

Но пришлось использовать:

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

После закрытия firefox это также закроет сеанс ssh.

Обновить:

Кажется, что на сервере остается нагрузка процессов dbus-daemon, поэтому это не оптимально, добавление --exit-with-session для обеих учетных записей не помогает, потому что это возвращает исходное поведение

обновление 2: это работает, когда я использую одинарные кавычки (как предлагает @lobo) и добавляю kill -TERM $DBUS_SESSION_BUS_PID чтобы убить оставшиеся процессы dbus-daemon, как предлагает Holgr Joukl из https://blog.dhampir.no/content/how-to-prevent-ssh-x-from-hanging-on-exit-when-dbus-is-used)

Интересно, не возникает ли проблема из-за неизвестного или не завершающегося сеанса dbus.

Действительно, когда сеанс SSH открыт, он не запускает сеанс dbus. Некоторые программы могут запускать его, но тогда сеанс не знает об этом (следовательно, не может его закрыть).

Незнание о сеансе dbus также означает, что программы, использующие dbus, но не запускающие его сами, будут иметь проблемы.

Разделы dbus предназначены для каждой машины и для каждого дисплея X11. Их информация хранится в $ HOME / .dbus / session-bus / - однако упомянутый там процесс может быть закрыт, поэтому необходима дополнительная проверка, чтобы определить, нужен ли запуск dbus или нет. Затем переменные должны быть экспортированы в сеанс.

Тогда работает как шарм :)

Я поместил в свой файл .bash_profile следующее:

# 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

примечания: hostnamectl является частью systemd и позволяет получить идентификатор машины, dbus-launch отображает нужные нам переменные; используя export $(dbus-launch) мы получаем вывод dbus-launch и экспортируем переменные

если вы хотите, чтобы это выполнялось на неинтерактивном сеансе (например, при запуске команды из ssh), попробуйте вместо этого поместить его в .bashrc (но помните, что bashrc выполняется в КАЖДОЙ открытой оболочке)