Como configurar o D-Bus e o X-Forwarding SSH para impedir que o SSH fique pendurado na saída?

Estou tentando executar vários aplicativos Gnome via X11 Forwarding e SSH. Algumas aplicações farão com que a aplicação 'dbus-launch' seja gerada primeiro. O problema é que o dbus-launch não fecha quando o aplicativo X é encerrado e, portanto, deve ser eliminado antes que a sessão SSH possa ser fechada corretamente.

Suponho que o problema é que os aplicativos X / Gnome não podem se conectar ao daemon de 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. Tenho o encaminhamento X11 ativado, tudo parece funcionar bem.

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

(aqui o programa gcalctool inicia e é exibido no meu servidor X de remoção (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 dbus-launch ainda está ativo. E a pior parte, isso impede que a conexão SSH seja fechada 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 de barramento de mensagens sem impedimentos? Procurei no / etc / dbus-1 por respostas, mas não sei o que procurar.

Obrigado antecipadamente pela ajuda.

[EDITAR]

OK, estou percebendo que estou enfrentando um problema comum. Parece que este é um comportamento bastante comum, mas sem uma boa solução. Estou enfrentando o travamento do SSH porque o dbus-launch ainda está ativo no tty. Mas aparentemente não há uma boa maneira de fazer com que o dbus-launch ocorra silenciosamente.

Olhar para /etc/X11/xinit/xinitrc.d/00-start-message-bus.sh fornece algumas dicas sobre o que deve acontecer com uma sessão X "normal". Obviamente, isso não funciona ao invocar 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 desagradável. Existem soluções melhores por aí? Qual é a maneira correta de executar aplicativos remotos X11 sem o dbus atrapalhar?

Por lançamento do dbus (1):

Se DBUS_SESSION_BUS_ADDRESS não estiver definido para um processo que tente usar o D-Bus, por padrão, o processo tentará chamar o dbus-launch com a opção --autolaunch para iniciar um novo barramento de sessão ou encontrar o endereço de barramento existente na tela X ou em um arquivo em ~ / .dbus / session-bus /

Sempre que ocorre um lançamento automático, o aplicativo que teve que iniciar um novo barramento estará em seu próprio mundinho; ele pode efetivamente terminar uma sessão totalmente nova se tentar usar muitos serviços de barramento. Isso pode ser abaixo do ideal ou até mesmo totalmente interrompido, dependendo do aplicativo e do que ele tenta fazer.

Há dois motivos comuns para o lançamento automático. Um é ssh para uma máquina remota.

Portanto, parece que o truque é iniciar o dbus-daemon preventivamente, de maneira 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 define $ DBUS_SESSION_BUS_ADDRESS dentro do gnome-terminal .

Todos os programas X executados no gnome-terminal se comportam bem e o dbus-launch se limpa quando o gnome-terminal sai.

Gostaria de saber se o problema não vem por causa de uma sessão dbus desconhecida ou incômoda.

De fato, 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 é possível fechá-lo).

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

As seções do dbus são por máquina e por monitor X11. Suas informações são armazenadas em $ HOME / .dbus / session-bus / - no entanto, o processo mencionado lá pode ser fechado, portanto é necessária uma verificação extra para determinar se é necessário ou não iniciar o dbus. Em seguida, as variáveis ​​devem ser exportadas para a sessão.

Então funciona como um encanto :)

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]\+\)*$/\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 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ê quiser que seja feito em uma sessão não interativa (por exemplo, ao executar um comando a partir do ssh), tente colocá-lo em .bashrc (mas lembre-se de que o bashrc é executado no shell aberto do EVEERY)

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

Então eu queria correr

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

Mas teve que usar:

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

Após fechar o firefox, isso também fecha a sessão ssh.

Atualização :

Isso parece deixar uma carga de processos do dbus-daemon em execução no servidor, portanto, isso não é ideal, adicionando --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 adiciono kill -TERM $DBUS_SESSION_BUS_PIDpara eliminar os processos restantes do dbus-daemon, conforme proposto por Holgr Joukl em https://blog.dhampir.no/content/how- para impedir-ssh-x-de-pendurar-na-saída-quando-o dbus é usado )