Как настроить D-шину и X-передачу SSH, чтобы препятствовать тому, чтобы SSH завис на выходе?
Per dbus-launch (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- для предотвращения-ssh-x-from-зависания-при-выходе-когда-dbus-используется )
Интересно, не возникает ли проблема из-за неизвестного или не завершающегося сеанса 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 запускается при КАЖДОЙ открытой оболочке)