Como configurar o D-Bus e o SS-X-Forwarding para impedir que o SSH seja interrompido na saída?

Question

Eu estou tentando executar vários aplicativos Gnome via X11 Forwarding e SSH. Alguns aplicativos farão com que o aplicativo 'dbus-launch' seja gerado primeiro. O problema é que o lançamento do dbus não fecha quando o aplicativo X é encerrado e, portanto, deve ser eliminado antes que a sessão do SSH possa ser fechada corretamente.

Eu assumo que o problema é que os aplicativos X / Gnome não podem se conectar com o daemon do barramento de mensagens principal e, portanto, devem iniciar sua própria cópia? Como posso consertar isso? Ou o que estou perdendo?

Aqui está um exemplo. Eu tenho X11 Forwarding habilitado, tudo parece funcionar bem.

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

(aqui o programa gcalctool é iniciado e é exibido no meu servidor X remove (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

(agora, depois de fechar o aplicativo gcalctool na sessão remota)

[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

Observe que o lançamento do dbus ainda está ativo. E a pior parte, isso impede que a conexão SSH feche corretamente até que seja eliminada.

Observe que o daemon de mensagens do sistema está em execução, como pode ser visto aqui:

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

O que estou perdendo aqui? Eu nunca vi esse comportamento antes. Presumivelmente, eu só vi aplicativos que podem se conectar ao daemon do barramento de mensagens sem impedimentos? Eu procurei em / etc / dbus-1 por respostas, mas não sei o que procurar.

Agradecemos antecipadamente pela ajuda.

[EDITAR]

OK, estou percebendo que estou passando por um problema comum. Parece que este é um comportamento bastante comum, mas sem uma boa solução. Estou experimentando o SSH travar porque o lançamento do dbus ainda está ativo no tty. Mas aparentemente não há uma boa maneira de fazer com que o lançamento do dbus aconteça em silêncio.

Observar o /etc/X11/xinit/xinitrc.d/00-start-message-bus.sh dá alguma pista sobre o que deve acontecer com uma sessão X "normal". Isso, obviamente, não funciona quando se está apenas invocando um aplicativo X para um servidor X remoto.

Como solução temporária, adicionei isso ao meu .bash_logout:

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

Isso permitirá que a sessão SSH seja encerrada, mas parece ruim. Existe alguma solução melhor por aí? Qual é a maneira correta de executar aplicativos X11 remotos sem que o dbus atrapalhe?

    

Answer 1

Por lançamento-dbus (1):

If DBUS_SESSION_BUS_ADDRESS is not set for a process that tries to use D-Bus, by default the process will attempt to invoke dbus-launch with the --autolaunch option to start up a new session bus or find the existing bus address on the X display or in a file in ~/.dbus/session-bus/

Whenever an autolaunch occurs, the application that had to start a new bus will be in its own little world; it can effectively end up starting a whole new session if it tries to use a lot of bus services. This can be suboptimal or even totally broken, depending on the app and what it tries to do.

There are two common reasons for autolaunch. One is ssh to a remote machine.

Assim, parece que o truque é iniciar o dbus-daemon preventivamente, de tal forma que os programas possam encontrá-lo. Eu uso:

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

que, além do gnome-terminal, inicia o dbus-daemon e configura $ DBUS_SESSION_BUS_ADDRESS dentro do gnome-terminal .

Quaisquer programas X executados a partir do gnome-terminal se comportam bem, e o dbus-launch limpa depois de si próprio quando o gnome-terminal sai.

    

Answer 2

Eu me pergunto se o problema não vem por causa de uma sessão de dbus desconhecida ou inexistente.

Na verdade, quando uma sessão SSH é aberta, ela não inicia uma sessão dbus. Alguns programas podem iniciá-lo, mas a sessão não o conhece (portanto, não pode fechá-lo).

Não saber sobre a sessão dbus também significa que os programas que usam o dbus, mas não o iniciam, terão problemas.

As seções

dbus são por máquina e por tela X11. Suas informações são armazenadas em $ HOME / .dbus / session-bus / - no entanto, o processo referenciado pode estar fechado, portanto, uma verificação extra é necessária para determinar se a inicialização do dbus é necessária ou não. Então, as variáveis que existem são exportadas para a sessão.

Então funciona como um encanto:)

Eu coloquei o seguinte no meu arquivo .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]\+\)*$//')
    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 faz parte do systemd e permite recuperar o ID da máquina o dbus-launch exibe as variáveis que queremos; usando export $(dbus-launch) , recuperamos a saída do dbus-launch e exportamos as variáveis

se você quer que seja feito em uma sessão não-interativa (por exemplo, ao executar um comando do ssh) tente colocá-lo em .bashrc (mas cuidado que o bashrc é executado no shell aberto do EVEERY)

    

Answer 3

Eu tive o mesmo problema ao tentar executar um comando X remoto e fazer a sessão sair após a ferramenta X ter saído.

Então eu queria correr

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

Mas tive que usar:

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

Depois de fechar o firefox, isso também fecha a sessão do ssh.

Atualizar :

Isso parece deixar uma carga de processos dbus-daemon em execução no servidor, portanto, isso não é o ideal, adicionar --exit-with-session em ambas as contas não ajuda, porque isso reverte o comportamento original

atualização 2 : isso funciona quando eu uso aspas simples (como sugerido por @lobo) e adicionando kill -TERM $DBUS_SESSION_BUS_PID para matar os processos restantes de dbus-daemon, como proposto por Holgr Joukl de link )