Comment configurer D-Bus et SSH X-Forwarding pour empêcher SSH de se bloquer à la sortie ?

Solution 1 :

Par dbus-launch(1) :

Si DBUS_SESSION_BUS_ADDRESS n'est pas défini pour un processus qui tente d'utiliser D-Bus, par défaut, le processus tentera d'invoquer dbus-launch avec l'option --autolaunch pour démarrer un nouveau bus de session ou trouver l'adresse de bus existante sur l'affichage X ou dans un fichier dans ~/.dbus/session-bus/

Chaque fois qu'un lancement automatique se produit, l'application qui a dû démarrer un nouveau bus sera dans son propre petit monde; il peut finir par démarrer une toute nouvelle session s'il essaie d'utiliser de nombreux services de bus. Cela peut être sous-optimal ou même totalement cassé, selon l'application et ce qu'elle essaie de faire.

Il existe deux raisons courantes pour le lancement automatique. L'un est ssh vers une machine distante.

Il semble donc que l'astuce consiste à démarrer dbus-daemon de manière préventive, de manière à ce que les programmes puissent le trouver. J'utilise :

[[email protected] ~]$ dbus-launch --exit-with-session gnome-terminal

qui, à part gnome-terminal, démarre dbus-daemon et définit $DBUS_SESSION_BUS_ADDRESS dans gnome-terminal .

Tous les programmes X exécutés à partir de gnome-terminal se comportent alors correctement et dbus-launch se nettoie après lui-même lorsque gnome-terminal se ferme.

Solution 2 :

Je me demande si le problème ne vient pas d'une session dbus inconnue ou inexistante.

En effet lorsqu'une session SSH est ouverte, elle ne lance pas de session dbus. Certains programmes peuvent le lancer, mais la session ne le sait pas (et ne peut donc pas le fermer).

Ne pas connaître la session dbus signifie également que les programmes qui utilisent dbus mais ne le lancent pas eux-mêmes auront des problèmes.

Les sections dbus sont par machine et par écran X11. Leurs informations sont stockées dans $HOME/.dbus/session-bus/-cependant, le processus référencé ici peut être fermé, donc une vérification supplémentaire est nécessaire pour déterminer si le lancement de dbus est nécessaire ou not.Ensuite, les variables qui s'y trouvent sont à exporter vers la session.

Alors ça marche comme un charme :)

J'ai mis ce qui suit dans mon fichier .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

notes :hostnamectl fait partie de systemd et permet de récupérer l'id de la machine, le dbus-launch affiche les variables que l'on veut; en utilisant export $(dbus-launch) nous récupérons la sortie de dbus-launch et exportons les variables

si vous voulez que cela soit fait sur une session non interactive (par exemple lors de l'exécution d'une commande depuis ssh), essayez de le mettre dans .bashrc à la place (mais attention, bashrc est exécuté à CHAQUE shell ouvert)

Solution 3 :

J'ai eu le même problème en essayant d'exécuter une commande X à distance et de fermer la session après la fermeture de l'outil X.

Alors j'ai voulu courir

ssh -X [email protected] "firefox -no-remote"

Mais j'ai dû utiliser :

ssh -X [email protected] 'export \`dbus-launch\`; dbus-launch firefox -no-remote; kill -TERM $DBUS_SESSION_BUS_PID'

Après la fermeture de firefox, cela fermerait également la session ssh.

Mettre à jour :

Cela semble laisser une charge de processus dbus-daemon en cours d'exécution sur le serveur, donc ce n'est pas optimal, ajouter --exit-with-session sur les deux comptes n'aide pas, car cela inverse le comportement d'origine

mise à jour 2 :cela fonctionne lorsque j'utilise des guillemets simples (comme suggéré par @lobo) et en ajoutant kill -TERM $DBUS_SESSION_BUS_PID pour tuer les processus dbus-daemon restants, comme proposé par Holgr Joukl de https://blog.dhampir.no/content/how-to-prevent-ssh-x-from-hanging-on-exit-when-dbus-is -utilisé)