Як налаштувати D-Bus та SSH X-Forwarding, щоб запобігти зависанню SSH при виході?

Я намагаюся запускати різні програми Gnome через X11 Forwarding та SSH. Деякі програми спричинить спочатку породження програми "dbus-start". Проблема полягає в тому, що запуск dbus не закривається, коли програма 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 все ще активний. І найгірше, що це запобігає належному закриттю з'єднання SSH, поки воно не буде вбите.

Зауважте, що демон-система повідомлень на всій системі працює, як це видно тут:

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

Що я тут пропускаю? Я ніколи раніше не бачив такої поведінки. Імовірно, я бачив лише програми, які можуть безперешкодно підключатися до демона шини повідомлень? Я шукав відповіді / etc / dbus-1, але не знаю, що шукати.

Заздалегідь дякую за допомогу.

[EDIT]

Гаразд, я розумію, що у мене виникає загальна проблема. Здається, це досить поширена поведінка, але без хорошого рішення. У мене спостерігається зависання SSH, оскільки запуск dbus все ще активний в 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-start за допомогою параметра --autolaunch для запуску нової шини сеансу або пошуку наявної адреси шини на дисплеї X або у файлі в ~ / .dbus / session-bus /

Щоразу, коли відбувається автозапуск, додаток, якому довелося запустити нову шину, опиниться у своєму маленькому світі; він може ефективно закінчити цілий новий сеанс, якщо він намагатиметься використовувати багато автобусних послуг. Це може бути неоптимальним або навіть повністю порушеним, залежно від програми та того, що вона намагається зробити.

Існує дві загальні причини автозапуску. Один - ssh на віддаленій машині.

Тому, здається, хитрість полягає в тому, щоб запустити dbus-демон наперед, таким чином, щоб програми могли його знайти. Я використовую:

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

який, окрім gnome-терміналу, запускає dbus-демон і встановлює $ DBUS_SESSION_BUS_ADDRESS в межах gnome-терміналу .

Будь-які програми X запускаються з gnome-терміналу, тоді вони ведуть себе добре, і dbus-start очищається після себе, коли gnome-термінал виходить.

Цікаво, чи проблема не виникає через невідомий або невикористовуваний сеанс dbus.

Дійсно, коли сеанс SSH відкритий, він не запускає сеанс dbus. Деякі програми можуть запустити його, але тоді сеанс не знає про нього (отже, не може його закрити).

Якщо не знати про сеанс dbus, це також означає, що програми thzat використовують 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-start відображає потрібні нам змінні; за допомогою export $(dbus-launch)ми отримуємо вихід dbus-start та експортуємо змінні

якщо ви хочете, щоб це було зроблено на неінтерактивній сесії (наприклад, під час запуску команди з 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-демон, тому це не є оптимальним, додавання --exit-with-session на обох облікових записах не допомагає, оскільки це повертає оригінальну поведінку

оновлення 2 : це спрацьовує, коли я використовую одинарні лапки (як це запропонував @lobo) і додає kill -TERM $DBUS_SESSION_BUS_PIDдля вбивства залишкові процеси dbus-daemon, як це запропонував Холгр Джоукл з https://blog.dhampir.no/content/how- щоб запобігти-ssh-x-від-повісити-на-вихід-коли-dbus-використовується )