Investigamos por todo el mundo online para mostrarte la solución para tu inquietud, si continúas con alguna inquietud puedes dejar un comentario y contestaremos porque estamos para ayudarte.
Solución:
Solución 1:
Por dbus-lanzamiento (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 encontrar 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 suelo:
[[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.
Cualquier programa X que se ejecute desde gnome-terminal se comportará bien, y dbus-launch se limpiará automáticamente cuando gnome-terminal salga.
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. Luego, las variables que hay que exportar a la sesión.
Entonces funciona como un encanto 🙂
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 la identificación de la máquina, el lanzamiento de dbus muestra las variables que queremos; mediante el uso 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 cuando intenté ejecutar un comando X remoto y hacer que la sesión saliera después de que la herramienta X había salido.
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
actualizar 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 -utilizado)
Reseñas y calificaciones
Finalizando este artículo puedes encontrar las acotaciones de otros programadores, tú además eres capaz insertar el tuyo si lo deseas.