web-dev-qa-db-ja.com

SSHが終了時にハングアップしないように、D-BusおよびSSH X-Forwardingを構成する方法

X11転送とSSHを介してさまざまなGnomeアプリケーションを実行しようとしています。一部のアプリケーションでは、「dbus-launch」アプリケーションが最初に起動されます。問題は、Xアプリケーションが終了したときにdbus-launchが閉じないため、SSHセッションを適切に閉じる前に強制終了する必要があることです。

X/Gnomeアプリケーションがメインメッセージバスデーモンに接続できないため、独自のコピーを起動する必要があるという問題があると思いますか？どうすれば修正できますか？または何が欠けていますか？

例を示します。 X11転送を有効にしていますが、すべて正常に動作しているようです。

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

（ここでgcalctoolプログラムが起動し、私の削除Xサーバー（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

（今、リモートセッションでgcalctoolアプリを閉じた後）

[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

Dbus-launchがまだアクティブであることに注意してください。そして最悪の場合、これにより、SSH接続が強制終了されるまで適切に閉じることができなくなります。

次のように、システム全体のメッセージデーモンが実行されていることに注意してください。

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

ここで何が欠けていますか？これまでにこのような動作を見たことはありません。おそらく、メッセージバスデーモンに妨げられずに接続できるアプリケーションを見たことがありますか？/etc/dbus-1で回答を探しましたが、何を探すべきかわかりません。

助けてくれてありがとう。

[編集]

はい、よくある問題が発生していることを理解しています。これはかなり一般的な動作のようですが、良い解決策はありません。 dbus-launchがttyでまだアクティブであるため、SSHハングが発生しています。しかし、dubs-launchを静かに実行する良い方法はないようです。

/etc/X11/xinit/xinitrc.d/00-start-message-bus.shを見ると、「通常の」Xセッションで何が起こるかについての手掛かりが得られます。もちろん、これは、リモートXサーバーに対してXアプリケーションを呼び出すだけでは機能しません。

一時的な回避策として、これを.bash_logoutに追加しました。

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

これにより、SSHセッションを終了できますが、ぎこちない感じがします。そこに良い解決策はありますか？ dbusが邪魔をせずにリモートX11アプリケーションを実行する適切な方法は何ですか？

linuxx11dbus
19
taftster

Dbus-launch（1）ごと：

D-Busを使用しようとするプロセスにDBUS_SESSION_BUS_ADDRESSが設定されていない場合、デフォルトでは、プロセスは--autolaunchオプションを指定してdbus-launchを呼び出し、新しいセッションバスを起動するか、Xディスプレイで既存のバスアドレスを見つけようとします。または〜/ .dbus/session-bus /内のファイル

自動起動が発生するたびに、新しいバスを開始する必要があったアプリケーションは、独自の小さな世界に存在します。多数のバスサービスを使用しようとすると、まったく新しいセッションを開始することになります。これは、アプリやアプリが何をしようとしているのかに応じて、最適とは言えない場合もあれば、まったく壊れている場合もあります。

自動起動の一般的な理由は2つあります。 1つはリモートマシンへのsshです。

したがって、トリックは、プログラムがそれを見つけることができるような方法で、dbus-daemonをプリエンプティブに開始することです。私が使う：

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

これは、gnome-terminalとは別に、dbus-daemonを起動し、$ DBUS_SESSION_BUS_ADDRESS gnome-terminal内を設定します。

Gnome-terminalから実行されるXプログラムはすべて正常に動作し、gnome-terminalが終了すると、dbus-launchが自動的にクリーンアップします。

15
Nathan

Dbusセッションが不明または終了しないために問題が発生しないのでしょうか。

実際、SSHセッションが開いているときは、dbusセッションは起動しません。一部のプログラムはそれを起動する可能性がありますが、セッションはそれを認識しません（したがって、それを閉じることができません）。

Dbusセッションについて知らないということは、プログラムがdbusを使用するが、それ自体を起動しないと問題が発生することも意味します。

dbusセクションは、マシンごとおよびX11ディスプレイごとです。それらの情報は$ HOME/.dbus/session-bus /-に保存されますが、そこで参照されているプロセスが閉じている可能性があるため、dbusの起動が必要かどうかを判断するには、追加のチェックが必要です。次に、そこにある変数をセッションにエクスポートします。

それからそれは魅力のように働きます:)

以下を.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
_

注：hostnamectlはsystemdの一部であり、dbus-launchが必要な変数を表示するマシンIDを取得できます。 export $(dbus-launch)を使用して、dbus-launchの出力を取得し、変数をエクスポートします

非対話型のsessioで実行したい場合（たとえば、sshからコマンドを実行する場合）、代わりに.bashrcに配置してみてください（ただし、bashrcはEVEERYで開かれたシェルで実行されることに注意してください）

2
Pablo Saratxaga

リモートXコマンドを実行しようとしたときに同じ問題が発生し、Xツールが終了した後でセッションを終了させました。

走りたかった

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

しかし、使用する必要がありました：

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

Firefoxを閉じた後、sshセッションも閉じます。

更新：

これにより、サーバー上で実行されているdbus-daemonプロセスの負荷が残っているように見えるため、これは最適ではありません。両方のアカウントに--exit-with-sessionを追加しても、元の動作に戻るため、効果がありません。

update 2：これは、（@ loboで提案されているように）単一引用符を使用し、kill -TERM $DBUS_SESSION_BUS_PIDを追加して残りのdbusを強制終了すると機能します Holgr Joukl によって提案されたデーモンプロセス https://blog.dhampir.no/content/how-to-prevent-ssh-x-from-hanging-on-exit- when-dbus-is-used ）

1
Jens Timmerman