Come configurare D-Bus e SSH X-Forwarding per impedire che SSH si blocchi all'uscita?

Sto tentando di eseguire varie applicazioni Gnome tramite X11 Forwarding e SSH. Alcune applicazioni causeranno la prima generazione dell'applicazione 'dbus-launch'. Il problema è che dbus-launch non si chiude all'uscita dall'applicazione X e quindi deve essere interrotto prima che la sessione SSH possa essere chiusa correttamente.

Presumo che il problema sia che le applicazioni X / Gnome non riescono a connettersi con il demone principale del bus dei messaggi e quindi devono avviare la propria copia? Come posso risolvere questo problema? O cosa mi sto perdendo?

Ecco un esempio Ho X11 Forwarding abilitato, tutto sembra funzionare bene.

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

(qui il programma gcalctool si avvia e viene visualizzato sul mio server X di rimozione (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

(ora, dopo aver chiuso l'app gcalctool nella sessione 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

Si noti che dbus-launch è ancora attivo. E la parte peggiore, questo impedisce alla connessione SSH di chiudersi correttamente fino a quando non viene uccisa.

Si noti che il daemon di messaggi a livello di sistema è in esecuzione, come si può vedere qui:

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

Cosa mi sto perdendo qui? Non ho mai visto questo comportamento prima. Presumibilmente, ho sempre visto senza ostacoli le applicazioni in grado di connettersi al demone del bus dei messaggi? Ho cercato in / etc / dbus-1 le risposte, ma non so cosa cercare.

Grazie in anticipo per l'aiuto.

[MODIFICARE]

OK, sto realizzando che sto riscontrando un problema comune. Sembra che questo sia un comportamento abbastanza comune, ma senza una buona soluzione. Sto sperimentando il blocco SSH perché dbus-launch è ancora attivo nel tty. Ma a quanto pare non c'è un buon modo per far sì che il lancio del dbus avvenga in modo silenzioso.

Guardare /etc/X11/xinit/xinitrc.d/00-start-message-bus.sh dà qualche indizio su cosa dovrebbe accadere con una sessione X "normale". Questo ovviamente non funziona quando si richiama semplicemente un'applicazione X a un X Server remoto.

Come soluzione temporanea, l'ho aggiunto al mio .bash_logout:

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

Ciò consentirà la chiusura della sessione SSH, ma sembra difficile. Ci sono soluzioni migliori là fuori? Qual è il modo corretto di eseguire applicazioni X11 remote senza che dbus si frapponga?

Per lancio dbus (1):

Se DBUS_SESSION_BUS_ADDRESS non è impostato per un processo che tenta di utilizzare D-Bus, per impostazione predefinita il processo tenterà di invocare dbus-launch con l'opzione --autolaunch per avviare un nuovo bus di sessione o trovare l'indirizzo del bus esistente sul display X o in un file in ~ / .dbus / session-bus /

Ogni volta che si verifica un lancio automatico, l'applicazione che doveva avviare un nuovo bus sarà nel suo piccolo mondo; può effettivamente iniziare una nuova sessione se tenta di utilizzare molti servizi di autobus. Questo può essere non ottimale o addirittura completamente rotto, a seconda dell'app e di ciò che tenta di fare.

Esistono due motivi comuni per l'avvio automatico. Uno è ssh per una macchina remota.

Quindi sembra che il trucco sia avviare preventivamente dbus-daemon, in modo tale che i programmi possano trovarlo. Io uso:

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

che, a parte gnome-terminal, avvia dbus-daemon e imposta $ DBUS_SESSION_BUS_ADDRESS all'interno di gnome-terminal .

Tutti i programmi X eseguiti da gnome-terminal si comportano bene e dbus-launch ripulisce dopo se stesso quando gnome-terminal esce.

Mi chiedo se il problema non si presenta a causa di una sessione dbus sconosciuta o inesistente.

Infatti quando una sessione SSH è aperta, non avvia una sessione dbus. Alcuni programmi potrebbero avviarlo, ma la sessione non lo conosce (quindi non può chiuderlo).

Non conoscere la sessione dbus significa anche che i programmi che usano dbus ma che non si avviano da soli avranno problemi.

le sezioni dbus sono per macchina e per display X11. Le loro informazioni sono memorizzate in $ HOME / .dbus / session-bus / - tuttavia, il processo a cui si fa riferimento potrebbe essere chiuso, quindi è necessario un controllo aggiuntivo per determinare se è necessario o meno l'avvio di dbus. Quindi, le variabili presenti devono essere esportate nella sessione.

Quindi funziona come un fascino :)

Ho inserito quanto segue nel mio file .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

note: hostnamectl fa parte di systemd e consente di recuperare l'id macchina che dbus-launch visualizza le variabili che vogliamo; usando export $(dbus-launch)recuperiamo l'output di dbus-launch ed esportiamo le variabili

se vuoi che sia fatto su sessio non interattivo (ad es. quando esegui un comando da ssh) prova invece a inserirlo in .bashrc (ma fai attenzione che bashrc viene eseguito su EVEERY open shell)

Ho avuto lo stesso problema durante il tentativo di eseguire un comando X remoto e far uscire la sessione dopo la chiusura dello strumento X.

Quindi volevo correre

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

Ma ho dovuto usare:

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

Dopo aver chiuso Firefox, questo chiuderebbe anche la sessione SSH.

Aggiornamento :

Questo sembra lasciare un carico di processi dbus-daemon in esecuzione sul server, quindi non è ottimale, l'aggiunta di --exit-with-session su entrambi gli account non aiuta, perché ripristina il comportamento originale

aggiornamento 2 : funziona quando uso virgolette singole (come suggerito da @lobo) e l'aggiunta kill -TERM $DBUS_SESSION_BUS_PIDper eliminare i processi rimanenti di dbus-daemon, come proposto da Holgr Joukl da https://blog.dhampir.no/content/how- prevenire-ssh-x-da-appendere-all'uscita-quando-viene usato-dbus )