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

Я пытаюсь запустить различные приложения Gnome через X11 Forwarding и SSH. Некоторые приложения будут вызывать приложение «dbus-launch» в первую очередь. Проблема в том, что dbus-launch не закрывается при выходе из приложения X и, следовательно, должен быть уничтожен до того, как сеанс SSH может быть правильно закрыт.

Я предполагаю, что проблема в том, что приложения X / Gnome не могут соединиться с главным демоном шины сообщений и поэтому должны запускать свою собственную копию? Как я могу это исправить? Или чего мне не хватает?

Вот пример. У меня включена переадресация X11, вроде все работает нормально.

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

(здесь программа gcalctool запускается и отображается на моем удаленном X-сервере (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

(теперь, после закрытия приложения gcalctool в удаленном сеансе)

[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

Обратите внимание, что dbus-launch все еще активен. И что хуже всего, это предотвращает правильное закрытие соединения SSH, пока оно не будет уничтожено.

Обратите внимание, что работает системный демон сообщений, как можно увидеть здесь:

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

Что мне здесь не хватает? Я никогда не видел такого поведения раньше. Предположительно, я когда-либо видел приложения, которые могут беспрепятственно подключаться к демону шины сообщений? Я искал ответы в / etc / dbus-1, но не знаю, что искать.

Заранее спасибо за помощь.

[РЕДАКТИРОВАТЬ]

Хорошо, я понимаю, что у меня общая проблема. Кажется, это довольно распространенное поведение, но без хорошего решения. Я испытываю зависание SSH, потому что dbus-launch все еще активен в tty. Но, похоже, нет хорошего способа, чтобы запуск dbus происходил тихо.

Взглянув на /etc/X11/xinit/xinitrc.d/00-start-message-bus.sh, вы получите некоторое представление о том, что должно произойти с "нормальным" сеансом X. Это, конечно, не работает, когда вы просто вызываете X-приложение на удаленный X-сервер.

В качестве временного решения я добавил это в свой .bash_logout:

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

Это позволит закрыть сессию SSH, но это кажется грязным. Есть ли лучшие решения там? Как правильно запускать удаленные приложения X11 без использования dbus?

За 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-терминала, запускает dbus-daemon и устанавливает $ DBUS_SESSION_BUS_ADDRESS в gnome-терминале .

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

Интересно, не возникает ли проблема из-за неизвестного или не проходящего сеанса 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 и экспортируем переменные

если вы хотите, чтобы это было сделано в неинтерактивном sessio (например, при запуске команды из ssh), попробуйте вместо этого поместить его в .bashrc (но помните, что bashrc выполняется в каждой открытой оболочке)

У меня возникла та же проблема при попытке запустить удаленную команду 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- для предотвращения-ssh-x-от-зависания на выходе-когда-dbus-is-used )