Lösung 1:
Per dbus-launch(1):
Wenn DBUS_SESSION_BUS_ADDRESS nicht für einen Prozess gesetzt ist, der versucht, D-Bus zu verwenden, wird der Prozess standardmäßig versuchen, dbus-launch mit der Option --autolaunch aufzurufen, um einen neuen Sitzungsbus zu starten oder die vorhandene Busadresse auf dem X-Display zu finden oder in einer Datei in ~/.dbus/session-bus/
Immer wenn ein Autostart stattfindet, befindet sich die Anwendung, die einen neuen Bus starten musste, in ihrer eigenen kleinen Welt; Es kann effektiv dazu führen, dass eine ganz neue Sitzung gestartet wird, wenn es versucht, viele Busdienste zu nutzen. Dies kann suboptimal oder sogar völlig kaputt sein, je nach App und was sie zu tun versucht.
Es gibt zwei häufige Gründe für den automatischen Start. Einer ist ssh zu einem entfernten Rechner.
Der Trick scheint also darin zu bestehen, dbus-daemon präventiv zu starten, so dass Programme ihn finden können. Ich verwende:
[[email protected] ~]$ dbus-launch --exit-with-session gnome-terminal
die, abgesehen von gnome-terminal, dbus-daemon startet und $DBUS_SESSION_BUS_ADDRESS innerhalb von gnome-terminal setzt .
Alle X-Programme, die von gnome-terminal ausgeführt werden, verhalten sich dann gut, und dbus-launch räumt nach sich selbst auf, wenn gnome-terminal beendet wird.
Lösung 2:
Ich frage mich, ob das Problem nicht wegen einer unbekannten oder nicht existierenden dbus-Sitzung auftritt.
Wenn eine SSH-Sitzung geöffnet ist, wird tatsächlich keine Dbus-Sitzung gestartet. Einige Programme können es starten, aber dann weiß die Sitzung nichts davon (daher kann es nicht geschlossen werden).
Nichtwissen über die dbus-Sitzung bedeutet auch, dass Programme, die dbus verwenden, es aber nicht selbst starten, Probleme haben werden.
dbus-Abschnitte gelten pro Maschine und pro X11-Anzeige. Ihre Informationen werden in $HOME/.dbus/session-bus/ gespeichert. Der dort referenzierte Prozess kann jedoch geschlossen sein, sodass eine zusätzliche Überprüfung erforderlich ist, um festzustellen, ob das Starten von dbus erforderlich ist oder nicht. Dann sollen die dortigen Variablen in die Session exportiert werden.
Dann funktioniert es wie am Schnürchen :)
Ich habe Folgendes in meine .bash_profile-Datei eingefügt:
# 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
Anmerkungen:Hostnamectl ist Teil von Systemd und ermöglicht das Abrufen der Maschinen-ID. Der dbus-Launch zeigt die gewünschten Variablen an. indem Sie export $(dbus-launch) verwenden wir rufen die Ausgabe von dbus-launch ab und exportieren die Variablen
wenn Sie möchten, dass es in einer nicht-interaktiven Sitzung ausgeführt wird (z. B. wenn Sie einen Befehl von ssh ausführen), versuchen Sie es stattdessen in .bashrc (aber beachten Sie, dass bashrc bei JEDER geöffneten Shell ausgeführt wird)
Lösung 3:
Ich hatte das gleiche Problem, als ich versuchte, einen Remote-X-Befehl auszuführen und die Sitzung zu beenden, nachdem das X-Tool beendet wurde.
Also wollte ich rennen
ssh -X [email protected] "firefox -no-remote"
Musste aber verwenden:
ssh -X [email protected] 'export \`dbus-launch\`; dbus-launch firefox -no-remote; kill -TERM $DBUS_SESSION_BUS_PID'
Nach dem Schließen von Firefox würde dies auch die SSH-Sitzung schließen.
Aktualisieren :
Dies scheint eine Menge dbus-daemon-Prozesse auf dem Server laufen zu lassen, daher ist dies nicht optimal, das Hinzufügen von --exit-with-session auf beiden Konten hilft nicht, da dies das ursprüngliche Verhalten umkehrt
Aktualisierung 2 :Dies funktioniert, wenn ich einfache Anführungszeichen verwende (wie von @lobo vorgeschlagen) und kill -TERM $DBUS_SESSION_BUS_PID hinzufüge um die verbleibenden dbus-daemon-Prozesse zu beenden, wie von Holgr Joukl von https://blog.dhampir.no/content/how-to-prevent-ssh-x-from-hanging-on-exit-when-dbus-is vorgeschlagen -gebraucht)