Jak skonfigurować D-Bus i SSH X-Forwarding, aby zapobiec zawieszaniu się SSH przy wyjściu?

Próbuję uruchomić różne aplikacje Gnome za pośrednictwem X11 Forwarding i SSH. Niektóre aplikacje powodują, że najpierw zostanie uruchomiona aplikacja „dbus-launch”. Problem polega na tym, że uruchomienie dbus nie zamyka się po wyjściu z aplikacji X i dlatego musi zostać zabite, aby sesja SSH mogła zostać poprawnie zamknięta.

Zakładam, że problem polega na tym, że aplikacje X / Gnome nie mogą połączyć się z demonem magistrali komunikatów i dlatego muszą uruchomić własną kopię? Jak mogę to naprawić? Lub czego mi brakuje?

Oto przykład. Mam włączone X11 Forwarding, wszystko wydaje się działać dobrze.

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

(tutaj uruchamia się program gcalctool i wyświetla się na moim serwerze X usuwania (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

(teraz po zamknięciu aplikacji gcalctool w sesji zdalnej)

[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

Zauważ, że uruchomienie dbus jest nadal aktywne. A najgorsze jest to, że połączenie SSH nie zamyka się poprawnie, dopóki nie zostanie zabite.

Zauważ, że działa systemowy demon wiadomości, co można zobaczyć tutaj:

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

Czego tu brakuje? Nigdy wcześniej nie widziałem takiego zachowania. Prawdopodobnie kiedykolwiek widziałem tylko aplikacje, które mogą bez przeszkód łączyć się z demonem magistrali komunikatów? Szukałem odpowiedzi w / etc / dbus-1, ale nie wiem, czego szukać.

Z góry dziękuję za pomoc.

[EDYTOWAĆ]

OK, zdaję sobie sprawę, że mam wspólny problem. Wydaje się, że jest to dość powszechne zachowanie, ale bez dobrego rozwiązania. Występuje zawieszenie SSH, ponieważ uruchomienie dbus jest nadal aktywne w tty. Ale pozornie nie ma dobrego sposobu, aby uruchomienie dbus odbywało się po cichu.

Spojrzenie na /etc/X11/xinit/xinitrc.d/00-start-message-bus.sh daje pewne wskazówki co do tego, co powinno się stać z „normalną” sesją X. To oczywiście nie działa, gdy wywołuje się aplikację X na zdalnym serwerze X Server.

Jako tymczasowe obejście, dodałem to do mojego .bash_logout:

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

Pozwoli to zamknąć sesję SSH, ale wydaje się nieprzyzwoita. Czy są jakieś lepsze rozwiązania? Jaki jest właściwy sposób uruchamiania zdalnych aplikacji X11 bez przeszkadzania dbus?

Na uruchomienie dbus (1):

Jeśli DBUS_SESSION_BUS_ADDRESS nie jest ustawiony dla procesu, który próbuje użyć D-Bus, domyślnie proces będzie próbował wywołać uruchomienie dbus z opcją --autolaunch, aby uruchomić nową magistralę sesji lub znaleźć istniejący adres magistrali na wyświetlaczu X lub w pliku w ~ / .dbus / session-bus /

Za każdym razem, gdy nastąpi automatyczne uruchomienie, aplikacja, która musiała uruchomić nowy autobus, znajdzie się w swoim małym świecie; może skutecznie rozpocząć zupełnie nową sesję, jeśli spróbuje skorzystać z wielu usług autobusowych. Może to być nieoptymalne lub nawet całkowicie zepsute, w zależności od aplikacji i tego, co próbuje zrobić.

Istnieją dwa typowe powody automatycznego uruchamiania. Jednym z nich jest ssh na zdalnym komputerze.

Wydaje się więc, że sztuczką jest zapobiegawcze uruchomienie demona dbus w taki sposób, aby programy mogły go znaleźć. Używam:

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

który oprócz gnome-terminal uruchamia demona dbus i ustawia $ DBUS_SESSION_BUS_ADDRESS w gnome-terminal .

Wszelkie programy X uruchamiane z terminala gnome zachowują się ładnie, a dbus-launch czyści się sam po wyjściu z terminala gnome.

Zastanawiam się, czy problem nie pojawia się z powodu nieznanej lub nieoczekiwanej sesji dbus.

Rzeczywiście, gdy sesja SSH jest otwarta, nie uruchamia ona sesji dbus. Niektóre programy mogą go uruchomić, ale wtedy sesja o nim nie wie (stąd nie można go zamknąć).

Brak wiedzy o sesji dbus oznacza również, że programy, które używają dbus, ale nie uruchamiają go same, będą miały problemy.

Sekcje dbus są na maszynę i na wyświetlacz X11. Ich informacje są przechowywane w $ HOME / .dbus / session-bus / - jednak proces, do którego się tam odwołuje, może zostać zamknięty, więc konieczna jest dodatkowa kontrola, aby ustalić, czy uruchomienie dbus jest potrzebne, czy nie. Następnie zmienne, które mają zostać wyeksportowane do sesji.

To działa jak urok :)

W moim pliku .bash_profile umieszczam:

# 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

uwagi: hostnamectl jest częścią systemd i pozwala odzyskać identyfikator komputera, dbus-launch wyświetla zmienne, które chcemy; za pomocą export $(dbus-launch)pobieramy dane wyjściowe dbus-launch i eksportujemy zmienne

jeśli chcesz, aby było to zrobione na nieinteraktywnym sessio (np. podczas uruchamiania polecenia z ssh), spróbuj umieścić go w .bashrc (ale uważaj, że bashrc jest wykonywany przy otwartej powłoce EVEERY)

Miałem ten sam problem, gdy próbowałem uruchomić zdalne polecenie X i sprawić, że sesja zakończyła się po wyjściu narzędzia X.

Więc chciałem biec

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

Ale musiałem użyć:

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

Po zamknięciu Firefoksa spowoduje to także zamknięcie sesji ssh.

Aktualizacja :

Wydaje się, że pozostawia to obciążenie procesów demona dbus uruchomionych na serwerze, więc nie jest to optymalne, dodanie opcji --exit-with-session na obu kontach nie pomaga, ponieważ to odwraca oryginalne zachowanie

aktualizacja 2 : działa to, gdy używam pojedynczych cudzysłowów (jak sugeruje @lobo) i dodawania w kill -TERM $DBUS_SESSION_BUS_PIDcelu zabicia resztkowych procesów demona dbus, jak zaproponował Holgr Joukl z https://blog.dhampir.no/content/how- to-prevent-ssh-x-from-hang-on-exit-when-dbus-is-used )