Solución 1:
Por lanzamiento de dbus(1):
Si DBUS_SESSION_BUS_ADDRESS no está configurado para un proceso que intenta usar D-Bus, de manera predeterminada, el proceso intentará invocar dbus-launch con la opción --autolaunch para iniciar un nuevo bus de sesión o buscar la dirección de bus existente en la pantalla X o en un archivo en ~/.dbus/session-bus/
Cada vez que se produzca un inicio automático, la aplicación que tuvo que iniciar un nuevo bus estará en su propio pequeño mundo; efectivamente puede terminar iniciando una sesión completamente nueva si intenta usar muchos servicios de bus. Esto puede ser subóptimo o incluso totalmente defectuoso, según la aplicación y lo que intente hacer.
Hay dos razones comunes para el inicio automático. Uno es ssh a una máquina remota.
Entonces parece que el truco es iniciar dbus-daemon de forma preventiva, de tal manera que los programas puedan encontrarlo. Yo uso:
[[email protected] ~]$ dbus-launch --exit-with-session gnome-terminal
que, además de gnome-terminal, inicia dbus-daemon y establece $DBUS_SESSION_BUS_ADDRESS dentro de gnome-terminal .
Todos los programas X que se ejecutan desde gnome-terminal se comportan bien, y dbus-launch se limpia automáticamente cuando se cierra gnome-terminal.
Solución 2:
Me pregunto si el problema no se debe a una sesión de dbus desconocida o inactiva.
De hecho, cuando una sesión SSH está abierta, no inicia una sesión dbus. Algunos programas pueden iniciarlo, pero luego la sesión no lo sabe (por lo tanto, no puede cerrarlo).
No saber acerca de la sesión de dbus también significa que los programas que usan dbus pero no lo inician por sí mismos tendrán problemas.
Las secciones de dbus son por máquina y por pantalla X11. Su información se almacena en $HOME/.dbus/session-bus/; sin embargo, el proceso al que se hace referencia allí puede estar cerrado, por lo que se necesita una verificación adicional para determinar si es necesario iniciar dbus o no. Entonces, las variables que hay que exportar a la sesión.
Entonces funciona de maravilla :)
Puse lo siguiente en mi archivo .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
notas:hostnamectl es parte de systemd y permite recuperar el id de la máquina; el dbus-launch muestra las variables que queremos; usando export $(dbus-launch) recuperamos la salida de dbus-launch y exportamos las variables
si desea que se haga en una sesión no interactiva (por ejemplo, cuando ejecuta un comando desde ssh), intente ponerlo en .bashrc en su lugar (pero tenga en cuenta que bashrc se ejecuta en TODOS los shell abiertos)
Solución 3:
Tuve el mismo problema al intentar ejecutar un comando X remoto y hacer que la sesión se cerrara después de que la herramienta X se hubiera cerrado.
Así que quería correr
ssh -X [email protected] "firefox -no-remote"
Pero tuve que usar:
ssh -X [email protected] 'export \`dbus-launch\`; dbus-launch firefox -no-remote; kill -TERM $DBUS_SESSION_BUS_PID'
Después de cerrar Firefox, esto también cerraría la sesión ssh.
Actualizar :
Esto parece dejar una carga de procesos dbus-daemon ejecutándose en el servidor, por lo que no es óptimo, agregar --exit-with-session en ambas cuentas no ayuda, porque esto revierte el comportamiento original
actualización 2 :esto funciona cuando uso comillas simples (como lo sugiere @lobo) y agrego kill -TERM $DBUS_SESSION_BUS_PID para eliminar los procesos sobrantes de dbus-daemon, según lo propuesto por Holgr Joukl de https://blog.dhampir.no/content/how-to-prevent-ssh-x-from-hanging-on-exit-when-dbus-is -usado)