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?
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:
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 zmiennejeś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)
źródło
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
Ale musiałem użyć:
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_PID
celu 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 )źródło
dbus-launch
jest uruchamiane lokalnie ), ale potem działa. Dzięki!